Relief Mapping - Performance Improvement - Beta v2

That's what I keep thinking, it's visible that the start of artifacts in the original code seems to be magnified in the newer one. So it may just be height map issues, or clipping issues, since it always appears at the top of the heightmap, we might want to see if it's a clipping issue, and yeah...that's why I'd like an option to pick the number of passes for the relief mapping in the menu, allows the user a little more flexibilty in framerate vs quality.

FruitieX, have you bothered with this at all yet? This is as far as I can get it, but with the performance difference, it would be nice to implement it, especially with a "quality" slider to set iterations(labeled poor, good, best, insane...etc) If you want me to integrate it, I can but I feel like I'd be...in the way if I start making commits, so I want to leave the true game code to y'all.

Well, I finally got around to it:


I used a lower number of iterations for that screenshot(check the FPS O_o) but with a nice high value, it's a perfect image. The bricks DID NOT fix themselves. There is some issue with the heightmap that stepping through the texture in a rather crude fashion seemed to fix. I'll look into the heightmap, but it's the only trouble texture. The problem was exactly what I thought it was. The interpolation on the heightmap at extreme angles was getting clipped. So increasing the search area past the actual 1.0 value fixed the issue. Here is the code:

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.2;
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z)          - 0.7);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.7    - 0.35);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.35    - 0.175);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.175    - 0.0875);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.0875    - 0.04375);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.04375    - 0.021875);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.021875    - 0.0109375);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.0109375    - 0.00546875);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.00546875    - 0.002734375);
    RT += OffsetVector * (step(texture2D(Texture_Normal, RT.xy).a, RT.z) * 0.002734375    - 0.0013671875);
    return RT.xy;

I know exactly why the offset mapping it messed up too. It only needs one sample, but it's being applied before the normal maps, shadow maps, specular, and cubemaps. That means the texture is stretched but the shaders are not. Initial attempts to fix it were...odd to say the least, but I'm going to keep plugging away at it.

This is with the code above(more iterations for quality):


I tested with a larger search area(2.0), but the...white tiled like texture showed brand new artifacts. I've found that if the texture repeats on a curved surface, a small viewing angle will make them appear to overlap in 3d, but that's not really a fixable thing. So....enjoy. I'll let you know how the height map editing works.

If you conclude that this is better than before, you should present it to divVerent and get it committed for sure! from what i can see it looks much better, great work!

Hmmm...found an article detailing the theory behind relief mapping, I'll move this back to beta...I have some new ideas.

Interesting book, GPU Gems 3 by nVidia. They have an entire chapter dedicated to relief mapping and cone step mapping. I'm thoroughly considering testing the cone step mapping, but ATM, I can explain the holes in the brick texture. The purpose for stepping through in a linear fashion and then doing a binary search is to keep the binary search from picking the wrong point. Reading the article would probably make better sense, but here is the jist. If, in tracing the ray, it intersects two points in the heightmap, than it's ambiguous which one should be used first. The linear search forces it to check the closest points first. Albiet, I think the original implementation was incorrect. I will step through the texture 9 times(or maybe 5) but the jitter will only be the width of a single step, not the entire 1.0 scale. That should reduce the number of jitter passes. So using 5 linear searches and 3-4 binary searches should help and still keep a better framerate. I'll test it this afternoon, as well as conestep mapping(which is amazing BTW O_o).

Bumping the thread. I think this would be a good idea to patch this into the next build of the game since it does drastically improve things.

Yeah, this was me not being familiar with the tech behind relief mapping. In removing the linear search, I allowed the relief shader to find more than one collision point. The reason there were holes in the brick was because it was finding the farthest point before the one the user was looking at. It's like rendering without using the Z axis. There is no real way to fix this without using the linear than binary search. I have an alternate option but it requires a completely new type of map: Cone Step Mapping. This would be generated either as the level loads or when the author builds the map. It is automated though as cone generation is not something a human could do. I'm still looking into it and will try some tests soon...*fingers crossed*

LordHavoc rejected these changes - he said that in his experience, more samples always yielded more quality, and also that people who don't want such a speed loss should use offsetmapping instead, which now "looks much better than before". And in fact, given the improvements on your screenshot - they come from something entirely different, namely you miscalculating the scaling factor (your 0.375 should actually be 0.5). In fact, you get the better visual quality than your "LQ" shots by using the current code and reducing r_glsl_offsetmapping_scale from 0.02 to 0.015. The current code cannot handle this situation:



as the following screenshots prove, which only differ by r_glsl_offsetmapping_scale:





This goes wrong because these situations cause texcoord discontinuities, causing texture2D() to pull from a texture at the wrong mip level. The result looks SOMEWHAT like aliasing, but at a higher size (namely, in 2x2 blocks). What helps is to use textureGrad() to force the "non-reliefmapping" mip level to be used, as these screenshots show:



BEFORE



AFTER


Other example:



BEFORE



AFTER


The fixed code can currently be retrieved in my divVerent/fix-reliefmapping branch. You can see the diff at http://git.xonotic.org/?p=xonotic/darkpl...iefmapping

I did not commit it yet to svn because nobody has tested the HLSL shader changes yet.

BTW: this fix is usually the very same speed as the old code. It could be faster with badly written GL drivers, as less derivatives are calculated in it.

As for proceeding further from here: I suggest that you "reboot" your efforts based on the code in the branch I made. And, you should always make sure your scale factor is correct. That way, we can make sure we do not mix different influences (like, your scale error "neutralized" the bug I fixed). Possibly, you can get a big improvement by changing the reliefmapping linear steps/binary search pattern.

Also, either way, cone step mapping would be welcome. But even in that case, better base your changes on my fixed code, as you will run into the very same issue with cone step mapping otherwise.

As for proceeding further from here: I suggest that you "reboot" your efforts based on the code in the branch I made. And, you should always make sure your scale factor is correct. That way, we can make sure we do not mix different influences (like, your scale error "neutralized" the bug I fixed). Possibly, you can get a big improvement by changing the reliefmapping linear steps/binary search pattern.

Also, either way, cone step mapping would be welcome. But even in that case, better base your changes on my fixed code, as you will run into the very same issue with cone step mapping otherwise.

Makes sense. Keep in mind, I dived into this head first with little knowledge of rendering techniques. I know coding, but not GLSL shaders. I'm doing my reading currently. But yeah, even with a steeper angle, I was still not including the linear stepping which prevents the holes I was getting in the texture.

BTW, my fix is now in master, and just is getting merged into div0-stable.

I now made cvars for the number of offsetmapping/reliefmapping steps (counting the binary search as a single step, though):

r_glsl_offsetmapping_steps
r_glsl_offsetmapping_reliefmapping_steps

We probably now just need to tune the defaults...

I now made cvars for the number of offsetmapping/reliefmapping steps (counting the binary search as a single step, though):

r_glsl_offsetmapping_steps
r_glsl_offsetmapping_reliefmapping_steps

We probably now just need to tune the defaults...

Sweet, I need to see how you linked those parameters. I'm glad you got some improvements in there.

Bumping this thread because I forgot where the offset and relief mapping shaders were.