Let me be the first to say that your bumpmapped wall looks incredible. It's hard to believe that only 2 triangles are used on it.

i do not know how it functions, but when i read it runs at 30 fps then you could also say it is incredible slow for just two triangles ;-)

Yea, but thats all in the pixel shader, so theoreticly you could do the same to thousands (ignoring overdraw, which could be a bit of a problem).

Mm.. I'd love to see a running demo. (Btw, the article linked was dated April 1st ? =)

Very interesting.
I've tested this bump method with your bitmaps and with 5 steps (N=5) I can see brutals steps on the image... I can't use more than 5 steps on my 9700 pro.

How many steps do you use to render these screen-shots ? (what is the value you use for "N")

Thanks.

Pacôme

Makes me wonder if you could get 30fps on a 6800 rendering it as geometry :)

I take it you've all seen these threads?
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012454
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012842

..where you see the evolution of this algorithm, and much more.

One nice advantage of per-pixel techniques is that you automatically get LOD for free.

Max

Exactly. Ideally you lay down a fast z-only pass and then have zero overdraw. 30 fps is fine since it is fill-rate bound; the CPU and vertex shader are literally doing nothing and available for work.

Thanks!

-m

I rendered the wall with N = 20 for the bumps and N = 40 for the shadows. After reading Tatarchuk's GDC talk I switched my implementation to:

numSteps = 10;
numSteps = mix(numSteps*2, numSteps, tsE.z);

where tsE is the normalized tangent space eye vector, so tsE.z = N dot E. This is faster without sacrificing fidelity.

-m

I'm familiar with Policarpo's work, which was formally presented this morning at I3D. He gets very nice results, and the two-sided relief map is also a good idea.

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. Because this is a case we care about particularly, we instead use mip-map LOD to guarantee sampling at the Nyquist rate. Since the texture reads are all adjacent and not dependent, they are performed very quickly from cache and the net result for our technique is high performance.

-m

When you mention anti-aliasing, are you using super-sampling? If so that would explain the performance, but I'm wondering how the effect looks without that. Are there noticable artifacts, etc? To my knowledge ATI cards do not currently support super-sampled anti-aliasing.

I suspect that you limit to 5 steps is due to the maximum of 4 dependent texture reads on ATI cards.

I mean 'FSAA'.

-m

Yeah, but there are several ways to implement "full-scene anti-aliasing", including but not limited to super-sampling (rendering a larger image and downsampling) and multi-sampling (the more common on modern hardware). The latter would produce no benefit for a shader since it effectively only anti-aliases edges, while the former would reduce "shader aliasing" as well.

Thus my question of whether or not the FSAA is multisampling (effectively not making any difference to the image quality here), or supersampling (in which case I'd like to know how much of a difference it is making).

I'm running on NVIDIA hardware, and it appears to actually run the fragment shader multiple times per output pixel. High frequency shading problems are corrected, dramatically reducing the noise and undersampling typically associated with pixel ray-tracing approaches. At 8x it looks gorgeous, at 4x it looks reasonable, 2x is noisy, and with no FSAA the noise is unacceptably bad. Of course, an alternative is to leave FSAA off and perform 4x as many ray casts inside the pixel shader.

-m

Thats quite cool.

I remember doing a similar thing a couple of years back, but ended up running into problems with the limitations of PS 2.0. You could only do 8 or so texture lookups and it just wasn't really looking good enough, especially really low viewing angles or when the bump map is high contrast.

Unfortunatly, I ended up deciding the performance hit wasn't worth it for what I was doing, and focused on writing up a shadow volume related paper.
I dont' actually have the shaders any more, but I think I was doing a number of texture lookups at varying depths, then using a couple of dependant reads to try and get a better result. Honestly don't remember exactly.

I was getting around the lack of real branching by using hacks with any() and the like.

I did post about it though: (I think this was using 5 layers)
http://www.gamedev.net/community/forums/topic.asp?topic_id=192321&whichpage=1��;

It's an interesting tech, and the shadows certainly make it looks a lot better, but it still isn't something thats quite ready for the hardware. Sortof ironic I guess, nice change with software leading hardware.


It will be interesting to know what sort of performance you end up getting on a R520 (x900?) when they come out in the next few months. Apparently they do full speed branching - so maybe binary search based will end up considerably faster?

Anyway good work.


come to think of it,
I've actually remember seeing paralax mapping done on a radeon 8500 _way_ back before even the 9700 came about, but it was definitly not all that flexible. Good old PS 1.4... :)