TSE Relief Mapping?

#21 Any possible way to get this down to 2.0?

#22 But on the other hand it would work with pixel shader 2.0a. But I don't know if you can select that specific shader version in TSE. Its possible it might be an option, but i didn't see it documented anywhere.

#23 Well from what was said, I wouldn't be able to use that either. Darn. Was dyin to try this out too.

#24 Well parallax and relief both can use the same source texture data... so it would be simple to have it use relief on 3.0 and 2.0a hardware and fall back to parallax for 2.0.

#25 Well that is what I was thinking. That's why I included all 3 shaders. ;)

#26 Oh wow, I was just about to do this, but it looks like Ray beat me to it... nice job Ray :)

#27 Very nice work!

#28 @Eric - It sounded like from your other post that you may have a different approach to relief or parallax shaders for the paper you are writing, so I for one would still like to see it, especially if you can get it down to PS 2.0.

@Tom and Ray - Now I don't know what a dependancy chain is, but is there anyway to encode the source data in a different way to get around this limitation so it will run on PS 2.0. Is it impossible to get around this "dependancy chain" problem at all? What's it all about?

Like a lot of people I only have PS2.0 as well (ATI Radeon 9800) and I was really looking forward to the precision that is made possible by relief, i.e. think protruding bricks, which from what I understand would look crappy under parallax mapping because of it's imprecise nature. Perhaps it's possible to increase the precision of parallax mapping? Again, sorry, I'm puzzled by why I can't have the precision, not due to the instruction limit, but due to this "dependancy chain" limit.

Cheers -- Tim.

#29 All I can think of is twisting my ankle when walking on those rocks :)

#30 @Tim - Steep parallax mapping is a 3.0 technique, but they say they have a 2.0 fallback that involves unrolling loops. It might be something to check out.

Also i noticed it claims to be better than relief mapping:

Quote:The main difference between Steep Parallax Mapping and Real-Time Relief Mapping is that Policarpo uses binary search. That gives a better appearance for smooth surfaces at slightly worse theoretical performance (the branch isn't very predictable in hardware). For thin, sharp features like hair and the raised text in the figures on our web page, binary search can miss the first intersection entirely and give incorrect results.

#31 @Tom - Thanks for this awesome reference Tom. If it was only for the PS2.0 fallback I would be excited, but with all the other features of their Steep parallax mapping and their screenshot comparisons, it's something I will gladly hold my breath for. Just imagine the level of detail that can be applied to a character using this sharp, detailed, self-shadowing technique and supporting PS2.0 as well as PS3.0. I just can't wait.

@Eric & Ray - Either of you guys think there is sufficient information in Tom's reference to Steep parallax mapping to get it working, and even working under PS2.0? Just wondering, sounds like you guys are the shader guru's here.

Cheers -- Tim.

#32 Awesome!!

#33 I personaly am not that impressed with steep parallax mapping. Steep parallax is just relief except they ditch the binary search step (which produces an image that looks like you took slices of a 3D object) and from what I understand they just smooth the normals to make the slicing artifacts less apparent. I think they word their poster to make it sound a little better than it really is, for example the line

For thin, sharp features like hair and the raised text in the figures on our web page, binary search can miss the first intersection entirely and give incorrect results.

what they should have said is "since both of our methods first use a linear search with the same step size, relief mapping can sometimes miss intersections on thin sharp features, if viewed at shallow angles (if the step size of the linear search misses these intersections). Our method however almost always misses the correct intersection as we don't have a binary search portion of our algorithm to find the exact collision point"

The main difference between the two methods is that steep is an approximation (like parallax) which does not find the correct results, but finds one thats usualy close enough that we can let it slide. Relief however always produces the correct 3D image (except for the shallow viewing angles where the initial linear search can sometimes miss intersections, which both methods suffer from). The benefit is that steep ditches the binary search portion which involves around 5 extra texture lookups per pixel and dynamic branching which is dependent on the results of previous itterations (both of which are very slow on the GPUs architecture).

I believe the reason why both methods are shader 3.0 is instruction size limit. Dynamic branching might also be a problem for relief mapping... I've got a 6800 so I've never really looked into the dynamic branching limitations on 2.0 hardware, from what I understand it has some kind of fake branching that doesnt really work for a lot of things... one of the big features in 3.0 is true dynamic branching (although its still slow). The main problem however is instruction size. Because in 2.0 there aren't real branches, there aren't real loops either I believe (keep in mind most of my experience is in 3.0, so I'm not completely sure). The compiler simulates looping by just unrolling the loops however this results in huge shader files which 2.0 can't handle... there are some cards that are 2.0 with large instruction sizes, but at that point you're just customizing a shader for a single card, which isn't really practical. There might be some kind of hack to get things working in 2.0 using multiple passes or something... I haven't really given it much thought since I've got a 3.0 card.

I'm afraid that my thing is also 3.0. It produces the same results as relief mapping just faster. I'm currently putting it into torque so I can make some nice screenshots for my paper (my testcube just wasn't flashy enough :-P). Once the paper is published I'm planning on making it available to everyone.

#34 @Eric - Ahhh... i think i've seen that "slices" artifact before in some parallax mapping demo. Although they can increase the number of slices and make it look better, it is still rather ugly in comparison to relief. In any case both methods work great in TSE.

#35 I've looked at both Steep Parallax and Relief, and in my opinion, the reflief mapping looks much better. The curved relief mapping looks even better than that, but it's probably pretty bad on performance.

#36 I looked into curved relief mapping. It wouldn't be hard to implement, but going by the demos it wouldn't look that much better. In fact when I ran the curved relief mapping demo, it looked the same as regular relief mapping to me. Although I am sure in certain cases it would look better. Going by the code in the demo, it would be a lot slower.

#37 The thing about curved releif mapping, is that it allows you to look at releif mapping from a profile viewpoint, and still see the distortion of the surface.
(actually, if you have properly setup textures, you could make highly complexe 3d models using a box and the textures with releif mapping, but that's something else)
I cant find the images right now, but curved releif mapping is actually quite a bit better visual quality wise, because it'll actually distort the surfaces and follow the releif mapping, even from a side view, or a extreme angle where it would normally fail.

If you can implement curved releif mapping, i very highly reccommend doing so, as it generally is alot better to look at. :P
(awsome work thus far btw :) )

#38 Woah neat...
Say goodbye to my 5900.... this is over the top as far as getting a 3.0 card. :)

#39 Heh....Nvidia should throw me a few bucks, if this is making people buy their video cards... ;)

#40 I'm still stickin with ATI.. But looks like I need to save for that x1800 now. heh