Relief Mapping - Performance Improvement - Beta v2

So I said I'd dig around the engine code, and I did. In finding the offset mapping shader, I bumped into the relief mapping shader. I said, "Hmmm, 14 passes is not a small number, I wonder if less will make a difference." 8 less passes later, I reached this result:

Click to Enlarge

LQ:











HQ:











In some cases, the "LQ" method looks even better than the "HQ" method. O_o
Now notice that framerate difference in the first image from both...
41 - HQ
69 - LQ
O_o

Exactly...

It's where the relief is combined with Realtime World Lighting and the warpzone. Largest hitting spot in the map.

Here are the changes made to gl_rmain.c:

At line 1133, change this chunk:

Code:

"#ifdef USEOFFSETMAPPING_RELIEFMAPPING\n"
"    // 14 sample relief mapping: linear search and then binary search\n"
"    // this basically steps forward a small amount repeatedly until it finds\n"
"    // itself inside solid, then jitters forward and back using decreasing\n"
"    // amounts to find the impact\n"
"    //vec3 OffsetVector = vec3(EyeVector.xy * ((1.0 / EyeVector.z) * OffsetMapping_Scale) * vec2(-1, 1), -1);\n"
"    //vec3 OffsetVector = vec3(normalize(EyeVector.xy) * OffsetMapping_Scale * vec2(-1, 1), -1);\n"
"    vec3 OffsetVector = vec3(normalize(EyeVector).xy * OffsetMapping_Scale * vec2(-1, 1), -1);\n"
"    vec3 RT = vec3(TexCoord, 1);\n"
"    OffsetVector *= 0.1;\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)          - 0.5);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.5    - 0.25);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.25   - 0.125);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.125  - 0.0625);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.0625 - 0.03125);\n"
"    return RT.xy;\n"

To this chunk:

Code:

"#ifdef USEOFFSETMAPPING_RELIEFMAPPING\n"
"    // 6 sample relief mapping: linear search and then binary search\n"
"    // this basically steps forward a small amount then jitters forward and back using decreasing\n"
"    // amounts to find the impact\n"
"    //vec3 OffsetVector = vec3(EyeVector.xy * ((1.0 / EyeVector.z) * OffsetMapping_Scale) * vec2(-1, 1), -1);\n"
"    //vec3 OffsetVector = vec3(normalize(EyeVector.xy) * OffsetMapping_Scale * vec2(-1, 1), -1);\n"
"    vec3 OffsetVector = vec3(normalize(EyeVector).xy * OffsetMapping_Scale * vec2(-1, 1), -1);\n"
"    vec3 RT = vec3(TexCoord, 1);\n"
"    OffsetVector *= 0.375;\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)          - 0.5);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.5    - 0.25);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.25   - 0.125);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.125  - 0.0625);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.0625 - 0.03125);\n"
"    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.03125 - 0.015625);\n"
"    return RT.xy;\n"

And make the same changes at line 2318.

Test it for yourself to see what I mean. BTW, the "height" difference is already compensated for in the .375 value. The offset mapping scale cvar doesn't need to be changed from .02. Maybe someone wants to calculate the more accurate value than .375? But it's close enough. The height is almost exactly identical.

The biggest visual difference is when you observe the texture at a really short distance, thats why I recommend it be a menu option, LQ vs HQ. I will point out that HQ seems to overcompensate frequently and produce strange artifacts while LQ seems to be dead accurate. One recommendation I make is to add a few more iterations of jitter, that would most likely remove the "banding" more visible in HQ without creating the strange artifacts present from 8 extra iterations....

Yeah, hope that's helpful, I'd commit it to git, but I don't have any portion of git setup to run with this project, or an account/name.

"Low Quality" looks just right. "High Quality" makes the bricks look like it's got spikes shooting out of it. Combine that with the major frame rate boost, I think this should be applied to the engine code. Should enable me to come close to maxing the game out on my 2048 X 1536 display. Where did you find the engine code? Think I may have to snoop through to see if there's anything noob-friendly enough for me to tweak. You find the reflections shaders yet?

