> > I mean displacement in the renderman displacement shader sense which
> > is what Roberto was asking about, hence in this case 'true
> > displacement'.
>
> Renderman (at least the PRMan implementation) is not a raytracer.

There are Renderman compliant renderers with raytracing support that do true
displacement without problems (BMRT being one of them, and Pixie a more
current example). Of course, true displacement is best used with Reyes
renderers, since you have almost infinite precision with that particular
algorythm.

> No, it's simply wrong.  Isosurfaces are just a more general feature than
> a displacement shader.  Displacement there is limited to mesh
> geomentries since - as mentioned above - it has to work for a scanline
> renderer.  You can model a shape as an isosurface function and then
> displace it - just like with a shader.  The only difference is that with
> isosurfaces you can also do much more.

Displacement can be applied to any primitive that takes shaders on a
Renderman compliant renderer. The original object retains the same
geometry - it's only displaced by the shader when rendering. However, with
isosurfaces, you have to modify the original function, thus the original
object is modified before parsing or rendering. As David said, picky, but
true.

Both approaches have their weak and strong points. However, that doesn't
change the fact that I'd like to apply displacement on pure primitives on
POV, or even meshes without any workarounds. And I can't do that.

At least not for now (hint, hint). ;-)

Best regards,

Roberto

Post a reply to this message

On Thu, 16 Oct 2003 11:05:35 -0300, "Roberto A." <wol### [at] hot-mailcom>
wrote:
> > Is that displacement on object/sphere/plane/mesh or is is only on meshes (if
> > you know what I mean in my question)?
>
> Displacement on Renderman can be applied to any primitive that takes
> shaders, with the exception of points and curves. That means meshes,
> subsurface subdivision meshes, spheres, cones, etc.

From what I understand from 
https://renderman.pixar.com/products/rispec/rispec_3_1/section12.html#Displacement.shaders
https://renderman.pixar.com/products/rispec/rispec_3_1/section4.html#RiDisplacement
https://renderman.pixar.com/products/rispec/rispec_3_1/section5.html#Quadrics
it doesn't mean that 'applied' = realized without conversion to mesh

ABX

Post a reply to this message

Roberto A. wrote:
> 
> There are Renderman compliant renderers with raytracing support that do true
> displacement without problems (BMRT being one of them, and Pixie a more
> current example). Of course, true displacement is best used with Reyes
> renderers, since you have almost infinite precision with that particular
> algorythm.

There is no raytracer that can apply displacement to an analytically 
solved shape.  That's not too bad of course because all non-raytracers 
can't even render those shapes.  At the risk of repeating myself - 
isosurfaces are as close to 'true displacement' as you can get.

> Displacement can be applied to any primitive that takes shaders on a
> Renderman compliant renderer. The original object retains the same
> geometry - it's only displaced by the shader when rendering.

This is simply wrong (see above).  What the renderer you have in mind 
probably does is to approximate the shape with a mesh and displace that 
- this is of course much less a 'true displacement' than an isosurface.

> However, with
> isosurfaces, you have to modify the original function, thus the original
> object is modified before parsing or rendering. As David said, picky, but
> true.

No, you don't have to modify the function as ABX already pointed out:

#declare fn_Shape = function { ... }

#declare fn_Iso = IC_Displace (fn_Shape)

isosurface {
   function { fn_Iso(x,y,z) }
   ...
}

> Both approaches have their weak and strong points. However, that doesn't
> change the fact that I'd like to apply displacement on pure primitives on
> POV,

Sorry, this will never happen, simply because it is not possible (at 
least not without an approximative root solver like in the isosurface 
shape).

Christoph

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

Post a reply to this message

> There is no raytracer that can apply displacement to an analytically
> solved shape.  That's not too bad of course because all non-raytracers
> can't even render those shapes.  At the risk of repeating myself -
> isosurfaces are as close to 'true displacement' as you can get.

Got it.

> This is simply wrong (see above).  What the renderer you have in mind
> probably does is to approximate the shape with a mesh and displace that
> - this is of course much less a 'true displacement' than an isosurface.

That's what it does internally, yes, but the effect has a 1-pixel
resolution, and thus is as close as defining a perfect displaced geometry as
possible. That's what I meant. I may be wrong, though.

> No, you don't have to modify the function as ABX already pointed out:
>
> #declare fn_Shape = function { ... }
>
> #declare fn_Iso = IC_Displace (fn_Shape)
>
> isosurface {
>    function { fn_Iso(x,y,z) }
>    ...
> }

I was not aware of this possibility. My bad.

