Displacement mapping with shaders

[Vadi]

I have a question: What techniques are used to do displacement mapping with shaders? I hadn't believed it's feasable until I saw screenshots of this. I stand corrected .

Thank you!


edit: One more question : Is it possible to do ambient occlusion with shaders?

 

[bloodbob]

I have a question: What techniques are used to do displacement mapping with shaders? I hadn't believed it's feasable until I saw screenshots of this. I stand corrected .

Thank you!


edit: One more question : Is it possible to do ambient occlusion with shaders?

Relief mapping I believe and it requires P3.0 capable hardware.

 

[Vadi]

Thanks a lot!

 

[Ostsol]

edit: One more question : Is it possible to do ambient occlusion with shaders?

Definitely. ATI has it in their Crowd demo.

 

[Vadi]

Cool! Thank you very much Ostsol!

 

[poly-gone]

What techniques are used to do displacement mapping with shaders

Simple displacement mapping is done by displacing each vertex of the mesh by a displacement value got by looking up a texture using that vertex's texture coordinates. This would take just 2 lines of shader code.

 

[Vadi]

Yes but I meant displacement via pixel shaders.

 

[991060]

There's a discussion about relief mapping in OpenGL.org's forum a while ago, I've cached some screenshots:

bumpmapping:

http://bbs.gzeasy.com/uploads/post-44469-1096730961.jpg

parallax mapping:

http://bbs.gzeasy.com/uploads/post-44469-1096730971.jpg

relief mapping:

http://bbs.gzeasy.com/uploads/post-44469-1096730981.jpg

the effect is stunning, yet the performance drop is also significant(relief mapping needs aroung 200 instructions in fragment program to work correctly).

BTW, the original discussion is here, in case you're interested in the detail:

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012454

 

[radar1200gs]

Pixel shader based "virtual displacement" mapping may be able to be used in many games on vertical surfaces, but it is no substitute for proper vertex displacement mapping.

Consider the example of a ball rolling down a rough road. With virtual displacement the ball will roll smoothly along no matter how rough the road gets or what obstacles block its path. Hardly realistic (lets not forget the physics engines being built into games nowadays to help realism).

With proper vertex displacement mapping the ball will be affected by the rough road since it is interacting with real, rough geometry, not a flat plane that simply looks bumpy.

 

[Para]

edit: One more question : Is it possible to do ambient occlusion with shaders?

Definitely. ATI has it in their Crowd demo.

3DMark03 pixel shader 2.0 test...

 

[Vadi]

I always thought this is all bumpmapping and relief mapping ain't possible.

 

[Ostsol]

Pixel shader based "virtual displacement" mapping may be able to be used in many games on vertical surfaces, but it is no substitute for proper vertex displacement mapping.

Consider the example of a ball rolling down a rough road. With virtual displacement the ball will roll smoothly along no matter how rough the road gets or what obstacles block its path. Hardly realistic (lets not forget the physics engines being built into games nowadays to help realism).

With proper vertex displacement mapping the ball will be affected by the rough road since it is interacting with real, rough geometry, not a flat plane that simply looks bumpy.

That which is rendered and that which is used by the physics engine need not have anything in common with each other. Anyway, the geometry created by displacement mapping is generated dynamically, never passing the AGP/PCI-Express bus; and the collision hull's geometry must be static or generated in software. Because of this it makes no difference whether vertex or pixel displacement mapping is used. The same data may be used for collision either way.

 

[bloodbob]

relief mapping:

http://bbs.gzeasy.com/uploads/post-44469-1096730981.jpg

the effect is stunning, yet the performance drop is also significant(relief mapping needs aroung 200 instructions in fragment program to work correctly).

BTW, the original discussion is here, in case you're interested in the detail:

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012454

100Fps on current tech I probably wouldn't call it significant ( yeah I do realise its only one quad ).

 

[hovz]

Pixel shader based "virtual displacement" mapping may be able to be used in many games on vertical surfaces, but it is no substitute for proper vertex displacement mapping.

Consider the example of a ball rolling down a rough road. With virtual displacement the ball will roll smoothly along no matter how rough the road gets or what obstacles block its path. Hardly realistic (lets not forget the physics engines being built into games nowadays to help realism).

With proper vertex displacement mapping the ball will be affected by the rough road since it is interacting with real, rough geometry, not a flat plane that simply looks bumpy.

That which is rendered and that which is used by the physics engine need not have anything in common with each other. Anyway, the geometry created by displacement mapping is generated dynamically, never passing the AGP/PCI-Express bus; and the collision hull's geometry must be static or generated in software. Because of this it makes no difference whether vertex or pixel displacement mapping is used. The same data may be used for collision either way.

wrong again radar!!!

 

[radar1200gs]

Not wrong.

You use vertex based collision and feed the rsults of that into your physics engine.

 

[bloodbob]

wrong again radar!!!

If you want visually acurate physic it does matter I guess. If you don't care about visually accurate physics it don't matter.

 

[bloodbob]

Not wrong.

You use vertex based collision and feed the rsults of that into your physics engine.

You said VERTEX or PIXEL.
If your feeding the results into your physics system its going to have to cross the bus on the way back isn't it? So now you definately are wrong.

 

[Ostsol]

Anyway, it's much more efficient and accurate to have a separate collision hull that stays in system RAM and is static. It avoids needlessly using the bus and collision is the same regardless of visual LOD.

 

[Ostsol]

relief mapping:

http://bbs.gzeasy.com/uploads/post-44469-1096730981.jpg

the effect is stunning, yet the performance drop is also significant(relief mapping needs aroung 200 instructions in fragment program to work correctly).

BTW, the original discussion is here, in case you're interested in the detail:

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012454

100Fps on current tech I probably wouldn't call it significant ( yeah I do realise its only one quad ).

One quad, yes, but it's the fillrate that matters. I imagine that using such a technique would warrant an initial z-only pass to help eliminate overdraw.

 

[radar1200gs]

Not wrong.

You use vertex based collision and feed the rsults of that into your physics engine.

You said VERTEX or PIXEL.
If your feeding the results into your physics system its going to have to cross the bus on the way back isn't it? So now you definately are wrong.

No, I did NOT say vertex or pixel.

The only time I mentioned "pixel" was in relation to virtual displacment mapping, which I said was mostly suitable for vertical surfaces (since most in game objects will walk or roll along a horizontal surface).

Learn to read.

EDIT:
Before the next terminally thick idiot posts a smart-arsed reply, "virtual displacement mapping" means any method that attempts to visually fake real vertex based displacement mapping.