Displacement maps

[Dade]

Added "bool dmnormalsmooth" option. It is true by default. It will interpolate normals helping to smooth the surface after the displacement.

"bool dmnormalsmooth" ["false"] "integer nlevels" [4]:

"bool dmnormalsmooth" ["true"] "integer nlevels" [4]:

(better but many artifacts because of the low mesh resolution)

"bool dmnormalsmooth" ["true"] "integer nlevels" [7]:

(better but there is still some artifacts because of the imagemap used as displacement map)

"bool dmnormalsmooth" ["true"] "integer nlevels" [7] (blured imagemap):

(nice very smooth, I exaggerated the blur just to highlight the effect)

[Karl vom Berge]

Nice start!

Displacement mapping by subdivision of geometry however, typically results in huge memory requirements. You can subdivide adaptively, based on an error metric defined in image space of the displacement map: http://www.cgl.uwaterloo.ca/Projects/rendering/Papers/dmap2.pdf

Another technique is to directly raytrace the displaced geometry, this technique might be interesting (I'm no expert in displacement mapping though ):

Direct Ray Tracing of Displacement Mapped Triangles by Brian Smits, Peter Shirley and Michael M. Stark.

Karl

[Lotuspec]

Another technique is to directly raytrace the displaced geometry, this technique might be interesting (I'm no expert in displacement mapping though ):

Direct Ray Tracing of Displacement Mapped Triangles by Brian Smits, Peter Shirley and Michael M. Stark.

I ported my pbrt implementation of this technique a few months ago but I did not find time to do extensive testing. The few test I did indicate that it is significantly slower than subdividing in a preprocess (though i do not have any concrete numbers as Lux lacks the statistics system from pbrt AFAIK), I could do some test with my older pbrt code. At oblique angles on surfaces with large displacements, the number of microtriangles tested (and texture lookups) is very high (could be up to O(N) for a quad, i.e. 2 triangles, implicitely subdivided in NxNx2 triangles). The advantage is obviously that memory usage is very limited and the subdivision level can be chosen for each ray.

I see 2 solutions to this:
- combine it with a regular subdivision:
first subdivide the triangles (ex. with the current method) to avoid large differences in displacements on a single triangle
This should be quite simple to implement.

- use some kind of hierarchical variant of the proposed algorithm:
do not immediately test the smallest level but use some levels in between to discard entire regions
This will probably require a bit more work and I'm not convinced yet that it will be really usefull. A initial subdivision in a preprocess will certainly be much faster at discarding parts of the triangle and memory usage should be acceptable

I was planning on trying both ideas out myself, but as I'm a student I just lack the time (exams etc.) for this until July.

Anyway, I'll see if I can do a simple comparison with the current disp. mapping implementation tonight. It will probably be a simple plane with a rocks displacement map but if someone can provide other geometry (couldn't get blender to export uv coordinates on the monkey) or displacement maps, I'll also test them.

[Dade]

Another technique is to directly raytrace the displaced geometry, this technique might be interesting (I'm no expert in displacement mapping though ):

Direct Ray Tracing of Displacement Mapped Triangles by Brian Smits, Peter Shirley and Michael M. Stark.

I ported my pbrt implementation of this technique a few months ago but I did not find time to do extensive testing. The few test I did indicate that it is significantly slower than subdividing in a preprocess

I have read the paper few days ago and I had the feeling the proposed solution was going to be a slower than just using plain trinagles+kdtree, nice to find some confirmation.

At the moment, I would like to add support for adaptive surface subdivision in order to reduce the amount generated triangles. Do you have any paper about this topic (Loop subdivision + displacement maps + adaptive) ?

I have a raw idea how it should be implemented but I'm not sure (i.e. adaptive subdivision of the Loop surface + displacement instead of adaptive subdivision of just the Loop surface alone).

Anyway, even if expansive from the memory point of view, Lux per-vertex displacement maps work quite well after the last improvement:

[Radiance]

Hey,

Nice work

I can't do any tests at the moment as i'm frantically trying to get this demo animation ready by tomorrow

Radiance

[Karl vom Berge]

I have read the paper few days ago and I had the feeling the proposed solution was going to be a slower than just using plain trinagles+kdtree, nice to find some confirmation.

Of course, most of the time with many algortithms, there is a trade of between speed and memory requirements. For future work we could e.g. have different displacement methods that are choosen dynamically given the specific host computer capabilities.

Still, for a production renderer, it is essential that the memory requirements for displacement mapping are kept minimal. Look e.g. at the features of Fry Render: http://www.fryrender.com/#product/features|f=material
I think they use a kind of REYES technique that is also used in Renderman, although I am not sure about this (isn't REYES patented?).

The original REYES technique is discussed in this ancient paper: http://graphics.pixar.com/Reyes/paper.pdf.

At the moment, I would like to add support for adaptive surface subdivision in order to reduce the amount generated triangles. Do you have any paper about this topic (Loop subdivision + displacement maps + adaptive) ?

You could use the gradient of the displacement map as a refinement oracle. This makes sense because you want more detail (triangles) in areas of the displacement map where intensity (greylevels) change quicky: e.g. on edges.

Also, the required detail is dependent on the viewing setting: for areas that are further away from the camera, you can do with less polygons than in areas closer to the camera.

I think you need some sort of combination.

Look at the other paper I referred to in my above post. They discuss adaptive refinement of the mesh for hardware rendering purposes, but I think the idea could be useful.

Karl

[Dade]

Still, for a production renderer, it is essential that the memory requirements for displacement mapping are kept minimal. Look e.g. at the features of Fry Render: http://www.fryrender.com/#product/features|f=material

They have a really nice material library, very impressive.

Bricked monkey:

[Dade]

A more bricked Monkey (image map + displacement map + bump map):

[jeanphi]

Hi,

Now that we have this feature, it might be nice if Radiance would rerender the frog with proper displacement mapping on the skin and rocks

Jeanphi

[Radiance]

sure,

i'll have a look in couple of days , still working on the animation demo for tomorrow

Radiance