Displacement Mapping and Voxels
by MK · in General Discussion · 05/14/2002 (3:10 pm) · 5 replies
This displacement mapping stuff from Matrox looks pretty cool. Since current hardware or that in the near future don't support voxels, can the same effect be achieved using Displacement mapping in conjunction with Rendering to textures.
So you have you're displacement map generated terrain. Someone just drops a big bomb [we're not discussing the reason :)]. You calculate the changes to the terrain and render that into your displacement map and the visual texture.
Does that sound like how things can be done? Does it sound computationaly viable? Am I just muttering rubbish?
Also, does anyone have any idea of how big of a texture file can be loaded just for the terrain. How would it compare against a polygonal or a curve model?
Ofcourse I know it would be useless in current generation of cards, its just a technology discussion here.
So you have you're displacement map generated terrain. Someone just drops a big bomb [we're not discussing the reason :)]. You calculate the changes to the terrain and render that into your displacement map and the visual texture.
Does that sound like how things can be done? Does it sound computationaly viable? Am I just muttering rubbish?
Also, does anyone have any idea of how big of a texture file can be loaded just for the terrain. How would it compare against a polygonal or a curve model?
Ofcourse I know it would be useless in current generation of cards, its just a technology discussion here.
#2
I think HDM will be pretty sweet. It looks like a natural extention of displacement mapping and GPU-based extra tesellation (NPatch, etc..). So, if you push a displacement map on a poly, think about it as a 'texture map' on the poly.
So, wherever the center of the displacement map texel occurs, the GPU will generate a new vertex and link it into the mesh.
It also looks like they're patenting some CLOD for the mesh generation (this is good news.. I've been pushing for CLOD for a long time). I'm interested to find out which CLOD algorithm they chose for hardware.
The overall savings here is that you're pushing a low-poly mesh (say 4 vertices and 6 indices = 60 bytes) and a displacement map (say 32x32x8 bits = 1024 bytes) instead of a hi-res mesh (32x32 vertices + 1024 indices = 14336 bytes).
On next-generation hardware, this is really going to push the envelope for detail. Support for higher-res displacement maps AND higher-res models will generate exponential increase in detail levels with only geometric increase in bandwidth. This is a Good Thing (TM).
--Bryan
05/15/2002 (12:41 pm)
Sander,I think HDM will be pretty sweet. It looks like a natural extention of displacement mapping and GPU-based extra tesellation (NPatch, etc..). So, if you push a displacement map on a poly, think about it as a 'texture map' on the poly.
So, wherever the center of the displacement map texel occurs, the GPU will generate a new vertex and link it into the mesh.
It also looks like they're patenting some CLOD for the mesh generation (this is good news.. I've been pushing for CLOD for a long time). I'm interested to find out which CLOD algorithm they chose for hardware.
The overall savings here is that you're pushing a low-poly mesh (say 4 vertices and 6 indices = 60 bytes) and a displacement map (say 32x32x8 bits = 1024 bytes) instead of a hi-res mesh (32x32 vertices + 1024 indices = 14336 bytes).
On next-generation hardware, this is really going to push the envelope for detail. Support for higher-res displacement maps AND higher-res models will generate exponential increase in detail levels with only geometric increase in bandwidth. This is a Good Thing (TM).
--Bryan
#3
I agree it looks absolutely sweet :) I know you've been around CLOD for a long time and I know your work (see my article on Lone Wolves). Hope you don't mind I used your CLOD demo :) so here 3 questions for you I hope you can answer on HDM.
1) Games are usually based on rules. Eg, can't walk up a slope more than 35 degrees. If I want to create a small winding path up a mountain, how will I generate such a terrain? It seems extremely hard because it all gets tesslated so much. Could be that the path gets blocked or the mountains get walkable.
2) To extend on the path example: How can I specify different textures for the path (eg sand, while the mountains are rocks with snow peaks)? Can all this be done via shaders?
3) Matrox claims HDM makes bumpmapping redundant. I disagree since you cannot let HDM tesslate every tiny detail into infinity (yet!) like their golf ball in the white paper. If I want to generate HDM terrain can I use bumpmapping on it (or any other multipass algorithm for that matter)?
If these 3 are all YES then i'll be convinced HDM is the way to go (erm... maybe speed would be an issue but I gather they'll make it darn fast!).
Hope you can help
- An eye for an eye will make the world go blind -
05/16/2002 (12:41 am)
Bryan:I agree it looks absolutely sweet :) I know you've been around CLOD for a long time and I know your work (see my article on Lone Wolves). Hope you don't mind I used your CLOD demo :) so here 3 questions for you I hope you can answer on HDM.
1) Games are usually based on rules. Eg, can't walk up a slope more than 35 degrees. If I want to create a small winding path up a mountain, how will I generate such a terrain? It seems extremely hard because it all gets tesslated so much. Could be that the path gets blocked or the mountains get walkable.
2) To extend on the path example: How can I specify different textures for the path (eg sand, while the mountains are rocks with snow peaks)? Can all this be done via shaders?
3) Matrox claims HDM makes bumpmapping redundant. I disagree since you cannot let HDM tesslate every tiny detail into infinity (yet!) like their golf ball in the white paper. If I want to generate HDM terrain can I use bumpmapping on it (or any other multipass algorithm for that matter)?
If these 3 are all YES then i'll be convinced HDM is the way to go (erm... maybe speed would be an issue but I gather they'll make it darn fast!).
Hope you can help
- An eye for an eye will make the world go blind -
#4
Nice BFTerrain article :) Looks good. My new e-mail addy is "bryan.turner@pobox.com", if you want to update the link. I also run a website with my projects at "http://www.fractalscape.org".
As for HDM:
1) HDM is more of a 'detail' item, like texture mapping, not a rules-based element. While it seems possible to render an entire terrain via HDM, I believe this would be a waste. Combining smart use of CLOD with HDM will bring you incomparable detail, but still work well with existing rules systems. Basically, the answer here is for the rules to read from the height map directly and not the CLOD/HDM mesh. Not sure if this is the answer you're looking for though.
2) HDM does not change the texture mapping.. so you can't arbitrarially paint a texture over a poly without using some other per-pixel feature (such as stipple buffer or an alpha channel). You're still limited by the API here... but no differently than you were before HDM. So your path example: use stipple buffer to achive this effect.
3) I would agree with Matrox. Bump mapping is dead if you have HDM. That doesn't mean you CAN'T use bump mapping. I can forsee a time where you would use CLOD for distance-viewing, HDM for mid and close viewing, and bump mapping with close viewing for true deep-detail effects. However, if they allow mip-mapping of HDM, then bump mapping becomes useless (why use a trick when you can have the real thing?).
--Bryan
05/16/2002 (10:59 am)
Sander,Nice BFTerrain article :) Looks good. My new e-mail addy is "bryan.turner@pobox.com", if you want to update the link. I also run a website with my projects at "http://www.fractalscape.org".
As for HDM:
1) HDM is more of a 'detail' item, like texture mapping, not a rules-based element. While it seems possible to render an entire terrain via HDM, I believe this would be a waste. Combining smart use of CLOD with HDM will bring you incomparable detail, but still work well with existing rules systems. Basically, the answer here is for the rules to read from the height map directly and not the CLOD/HDM mesh. Not sure if this is the answer you're looking for though.
2) HDM does not change the texture mapping.. so you can't arbitrarially paint a texture over a poly without using some other per-pixel feature (such as stipple buffer or an alpha channel). You're still limited by the API here... but no differently than you were before HDM. So your path example: use stipple buffer to achive this effect.
3) I would agree with Matrox. Bump mapping is dead if you have HDM. That doesn't mean you CAN'T use bump mapping. I can forsee a time where you would use CLOD for distance-viewing, HDM for mid and close viewing, and bump mapping with close viewing for true deep-detail effects. However, if they allow mip-mapping of HDM, then bump mapping becomes useless (why use a trick when you can have the real thing?).
--Bryan
#5
I was wrong :) Thanx for clearing it up.
Oh, and I've updated the article with your new e-mail adress and URL. Very nice site you have.
- An eye for an eye will make the world go blind -
05/17/2002 (12:56 am)
Yep, those were exacly the answers I was looking for. I thought HDM would be used to generate all the terrain by itself, outdating pretty much any CLOD, ROAM, BF and what-ever-more terrain algorithms out there. I didn't consider it to be more directed toward detail.I was wrong :) Thanx for clearing it up.
Oh, and I've updated the article with your new e-mail adress and URL. Very nice site you have.
- An eye for an eye will make the world go blind -
Sander "Tweety" Mar
On the other hand, I'm still not totally convinced about HDM. Especially about fine control over the final tesslated mesh and about texturing it all. I'm still waiting for the TechSpecs to prove me wrong.
Does anybody know if OpenGL 2.0 is going to support HDM as well (DirectX 9.0 will).
- an eye for an eye will make the world go blind -