"Low Quality" looks just right. "High Quality" makes the bricks look like it's got spikes shooting out of it.

Thats becouse of bad data in the material, not the blame of the relief mapping code.

Combine that with the major frame rate boost, I think this should be applied to the engine code. Should enable me to come close to maxing the game out on my 2048 X 1536 display. Where did you find the engine code? Think I may have to snoop through to see if there's anything noob-friendly enough for me to tweak. You find the reflections shaders yet?

your/xonotic/git/path/darkplaces

if you just whanna fiddle with glsl, do a "r_glsl_dumpshader" you then have a default.glsl in "My documents/My Games/xonotic/data/glsl" (windows) or "~./xonotic/data/glsl" (lunix like os's). no need to change/recompile engine for that; vid_restart will be enough after changing that file (iirc).

Ah, cause that code is one big string in gl_rmain.c. Though recompiling the engine takes maybe 1 min. But that will be useful for tweaking the offset map, I think I understand the weird visual glitch from the offset map...It's running the stretch before it applies normal map and deluxe maps. Thus the texture is stretched but the normal map is not, though I'm not sure how it's affecting the iterations used, because it seems like the "shadow" from the normal map is duplicated with the iterations. Using only one iteration reduced the height of the effect.
BTW, looking at the way it was iterating 8 times extra, I can understand the random artifacts, it would over/underestimate the collision with the height map. I don't think the textures were the issue because the artifacts appear at every "sharp" edge on the relief map. The sharper the edge, the higher the number of artifacts.

Well unless my memory fails me, that texture does have a rather bad offset-map (alpha of _norm, usually). eg high contrast areas within the brick surface. The floor (that texture, btw had teh same spiky issue as the walls do before i fixed its _norm ; ) looks much brighter on the second shot, it that just another location or are your code accentually chancing the lightlevel too? Anyway, faster stuff is always nice, so keep up the good work =)

I added an extra iteration of jitter(check the OP, I edited the posted code.) and the result had the exact perfection of the original version of relief mapping when looking up close without any artifacts O_o... framerate was 62 so a loss of 7 fps and the gain of perfection, but 62 is still far better than 41 and firing the hagar with the Quad got my fps only down to 43! YAY!!!!

I changed camera angle in that shot...sorry But yeah, the spiky always bothered me with the relief mapping, I think you'll find the extra iteration of jitter extremely satisfactory.

"Low Quality" looks just right. "High Quality" makes the bricks look like it's got spikes shooting out of it.

Thats becouse of bad data in the material, not the blame of the relief mapping code.

Combine that with the major frame rate boost, I think this should be applied to the engine code. Should enable me to come close to maxing the game out on my 2048 X 1536 display. Where did you find the engine code? Think I may have to snoop through to see if there's anything noob-friendly enough for me to tweak. You find the reflections shaders yet?

your/xonotic/git/path/darkplaces

