POV-Ray : Newsgroups : povray.general : Feature Requests - Normal Map and Displacement Map Support : Re: Feature Requests - Normal Map and Displacement Map Support Server Time
31 Jul 2024 18:27:59 EDT (-0400)
  Re: Feature Requests - Normal Map and Displacement Map Support  
From: Thorsten Froehlich
Date: 24 Oct 2006 13:05:38
Message: <453e47e2$1@news.povray.org>
Kyle wrote:
> T> Why not?  I think having the option to apply a displacement instead of
> a normal to any object would be useful.  Applying a normal does not
> affect the shape or the shadow of the object. 

As said, you can do it with POV-Ray meshes already. As normal mapping is,
like displacement mapping, a trick to reduce the mesh triangle count in a
scanline renderer. POV-Ray is a ray-tracer and there are more efficient and
realistic ways to gain exactly the same effect for objects other than
meshes. (IMO) isosurfaces are the most viable of those ways, and POV-Ray
supports isosurfaces pretty well already.

> Applying a displacement
> should.  I realize that an isosurface can be used in many instance to
> obtain the desired effect, but I also think it would be useful to be
> able to build more complex objects with primitives, then apply a
> displacement as you would a normal.

Displacement mapping makes sense for triangle mesh scanline rendering, it
does not for ray-tracing. Displacement mapping was invented to reduce the
number of triangles that need to be fed through the graphics hardware, it
offers no benefits and many problems when applied to ray-tracing.

> I think having the option to support a low-poly mesh, which can then
> have a displacement map applied would be a nice feature. 

You have a misconception here: While for a scanline renderer there is a
benefit as you can reduce the number of triangles, for ray-tracing you won't
be able to reduce the number of triangles at all. they still need to be
generated.

Effectively, the workflow right now is: Export high-detail mesh from your
modeler and convert it to POV-Ray's mesh format. POV-Ray reads the mesh.
Then it renders the scene with the mesh.

The workflow you are suggesting is the following: Export low detail mesh
from modeler and have modeler compute and export displacement map images.
Convert the mesh to POV-Ray format. POV-Ray reads the mesh, reads the
displacement map images, generates triangles from the displacement map
images. Then POV-Ray renders the scene with the mesh.

See what you gain? Your modeler now needs to first generate the displacement
map. The displacement map images have lower precision than the original
mesh, and POV-Ray needs an additional processing step to turn the
displacement map back into more triangles (or you use geometry caching,
which makes rendering somewhat slower but reduces memory need). Along this
way there is conversion loss when turning triangles to an image (aka a grid
with limited spacial precision), and a lot of increased need for processing.
So your only gain would be a marginally smaller POV-Ray mesh source file,
with extreme increase in implementation complexity there would be a lower
memory footprint, but that would be offset again by additional computations.

> I agree that
> you can have any level of detail in a mesh, but the size of the mesh
> grows exponentially as the level of detail increases. 

The size does not grow exponentially. As mesh details are defined by the
surface area of the mesh, it grows by a power of two - that is, you need
four times as many triangles to get twice the mesh level of detail. This is
also why you can turn a mesh into a low detail version and a displacement
map, which effectively "compresses" the two dimensional surface details into
an image.

Besides, the mesh size is of course next to irrelevant as POV-Ray needs it
in memory anyway. More important is that the time to render a mesh grows
linearly with its number of triangles (n) when using a scanline renderer,
but only log(n) when using a ray-tracer!

In conclusion, the only read benefit that I have to admit exists with
displacement mapping is that it allows to use displacement mapped meshes
directly when the original mesh is not available.

> Additionally,
> it would be nice to have the ability to apply a procedural
> displacement in this instance.

With SDL you can already do that to meshes. Of course, I have to agree that
control over any primitive from within the scene would be even nicer. Yet,
even that still limits displacement mapping to mesh objects.

	Thorsten


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.