Per-Pixel Displacement Mapping with Distance Functions...

[j^aws]

Per-Pixel Displacement Mapping with Distance Functions

William Donnelly University of Waterloo

In this chapter, we present distance mapping, a technique for adding small-scale displacement mapping to objects in a pixel shader. We treat displacement mapping as a ray-tracing problem, beginning with texture coordinates on the base surface and calculating texture coordinates where the viewing ray intersects the displaced surface. For this purpose, we precompute a three-dimensional distance map, which gives a measure of the distance between points in space and the displaced surface. This distance map gives us all the information necessary to quickly intersect a ray with the surface. Our algorithm significantly increases the perceived geometric complexity of a scene while maintaining real-time performance.
...

More here...

http://download.nvidia.com/developer/GPU_Gems_2/GPU_Gems2_ch08.pdf

Sorry, I haven't been following what games use what techniques but any games out there using the above? If not can we expect any in the near future, e.g. next gen consoles?

 

[Inane_Dork]

On consoles? My initial impression is that no, you won't see it on consoles. 3D textures are pretty hard to justify on memory-bound consoles.

 

[j^aws]

VTC...3D texture compression?...Procedural 3D textures?

http://www.beyond3d.com/articles/3dtextures/index6.php

 

[bloodbob]

VTC...3D texture compression?...Procedural 3D textures?

http://www.beyond3d.com/articles/3dtextures/index6.php

Most hardware doesn't support VTC and well the whole point of the 3d texture is because its precomputed and doing it potentially many times at run time sort of defeats the purpose.

 

[corysama]

Re: Per-Pixel Displacement Mapping with Distance Functions..

Per-Pixel Displacement Mapping with Distance Functions

http://download.nvidia.com/developer/GPU_Gems_2/GPU_Gems2_ch08.pdf

Sorry, I haven't been following what games use what techniques but any games out there using the above? If not can we expect any in the near future, e.g. next gen consoles?

Non-trivial 3D textures have been infeasible because they don't scale well. Memory usage = level of detail^3. This technique is nice because it doesn't try to be ^3, instead it just puts a thick layer of texture on the surface. It ends up being (memory = detail * ~16). Multiplying your memory requirements by 16 or 32 is still kinda hard to swallow though. You have to choose between 16 normal objects or one fancy object.

I do expect parallax mapping to become fairly standard on games that utilize PS2.0 or higher. It's so damn cheap and easy that there isn't much excuse not to use it. Although the technique in the article gives a more "correct" appearance, paying 1600% or 3200% the resources for a small% better look is rarely a good idea.

 

[davepermen]

the 3d texture only stores distances, not colours, so only 8bit per texel needed.. so the 16 layers only need 16bytes, thats 4times as much as an ordinary colormap (4bytes).

still much, but not _that_ much.

the technique is very nice, and will definitely find its uses. at places, where parallax mapping isn't enough. i'm thinking of the detailed small objects you can find in levels (boxes, and all the stuff), wich will involve tons of instancing anyways..

or an asteroidfield (sorry, the term instancing inspired me) could possibly use this technology, too ..

one big feature of the technique is the adjustability. more memory? faster tracing? you can always adjust.

 

[bloodbob]

Exactly how fast is this shader anyway? I would be surprised if its much more then twice as fast the method from opengl which raytraces with precomputing.

 

[KimB]

Well, it looks like the shader can't reject pixels, so it's still a virtual displacement mapping technique. But it looks like it's a higher-quality version than the parallax mapping technique.

 

[davepermen]

it is just another raytracer. the trick is, all they focus on, is a fast, and reliable way to intersect the heightmap, with no chance to miss anything, and stay accurate all the time.

thats all. the rest, pixel discarding, and all the fuzz that popped up on the web to show correct silhuetes is still possible. it's just another solution to trace the ray onto the surface. an accurate way that works all the time, or so

 

[William Donnelly]

I'm glad you guys were interested by the chapter. I'll see if I can address some of your questions.

The space requirements aren't as severe as you might think when you hear "3d texture". It's monochrome 8bits/channel, and typically half the resolution of a color texture, so really its about the same cost as an uncompressed color texture.