if you just whanna fiddle with glsl, do a "r_glsl_dumpshader" you then have a default.glsl in "My documents/My Games/xonotic/data/glsl" (windows) or "~./xonotic/data/glsl" (lunix like os's). no need to change/recompile engine for that; vid_restart will be enough after changing that file (iirc).

Hehe cool. Now I feel like I'm tech school again. I'm gonna have some fun breaking stuff. Maybe learn a thing or two while I'm at it.

will this ever be added to git?

I hope so, It solves an annoying problem...I do have a suggestion for development of it:
There needs to be a slider beside the "relief map" checkbox that allows you to select the level of jittering. Each step cuts the search in half which in turn reduces the size of "lighting" bands in half. 2 more steps than I currently have and the result would be a perfect relief map. The step value should be changed to .5 and the r_glsl_offsetmapping_scale cvar should be changed to 0.01. That would even things out. I believe the current heightmap created is from 0.0 - 1.0 so the first iteration searches "higher or lower" from exactly half and then the search is refined in half steps till we tell it to stop. Simply add in some if statements and link it with a cvar to allow us to disable any number of iterations from the menu. Because it's shader code, you wouldn't have to call vid_restart to see the changes. Man, I need to start my own engine testing branch, I'm enjoying this...

Three future projects I want to work on:
-Running offset mapping post-normal map to fix the shadow replication issue I've been seeing. Offset mapping should only iterate once, so the values need to be adjusted, though this may actually be the only problem, I'll be checking it.
-See if there is a way to improve the dynamic lighting performance...it's horrendous.
-Disable relief mapping and offset mapping in warpzones(menu option).

Edit:
I'm not sure why it was iterating through the heightmap 9 times in increments of 0.1...It was wasting shader cycles and produced strange artifacts. It really does work much better if the "divide and conquer" method is used, uses less cycles and looks far more accurate...

yeah, dynamic lights need to be improved.

also, it would be nice if some changes were made in netradiant so you could set up dynamic lights there and also maybe add some more functionality.

I would +1 your reputation again if I could -.-

i did this with your changes, and there are still artifacts; i dont notice any visual or fps-difference.

edit:

uhm.... yeah.

Did your recompile the engine? Or did you edit the default.glsl? You might not have edited the Cg section, and you could possibly be using that shader instead, in short, the screenshots you posted don't seem to show any of the changes, but the framerate difference I saw came when I had a realtime light source in the image and a warpzone, it showed improvement only under that load, which matters. Did you use the .5 Offset_Value and a r_glsl_offsetmapping_scale cvar of 0.01? That might do it, b/c I had a slight height loss from my quick guess offset_value of 0.375 and that might be removing the artifacts(from overshoot)

i'm sorry, i did something wrong. now i can see the difference, and there is also a fps boost. direct comparison:

without:

with:

without:

with:


first screenshot looks better with you changes, but second one is worse. i hope you can do something about that


i edited default.glsl and did r_glsl_restart after that, it only needs a second to restart it (thanks to divverent)

edit: i used the code you wrote in the first post, unchanged.

Yeah, I thought I lost some depth... I recommended it as more of a LQ option in the menu. To fix the depth issue, just change the Offset_Value to .5, the .02 cvar is correct. I was able to replicate your issue jaykay, but only with that texture(and it's circular cousin) As tzork stated, It might just be a heightmap quality issue. The 4th screenshots I posted(the square white tile) was the artifact fix I was talking about, it fixed that issue. Adding one more iteration dropped the framerate to 57 but the textures looked perfect. I don't think there is a way(that I know of, I might stumble on one) to fix that visual glitch besides refining the heightmap quality. I say it's a texture issue because rotating around it does not cause it to flicker or dissappear. If it was a relief map issue, it would most likely shimmer and move.

no, no more quality options, thats insane. no gamer wants to set the number of iterations of the relief mapping, almost noone even understands the difference between offset and reliefmapping (me included). please, no more options. enable/disable, thats the way to go.

i think the next step is fixing the heightmaps.... if you really think the remaining artifacts are a heightmap issue. it would be cool if you could find someone to do that.

Oh, no, it won't be labeled iterations, it would just be identical to the reflection slider, with these settings:
Poor, Good, Excellent, Extreme, Insane.
The current code is set at Excellent. You can get an idea of how it would scale, we would add 2 lines afterwards and limit them with if statements. That would make sense to the user, and it gives greater flexibility of framerate for those with higher end machines.

I'd fix the heighmaps, but I've never messed with textures, though apparently, not having tried it hasn't stopped me yet .

the current code is not excellent but produces artifacts:


your changes:

your changes produce new artifacts, but much less then teh old code. your code is in no way equicvalent to low quality, just as the current code is in no way equevalent to high quality. you can't tell me that that the overall result is worse with your changes.

still, i don't think anyone wants a slider for that. especially because relief mapping is a subtle effect which improves the overall visual feeling but which is not often seen "in detail" due to the fast gameplay.

it would be great if you could experiment some more with the code, apparently the artifacts can be influenced with the number of iterations. maybe there is a way to have no artifacts at all.

I think some of those artifacts come from not being .5 but instead being .375. It's clipping some of the heightmap b/c of that. If it's set to .5, it should be an accurate representation of the original code, if not better...hopefully How do you keep the camera in the same position?

Edit: Yeah, comparing your screenshots, it looks like the artifacts present on the brick wall are from using the .375 value, it's clipping the top of the heightmap. Setting that to .5 should solve that problem, but I bet it will add back the artifacts on the white stone tile. At least it's saving GPU time. The relief map will never be "artifact free" if it's not oversampled, which would run EXTREMELY slow. The render would have to take 16 times as long(4x oversampling would be the only workable difference). In essence, what it's rendering now is an Un AntiAliased render of a 3D mapped texture. It will always have the jagged edges. The only improvement the extra iterations add is smaller and smaller banding on the changes in height(e.g. the slope of it...I don't know any other way to explain it....) I think the main difference between the previous code and this is that I simply removed random extra steps, whether or not they fix the artifacting, I can't know for sure, I just based it on what I saw, but I also didn't have the right offset height either...now I do, it should be .5

How do you keep the camera in the same position?

as i said, modify default.glsl (this is the place where this uber-string is stored as code) and then do r_glsl_restart.

i have some time tomorrow and will try to understand those lines a bit and experimenting a bit with the values and iterations. master[mind], maybe you could go to the dev-irc channel, maybe we can experiment a bit together

i'm going to bed now

Hmmmm, while it fixed the strange artifacts present on the white tiles, it seems to be creating "holes"(small ones) in the brick texture on the wall of stormkeep, that needs to be investigated, it very well could be still clipping the texture. I don't fully understand the concept behind relief mapping, so I'm making more of an intelligent guess in my understanding of what exactly they're doing. I plan to break it down further till it makes sense.

BTW, I dumped the shader, wonderfully easier solution, thanks tZork!

I might know why the holes exist in the rendering. The previous technique had far less accurate, so the nearest neighbor sampling that relief mapping uses was picking up the wrong information both covering for the heightmap errors and producing the strange artifacts. If you compare the two images you most recently posted, you'll see that the new method has a less "pixelated" look to it, almost anti aliased. That's because instead of running both a linear and binary search on the same data(redundant) it runs a binary search only, but with much finer detail. Now, instead of running 9 stepped passes to get an estimate and then focusing in, it searches directly for the value by only focusing in. I found that at around 8-9 passes of jitter, the result is almost perfect, looks more like rendered polygons which is the goal.

umm... yeah. what do you mean with holes? and i think the main problem are the artifacts, which the "jitter"-calls can't resolve. someone in #darkplaces said that there will always be artifacts...

could you post the code which you think is the best? with the right amount of jitter, maybe with a comment that the last x jitter-passes are optional and yield a higher quality, and a height of .5?

edit: here is the code i use right now:

Code:

#ifdef USEOFFSETMAPPING_RELIEFMAPPING
    // 6 sample relief mapping: linear search and then binary search
    // this basically steps forward a small amount then jitters forward and back using decreasing
    // amounts to find the impact
    //vec3 OffsetVector = vec3(EyeVector.xy * ((1.0 / EyeVector.z) * OffsetMapping_Scale) * vec2(-1, 1), -1);
    //vec3 OffsetVector = vec3(normalize(EyeVector.xy) * OffsetMapping_Scale * vec2(-1, 1), -1);
    vec3 OffsetVector = vec3(normalize(EyeVector).xy * OffsetMapping_Scale * vec2(-1, 1), -1);
    vec3 RT = vec3(TexCoord, 1);
    OffsetVector *= 0.5;
    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.5;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.25;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.125;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.0625;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.03125;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.015625;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.0078125;
    return RT.xy;

this is functionally identical to the code master[mind] posted in the first post, except changing the height (0.375->0.5) to have the old height back and adding 2 jitter passes. the -0.5 comes from factoring out the last -0.5, -0.25 etc.

i would say the last 3 jitter passes could be optional as the difference is barely noticable, and only noticable at all if you take a close look at a texture, which wont happen often ingame.


maybe the artifacts can only be fixed by fixing the heightmaps, if at all.

master[mind], did you make any additional changes, and why is OffsetVector *= 0.5; correct? i don't get how you get from 9 passes -> 1 pass to 0.1 -> 0.5

I'm currently testing with this:

Code:

#ifdef USEOFFSETMAPPING_RELIEFMAPPING
    // 14 sample relief mapping: linear search and then binary search
    // this basically steps forward a small amount repeatedly until it finds
    // itself inside solid, then jitters forward and back using decreasing
    // amounts to find the impact
    //vec3 OffsetVector = vec3(EyeVector.xy * ((1.0 / EyeVector.z) * OffsetMapping_Scale) * vec2(-1, 1), -1);
    //vec3 OffsetVector = vec3(normalize(EyeVector.xy) * OffsetMapping_Scale * vec2(-1, 1), -1);
    vec3 OffsetVector = vec3(normalize(EyeVector).xy * OffsetMapping_Scale * vec2(-1, 1), -1);
    vec3 RT = vec3(TexCoord, 1);
    OffsetVector *= 1.0;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)          - 0.5);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.5    - 0.25);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.25   - 0.125);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.125  - 0.0625);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.0625 - 0.03125);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.03125 - 0.015625);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.015625 - 0.0078125);
    //RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.0078125 - 0.00390625);
    //RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.00390625 - 0.001953125);
    //RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.001953125 - 0.0009765625);
    return RT.xy;