> Sorry, this will never happen, simply because it is not possible (at
> least not without an approximative root solver like in the isosurface
> shape).

That's sad. I stand corrected then.

Regards,

Roberto

Post a reply to this message

On Thu, 16 Oct 2003 13:58:04 -0300, "Roberto A." <wol### [at] hot-mailcom>
wrote:
> > Sorry, this will never happen, simply because it is not possible (at
> > least not without an approximative root solver like in the isosurface
> > shape).
>
> That's sad. I stand corrected then.

No. You were wrong. POV _can_ do exactly the same what other packages - see
family of HF macros in shapes.inc where You can displace grid of triangles
using delivered function (kind of shader). You can do it on-the fly (like in
other packages) or write it to precalculated file. You have sources of it so
you can adjust it to your needs. You can even write macros to perform kind of
CSG with it.

And yes, POV can't do displacement on every primitive but afaik none other
package can do it as it was said in this thread.

ABX

Post a reply to this message

ABX wrote:
> On Wed, 15 Oct 2003 18:56:23 +0100, David Burnett <var### [at] ntlworldcom> wrote:
> 
>>I mean displacement in the renderman displacement shader sense which
>>is what Roberto was asking about, hence in this case 'true 
>>displacement'. A function (in this case a shader)
>>applied to an object, sphere, mesh, plane etc which change its
>>geometry.
> 
> 
> Is that displacement on object/sphere/plane/mesh or is is only on meshes (if
> you know what I mean in my question)?
> 

Displacement shaders can be applied to any sphere, however as RMAN,
BMRT etc always convert objects to micropolygons
(effectively sub 1 pixel in size depending on settings ) for shading
you could and probably should say its done on meshes.

Dave

Post a reply to this message

Christoph Hormann wrote:

  No, you don't have to modify the function as ABX already pointed out:
> 
> #declare fn_Shape = function { ... }
> 
> #declare fn_Iso = IC_Displace (fn_Shape)
> 
> isosurface {
>   function { fn_Iso(x,y,z) }
>   ...
> }
> 


And this our point of contention. I say
the isosurface here is the result of fn_Iso,
and not a displacement of fn_Shape and you
disagree.

Dave

Post a reply to this message

Among other things, David Burnett wrote:

>   No, you don't have to modify the function as ABX already pointed out:
>> 
>> #declare fn_Shape = function { ... }
>> 
>> #declare fn_Iso = IC_Displace (fn_Shape)
>> 
>> isosurface {
>>   function { fn_Iso(x,y,z) }
>>   ...
>> }
> 
> And this our point of contention. I say
> the isosurface here is the result of fn_Iso,
> and not a displacement of fn_Shape and you
> disagree.

What if POV syntax were:

isosurface {
  function { fn_Shape(x,y,z) }
  displaced_by { IC_Displace }
  ...
}

... and it were internally translated to IC_Displace(fn_Shape) ?

Would it be different?

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Jellby wrote:
> Among other things, David Burnett wrote:
> 
> 
>>  No, you don't have to modify the function as ABX already pointed out:
>>
>>>#declare fn_Shape = function { ... }
>>>
>>>#declare fn_Iso = IC_Displace (fn_Shape)
>>>
>>>isosurface {
>>>  function { fn_Iso(x,y,z) }
>>>  ...
>>>}
>>
>>And this our point of contention. I say
>>the isosurface here is the result of fn_Iso,
>>and not a displacement of fn_Shape and you
>>disagree.
> 
> 
> What if POV syntax were:
> 
> isosurface {
>   function { fn_Shape(x,y,z) }
>   displaced_by { IC_Displace }
>   ...
> }
> 
> .... and it were internally translated to IC_Displace(fn_Shape) ?
> 
> Would it be different?
> 

Not really, syntactically it looks good but internally it would have to 
work something like...


if shape(<x,y,z>) = threshold then
    <a,b,c> = ic_displace(<x,y,z>)
    value_for_point(<a,b,c>) = threshold	
end if


Dave

Post a reply to this message

In article <3f903478$1@news.povray.org>,
 David Burnett <var### [at] ntlworldcom> wrote:

> > .... and it were internally translated to IC_Displace(fn_Shape) ?
> > 
> > Would it be different?
> 
> Not really, syntactically it looks good but internally it would have to 
> work something like...

I do not see how the internal implementation can matter. The only thing 
of importance is the results.

I especially don't see how a mesh approximation of an object with the 
vertices shifted around with the displacement function can be any more 
"real" of a displacement than solving for a displaced version of the 
actual shape.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message