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

On Fri, 27 Oct 2006 09:20:57 +0200, TB Software Support
<NOS### [at] tb-softwarecom> wrote:

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

Bump mapping in POV-Ray affects the normal of the object and does not
actually displace the surface of the object.  For example, if you use
a strong bump map on a sphere, you will notice that the edges of the
sphere are still perfectly round, as is the shadow cast by the sphere.
Displacement mapping, in the context that I am referring to, would
actually perturb the surface sphere.  This surface perturbation would
affect the shadow of the sphere also.  The effect would be similar to
using an isosurface in POV-Ray.


Kyle

Post a reply to this message

Kyle nous apporta ses lumieres en ce 27/10/2006 14:17:
> On Fri, 27 Oct 2006 09:20:57 +0200, TB Software Support
> <NOS### [at] tb-softwarecom> wrote:

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


> Bump mapping in POV-Ray affects the normal of the object and does not
> actually displace the surface of the object.  For example, if you use
> a strong bump map on a sphere, you will notice that the edges of the
> sphere are still perfectly round, as is the shadow cast by the sphere.
> Displacement mapping, in the context that I am referring to, would
> actually perturb the surface sphere.  This surface perturbation would
> affect the shadow of the sphere also.  The effect would be similar to
> using an isosurface in POV-Ray.


> Kyle

And would probably take around the same amount of time to render as an isosurface.

-- 
Alain
-------------------------------------------------
SHOPPING MATH
A man will pay $20 for a $10 item he needs.
A woman will pay $10 for a $20 item that she doesn't need.

Post a reply to this message

In article <45426f8a@news.povray.org>, ele### [at] netscapenet says...
> Kyle nous apporta ses lumieres en ce 27/10/2006 14:17:
> > On Fri, 27 Oct 2006 09:20:57 +0200, TB Software Support
> > <NOS### [at] tb-softwarecom> wrote:
> 
> >> Displacement mapping (or bump mapping) is already supported in
> >> POV-Ray.
> 
> 
> > Bump mapping in POV-Ray affects the normal of the object and does not
> > actually displace the surface of the object.  For example, if you use
> > a strong bump map on a sphere, you will notice that the edges of the
> > sphere are still perfectly round, as is the shadow cast by the sphere.
> > Displacement mapping, in the context that I am referring to, would
> > actually perturb the surface sphere.  This surface perturbation would
> > affect the shadow of the sphere also.  The effect would be similar to
> > using an isosurface in POV-Ray.
> 
> 
> > Kyle
> 
> And would probably take around the same amount of time to render as an is
osurface.
> 
Though.. Are there not some basic limitations of Isosurfaces as well 
anyway? How do you use an isosurface to produce a car or an animal 
model, for example? The one advantage displacement maps have is that you 
can add geometry to an object that "isn't" easily defined with a clear 
concise algorithm. If that is a good reason to support such a thing or 
not is entirely a matter of various people's perspectives of course. Its 
not always possible to argue successfully for solution that make things 
easier to do in "specific" cases, when there is a perception of a more 
physically "correct" model already in the engine, and it just happens to 
be complicated, frustrating and confusing to get the same result with it 
(like subsurface scattering effects, for example).

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> Though.. Are there not some basic limitations of Isosurfaces as well
> anyway? How do you use an isosurface to produce a car or an animal
> model, for example?

exactly!  Figuring out complex functions to model moderatelly complex shapes
with isosurfaces is a pain.  In the end, i think it's really just useful for
random naturally shaped patterns such as rocks or rocky landscapes.  Then
again, people will tell you to use meshes for cars or creatures (already
with displacements)...

I myself would be much happier if blobs were taken more seriously and boxes
were one of the primitives allowed.  It's so much easier to model shapes
with blobs by iteratively adding and subtracting shapes!...

Post a reply to this message