As for texture compression, I dont know of any formats that work for monochrome 3d textures. Although if such a scheme were available, the data would probably compress very well since the 3d texture is extremely smooth.

I've spoken a bit to Fabio, who posted his ray tracing shader on opengl.org. My impression is that this technique is faster (the shader is quite a bit shorter), but I havent done any proper benchmarks. The performance results were actually quite good for geforce 6 series, but it might be a bit much for fx cards. I havent written a multipass version to test performance on ati.

Although it doesn't handle silhouettes, it certainly can be extended to do so. It poses some problems for quadric curvature approximation trick because you would have to perform a parabola-sphere intersection instead of just a ray-sphere intersection. But ultimately I dont think the parabolic trick is useful anyway (See my reply to Fabio on opengl.org under the name pragma).

I haven't heard from any current game developers who are using the technique, since it's so new. As for whether it can be supported on consoles, the main obstacle there would be the dependent texture reads. Since ATI cards don't have dependent texture reads currently, its possible that their future console chips wont be able to support it. Although its probably just too heavy for current consoles, I think it may be ideal for future ones.

 

[Hyp-X]

Since ATI cards don't have dependent texture reads currently,

 

[William Donnelly]

Since ATI cards don't have dependent texture reads currently,

Right ... I should clarify that. They do allow you to write shaders with dependent texture lookups, but my understanding is that they are not supported directly within the hardware and the shaders are internally multipassed somehow. So in practice, they allow a limit of something like 4 levels, which isn't enough for this technique.

 

[Hyp-X]

Right ... I should clarify that. They do allow you to write shaders with dependent texture lookups, but my understanding is that they are not supported directly within the hardware and the shaders are internally multipassed somehow. So in practice, they allow a limit of something like 4 levels, which isn't enough for this technique.

Oh, yeah that's dependent read limit.
Fortunately PS3.0 specifies that there can be no dependent read limit, so both R520 and XBOX2 should be fine.

Thanks for the clarification.

 

[j^aws]

I'm glad you guys were interested by the chapter. I'll see if I can address some of your questions.

The space requirements aren't as severe as you might think when you hear "3d texture". It's monochrome 8bits/channel, and typically half the resolution of a color texture, so really its about the same cost as an uncompressed color texture.

As for texture compression, I dont know of any formats that work for monochrome 3d textures. Although if such a scheme were available, the data would probably compress very well since the 3d texture is extremely smooth.

I've spoken a bit to Fabio, who posted his ray tracing shader on opengl.org. My impression is that this technique is faster (the shader is quite a bit shorter), but I havent done any proper benchmarks. The performance results were actually quite good for geforce 6 series, but it might be a bit much for fx cards. I havent written a multipass version to test performance on ati.

Although it doesn't handle silhouettes, it certainly can be extended to do so. It poses some problems for quadric curvature approximation trick because you would have to perform a parabola-sphere intersection instead of just a ray-sphere intersection. But ultimately I dont think the parabolic trick is useful anyway (See my reply to Fabio on opengl.org under the name pragma).

I haven't heard from any current game developers who are using the technique, since it's so new. As for whether it can be supported on consoles, the main obstacle there would be the dependent texture reads. Since ATI cards don't have dependent texture reads currently, its possible that their future console chips wont be able to support it. Although its probably just too heavy for current consoles, I think it may be ideal for future ones.

Neat. So how long did it take you to develop the technique? And when you develop a technique, can you call it what you want...I mean 'Per-Pixel Displacement Mapping with Distance Functions' doesn't exactly roll off the tongue! ...Is 'Distance Mapping' it's official name?

 

[William Donnelly]

Probably a month or two if you count all the time researching, implementing other peoples ideas and developing alternative methods that didn't work.

I like to call it Distance Mapping. The name has been used before (as the process of generating a distance map from an arbitrary isosurface), but I dont feel too bad stealing it. If normal mapping is the algorithm that uses a map containing normals, then I guess an algorithm that uses a map of distances is Distance Mapping.