Warp wrote:
> 
>>- it is not possible to add a displacement feature to any shape POV-Ray 
>>renders analytically.
> 
> 
>   Change "possible" to "efficient" and then you may be right. (And it
> probably shouldn't hurt putting a "probably" somewhere.)

Well - then you would have to be able to give me an example of a POV-Ray 
shape where you can modify the analytical root solver to support 
displacement mapping.  As long as you don't i keep my statement that 
this is not possible (and i am quite sure about this).

>>==> the only shape that could profit from a displacement mapping feature 
>>is the mesh but apart from render time subdivision with displacement 
>>this is already possible to implement in SDL (or external programs).
> 
> [...]
>   On-the-fly subdivision and displacement can't be done by modelling: It has
> to be done by the renderer itself.
> 

Is what i write somehow impossible to understand?  If not i have no idea 
why you post such a reply.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> 
> - it does not make any sense to add a displacement mapping feature to 
> any higher level shape in POV-Ray that is internally rendered as a mesh.

Yes. I agree. That's exactly what I'm trying to say. Displacement could 
be applied on the internal (triangle) mesh represenation.

> - it is not possible to add a displacement feature to any shape POV-Ray 
> renders analytically.

I know.

> ==> the only shape that could profit from a displacement mapping feature 
> is the mesh but apart from render time subdivision with displacement 

Bicubic patches would profit.
In future (if somone finds it worthwile to implement it) nurbs and all 
kind of subdivision surfaces could profit too.

> this is already possible to implement in SDL (or external programs).

SDL is slow.

To sum it up:
In this thread it was claimed that POV-Ray supports NURBS and that 
POV-Ray can do displacment-mapping. This is simply not true. You can't 
seriously argue that those things are supported *IN* POV-Ray by using an 
*EXTERNAL* application!

-Sascha

Post a reply to this message

Sascha Ledinsky wrote:
> 
>> ==> the only shape that could profit from a displacement mapping 
>> feature is the mesh but apart from render time subdivision with 
>> displacement 
> 
> 
> Bicubic patches would profit.
> In future (if somone finds it worthwile to implement it) nurbs and all 
> kind of subdivision surfaces could profit too.

I am loosing interest in arguing here: As long as i have anything to say 
there will be no feature added to POV-Ray or MegaPOV that adds support 
for displacement mapping specifically to bicubic patches.  A generic 
mesh displacement might be interesting but redundant to some extent.

> To sum it up:
> In this thread it was claimed that POV-Ray supports NURBS and that 
> POV-Ray can do displacment-mapping. This is simply not true. You can't 
> seriously argue that those things are supported *IN* POV-Ray by using an 
> *EXTERNAL* application!

At the risk of repeating myself:  POV-Ray supports NURBS and 
displacement mapping as much as (and more than as far as isosurfaces are 
concerned) most other *renderers* available that use the raytracing 
algorithm.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> Well - then you would have to be able to give me an example of a POV-Ray 
> shape where you can modify the analytical root solver to support 
> displacement mapping.  As long as you don't i keep my statement that 
> this is not possible (and i am quite sure about this).

  Can you give me an example of how to shear an object without having to
do anything to the root solver? Naturally you can, because POV-Ray supports
exactly that: Instead of modifying the analytical representation of the
object, we modify the rays tested against the object.

  I'm in no way implying it's *easy* or *efficient* to perform displacement
mapping by tracing non-linear rays, I'm just saying it's theoretically
*possible*.

> Is what i write somehow impossible to understand?  If not i have no idea 
> why you post such a reply.

  You said "this is already possible to implement in SDL".
  No, it's not. You can't implement in SDL a dynamic displacement mapping
engine which subdivides triangles on the fly while rendering.

  You can subdivide the entire mesh before rendering and then render it,
but that requires quite a lot of extra memory. My point was that the whole
idea of supporting subdivision in the renderer is that it can perform
memory optimizations which allow almost unlimited subdivision with
limited amount of memory.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> A generic 
> mesh displacement might be interesting but redundant to some extent.

  It's certainly not redundant. Not if it's optimized to only subdivide
what is being currently rendering.
  As I said earlier, this kind of optimization allows enormous subdivisions
with only a tiny extra memory requirement.

  In other words: Imagine a 100MB mesh being subdivided so that each
triangle is divided into 100 triangles, and the result can be rendered
without requiring much more than the 100MB of RAM.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> 
>>Is what i write somehow impossible to understand?  If not i have no idea 
>>why you post such a reply.
> 
> 
>   You said "this is already possible to implement in SDL".
>   No, it's not. You can't implement in SDL a dynamic displacement mapping
> engine which subdivides triangles on the fly while rendering.

I wrote:

 > the only shape that could profit from a displacement mapping feature
 > is the mesh but apart from render time subdivision with displacement
 > this is already possible to implement in SDL (or external programs).

I would appreciate it if you'd either read and cite me correctly or 
refrain from replying.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
>  > the only shape that could profit from a displacement mapping feature
>  > is the mesh but apart from render time subdivision with displacement
>  > this is already possible to implement in SDL (or external programs).

> I would appreciate it if you'd either read and cite me correctly or 
> refrain from replying.

  I quoted you exactly and I said, and still say, that you are wrong.

  I repeat, once again: The whole idea of a displacement mapping
supported by the renderer (vs. the modeller) is that the renderer
can optimize the memory usage of the mesh which the displacement is
applied to.
  This is certainly not possible with the current SDL.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message