Here's two feature requests, both of which I think would be very useful, both of which
I'm sure have
likely been requested sometime in the past:

1)  Support for normal mapping (RGB type of normal maps)

... and even better ...

2)  Support for displacement mapping

Any thoughts on these features?


Kyle

Post a reply to this message

Kyle wrote:
> Here's two feature requests, both of which I think would be very useful, both of
which I'm sure have
> likely been requested sometime in the past:
> 
> 1)  Support for normal mapping (RGB type of normal maps)
> 
> ... and even better ...
> 
> 2)  Support for displacement mapping
> 
> Any thoughts on these features?

Both are in wide use when modeling meshes, but have not suitable application
to any other primitive POV-Ray supports. POV-Ray meshes already support
arbitrary normals, and you can easily create meshes with any level of
detail, making displacement mapping completely obsolete (except that a
displacement mapping could make parsing meshes a tiny bit faster). Hence
neither of these features needs to be added, they are already supported.

	Thorsten

Post a reply to this message

Thorsten,



>Both are in wide use when modeling meshes, but have not suitable application
>to any other primitive POV-Ray supports. 

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.  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.

>POV-Ray meshes already support
>arbitrary normals, and you can easily create meshes with any level of
>detail, making displacement mapping completely obsolete (except that a
>displacement mapping could make parsing meshes a tiny bit faster). 

I think having the option to support a low-poly mesh, which can then
have a displacement map applied would be a nice feature.  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.  Additionally,
it would be nice to have the ability to apply a procedural
displacement in this instance.

>Hence
>neither of these features needs to be added, they are already supported.
>
>	Thorsten

Again, thanks for your feedback.


Kyle

Post a reply to this message

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

453e47e2$1@news.povray.org...
> 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).

I've been using displacement maps (with subpolygon displacements) in two 
other renderers and these maps are either painted or generated procedurally 
(on the fly), not generated by a modeler. The workflow is to create a mesh 
with as few polygons as possible and then create the fine details through 
displacement. The benefit is that you can keep a relatively low-res mesh 
that is easy to manipulate (and change if necessary) and fine-tune its 
displacement map(s) directly in Photoshop or through procedural materials.

G.

Post a reply to this message

Kyle <hob### [at] gatenet> wrote:
> I think having the option to apply a displacement instead of
> a normal to any object would be useful.

  You are free to propose a solution to that. Preferably in C++.

  Displacement mapping is used in scanline renderers because it's
feasible there. They use triangle meshes (or easily tesselable surfaces
such as NURBS) which can be easily subdivided and displaced even on
the fly.

  You want it to be done with *any* object in POV-Ray. Well, feel
free to suggest how it could be done.

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> 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.

  Some scanline renderers support subdivision&displacement of the mesh
on the fly, while rendering. This means that only a small part of the
mesh needs to be subdivided at a time, and parts which have been already
rendered can be dropped. This keeps memory consumption low. This makes
it possible to render meshes which apparently consist of thousands of
millions of triangles, yet rendering them consumes only a few megabytes
of memory.

  Of course trying to do the same in a raytracing engine can be a bit
more complex.

-- 
                                                          - Warp

Post a reply to this message

Gilles Tran wrote:

> 453e47e2$1@news.povray.org...
>> 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).
> 
> I've been using displacement maps (with subpolygon displacements) in two 
> other renderers and these maps are either painted or generated procedurally 
> (on the fly), not generated by a modeler.

Indeed you can do it procedurally, but that was not the point in that
particular section of my post (I pointed out procedural displacement in the
last paragraph of the post). However, in real-time rendering applications
(in particular video games), displacement mapping is used as a kind of LOD
technique, and closely related to normal mapping (which, as the original
posted implied correctly, is a simplified form to get a kind of displacement
mapping appearance).

This was what the original poster seems to have been hinting at by asking
for both features at once, as they are closely related for exactly this kind
of application. Especially for normal mapping the method I describes is how
it actually came to be - a poor-mans, ahem, scanline renderers way of
simulating rather computational expensive displacement mapping of scanline
hardware renderers at the time.

> The workflow is to create a mesh
> with as few polygons as possible and then create the fine details through
> displacement.

Indeed that is one way to use it, depending on your application and modeler
capabilities (decimating meshes is a complex algorithmic problem and makes
most use if you need to to real-time rendering with the model). However, in
ray-tracing, as you know, there are nicer ways to do things like this, and
especially in POV-Ray directly (rather than using a modeler).

BTW, one very simple way to do in essence what some ray-tracing displacement
mapping algorithms do, you can just use a height field. By clipping, one can
even get them to behave like triangles. Of course, this is not as optimal as
having a mesh directly.

	Thorsten

Post a reply to this message

Warp wrote:
>   Some scanline renderers support subdivision&displacement of the mesh
> on the fly, while rendering.

Yes, that method is called geometry caching for ray-tracing (as I
mentioned). Just google for "geometry caching", and you get the research
papers that describe it.

	Thorsten

Post a reply to this message

On Mon, 23 Oct 2006 21:30:57 -0400, Kyle <hob### [at] gatenet> wrote:

>2)  Support for displacement mapping
>
>Any thoughts on these features?
>
Hello

Displacement mapping (or bump mapping) is already supported in
POV-Ray.

Following steps are required:
1. create highres model from low res model
2. create displacement map from both models
3. send lowres model + displacement map to POV-Ray

just look here http://www.tb-software.com/board/showthread.php?tid=16
Rheingold3D can do this and can create POV-Ray SDL.

B&R

-tb

Post a reply to this message