[TUTO] Vertex Displacement Mapping (english)

[JeGX]

The topic about Vertex Displacement Mapping tutorial is opened.

I haven't had the chance yet to test displacement mapping on ATI Radeon X1800 or X1900. If you've got this kind of videocard, don't hesitate to post your experimentation (works, does not work...).

[ozzy]

I have a GeForce 6800, and I tried loading the DEMO_displacement_mapping.xml into hyperion.

I get the wireframe, textured, but it is not displaced (nothing in the up/down axis).  Its perfectly flat.

Any ideas what could be wrong? I ran the Hardware Info program, it shows it correctly as Model: GeForce 6800/PCI/SSE2

I have the nVidia 91.31 driver version.

Thanks for any help!

[JeGX]

Yes mate, there is a problem. On my gf6600 and my gf7950, the displacement mapping doesn't work anymore. I'm going to track down the bug now...

[JeGX]

Ok I think I found the problem comes from nVidia drivers 91.xx and 93.xx series. I've done several tests with several drivers and here are the results:

Forceware 84.21 WHQL (http://downloads.guru3d.com/download.php?det=1353)
7950 GX2 --> not supported in these drivers
6600 GT  --> vertex displ. mapping works fine

Forceware 93.71 WHQL (http://downloads.guru3d.com/download.php?det=1509)
7950 GX2 --> vertex displ. mapping does not work
6600 GT  --> vertex displ. mapping does not work

Forceware 96.89 beta (http://downloads.guru3d.com/download.php?det=1505)
7950 GX2 --> vertex displ. mapping works fine
6600 GT  --> vertex displ. mapping works fine

The bug seems to affect the texture fetching in GLSL only.  I ran the sample shipped with the nv sdk and it works fine. This sample has been coded in asm.

Conclusion: install the Forceware 96.89 beta drivers  :wink:

[ozzy]

Thanks for narrowing that down. I can't believe vertex texture fetches have been "broken" in the drivers for what, 3-4 versions?!  I have a sneaking suspicion that vertex texture fetches do work in GLSL, but that maybe we're doing something unsafe that some drivers weren't catching or compensating for. Just an unfounded guess.

Yes, the nVidia example works for me too, which supports your GLSL vs assmebly theory. ;-)

The strange thing though is that this guy's sample (see link below) also doesn't work, and I think his shader is in assembly as well.

http://www.nvnews.net/vbulletin/showthread.php?t=49867

BTW, can you tell me what is the difference between a Vertex Shader and a Vertex Program? The terminology is confusing, they seem to be used interchangeably.

Thanks. :-)

[JeGX]

Vertex texture fetching is a feature that is not widely used in graphics programming. So a bug in the vertex texture fetching module could easily go unnoticed. But you're right, there's maybe a sequence of instructions in Hyperion that makes drivers go down. I don't know.

I tested Abba Zabba's demo last year and it worked fine.

You're a lucky guy: in the next few days I will publish a big tutorial about the 3d pipeline of SM3/DX9 GPUs where you will find the answer to your question. Stay tuned!

[ozzy]

Thanks JeGX.  All I can say is:       I imagine there are a lot of companies staying away from these "cutting edge" features that are only quasi-supported in the drivers.   Or maybe they're all using DirectX, which probably/might work better than GLSL?  Who knows.  The number of hours I've wasted on stupid $#@ is mind boggling....  :?

[JeGX]

The tutorial about SM3/DX9 GPUs is online: 3D Pipeline of SM3/DX9 GPUs
Enjoy!

[ozzy]

Great tutorial! Thanks!

Hey, so I tried the vertex displacement demo again, without the latest beta driver you suggested (the beta driver has some bug in it that broke something else of mine).

Anyway, as you know, the DEMO_displacement_mapping.xml scene didn't work, but the DEMO_bump_displacement_mapping.xml scene *did* work.  (at least looks that way to me).  

You probably would like your displacement-only demo to work on as many drivers as possible, so it would be interesting to see what you're doing different in the bump-displacement vertex shader that is causing the driver to be OK.

I might try narrowing it down by slowly removing the differences and see what makes the difference. If I find anything I'll let you know

[ozzy]

Well, I made a discovery which only adds to the confusion.

It *is* possible to do get the example to work under the non-beta drivers, by simply using the colorMap texture unit to look up the displacement instead of the displacementMap one. (i.e., dv = tex2D_bilinear( colorMap, gl_MultiTexCoord0.xy ); However, the frame rate drops to about 2 frames  a second, which makes me think the driver is switching to software mode internally.  

Ultimately, is what you said, which is it *seems* to be a GLSL bug.  My guess is that its not really flipping into ShaderModel 3.0 mode correctly. Its still in SM 2.0 for some reason. If I was super-fluent in opengl Assembly, I would translate it and see it in action.  I guess my next step is to learn OpenGL Assembly.