The extra jitter calls are commented out.

Here's why the .1 to .5 to 1.0:

These lines:

Code:

"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"
"    RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);\n"

Essentially accumulate to 1.0 in steps of .1.

When you reduce it down to a single line(what I had been using and what you have posted) it accumulates to 1.0 in steps of .5.

I cut out every linear search step and just went straight to 1.0. No difference that I could tell, except maybe(but I'm not sure) a random lack of resolution in lighting quality. Here is an example of the holes I was referring to:

comparisons:

not better or worse, but still different:


the edges are not so rough but there are these holes:


the lower right part is way better, but again the holes


it gets worse here, the artifacts which were present before are now extremely visible


same here, the artifacts are better visible


again not better or worse, but different



i used the same code as yours (one binary search pass less)

Code:

#ifdef USEOFFSETMAPPING_RELIEFMAPPING
    // 6 sample relief mapping: linear search and then binary search
    // this basically steps forward a small amount then jitters forward and back using decreasing
    // amounts to find the impact
    //vec3 OffsetVector = vec3(EyeVector.xy * ((1.0 / EyeVector.z) * OffsetMapping_Scale) * vec2(-1, 1), -1);
    //vec3 OffsetVector = vec3(normalize(EyeVector.xy) * OffsetMapping_Scale * vec2(-1, 1), -1);
    vec3 OffsetVector = vec3(normalize(EyeVector).xy * OffsetMapping_Scale * vec2(-1, 1), -1);
    vec3 RT = vec3(TexCoord, 1);
    //OffsetVector *= 0.5;
    //RT += OffsetVector *  step(texture2D(Texture_Normal, RT.xy).a, RT.z);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.5;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.25;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.125;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.0625;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.03125;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.015625;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.0078125;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)-0.5) * 0.00390625;
    return RT.xy;

performance improvement: 10%-20%.


i don't know what should be done now... theres a good performance improvement but there are also new artifacts... but maybe they are a heightmap issue...