Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Relief Mapping - Performance Improvement - Beta v2

#26
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.
Reply

#27
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.
Reply

#28
Well, I finally got around to it:
[Image: FixBeta-640x360.jpg]

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):
[Image: FinalFix-640x360.jpg]

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.
Reply

#29
If you conclude that this is better than before, you should present it to divVerent and get it committed for sure! Smile from what i can see it looks much better, great work!
There's nothing better than getting off you butt and contributing to a community. There is no excuse when it comes to computers. Spend a little of you playing time, giving back Smile
Reply

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

#31
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).
Reply

#32
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.
ECKZBAWKZ HUGE LIST OF ACHIEVEMENTS GOES HERE....


Oh wait.
Reply

#33
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. Tongue 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*
Reply

#34
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:

[Image: f00ce623ee2a07bc332d84224ea3c07d.png]

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

[Image: c7fbec102b101f6697b913e4a9f9f20d.jpg]
[Image: d37a09f3a95b35adf1f8350eab0a4dda.jpg]
[Image: 373174b077f4639b02b6f4f9c4b9dce5.jpg]

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:


[Image: ef582bc758d5966abb2e7b946f53954c.png]
BEFORE


[Image: 67d2c3a70e12e7a54c4f553f9d7fb25c.png]
AFTER


Other example:


[Image: 86c08a38ec75808b8dc26ccf89055fa5.png]
BEFORE


[Image: 9cb140aaf6ca7bc99a15cb85e6cdc56a.png]
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.
BRLOGENSHFEGLE (core dumped)

The Bot Orchestra is back! | Xoylent Easter Egg | 5bots1piano
My music on Google Play and SoundCloud
Reply

#35
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.
BRLOGENSHFEGLE (core dumped)

The Bot Orchestra is back! | Xoylent Easter Egg | 5bots1piano
My music on Google Play and SoundCloud
Reply

#36
(03-12-2011, 01:30 PM)divVerent Wrote: 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.
Reply

#37
BTW, my fix is now in master, and just is getting merged into div0-stable.
BRLOGENSHFEGLE (core dumped)

The Bot Orchestra is back! | Xoylent Easter Egg | 5bots1piano
My music on Google Play and SoundCloud
Reply

#38
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...
BRLOGENSHFEGLE (core dumped)

The Bot Orchestra is back! | Xoylent Easter Egg | 5bots1piano
My music on Google Play and SoundCloud
Reply

#39
(03-13-2011, 01:40 PM)divVerent Wrote: 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.
Reply

#40
Bumping this thread because I forgot where the offset and relief mapping shaders were.
ECKZBAWKZ HUGE LIST OF ACHIEVEMENTS GOES HERE....


Oh wait.
Reply



Possibly Related Threads…
Thread Author Replies Views Last Post
  Xonotic Game Engine, Mapping, Development - General Developer Questions p14r 6 10,218 08-04-2014, 10:24 AM
Last Post: p14r
  [SOLVED] misc_model : Support for specular and relief mapping? Maddin 5 6,572 11-10-2013, 06:34 AM
Last Post: Maddin
Exclamation Join the Xonotic mapping team Mirio 2 11,811 06-14-2013, 04:31 AM
Last Post: Maddin
  NVIDIA Delivers Massive Performance Boost to Linux Gaming CuBe0wL 20 18,179 11-13-2012, 10:13 AM
Last Post: Lee_Stricklin
  Mapping Tutorials hutty 57 44,381 08-31-2012, 11:43 AM
Last Post: aa
  Nextmap improvements / CA improvement prg319 9 10,956 07-07-2012, 09:37 AM
Last Post: prg319
Brick Proposal to change the mapping procedure for official Xonotic maps CuBe0wL 21 33,035 04-13-2012, 10:40 AM
Last Post: Samual
  Linux performance issues in Xonotic 0.6? Sarge999 3 5,356 04-04-2012, 09:43 PM
Last Post: edh
  My mapping ideas - pick one! CuBe0wL 28 30,578 07-07-2011, 06:48 AM
Last Post: CuBe0wL
Question Mapping with Blender? unfa 8 8,598 03-31-2011, 08:26 AM
Last Post: Sepelio

Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-