Vahur Krouverk wrote:
> 
> Nice. Did you 'invented' this shader by yourself? ARM book contains
> examples of such shaders. Unfortunately most advanced of them can't be
> applied to POVMan, as POVMan doesn't support surface derivatives, which
> are necessary for calculation of cel lines with uniform width. As it
> could be seen on this picture and other 'pure-povray' approaches, line
> widths depend from object geometry. Perhaps better results could be
> achieved with specific patch by J. Grimbert, but this requires as well
> surface derivative calculation...

Until YOU are going to provide EACH pov object with a function which
provide the derivative at any point of the object, including at the
surface, but also inside and outside, the only approach would be
to make a kind of guess by casting more rays.
Thus it would require more rewrite of the pov-engine, and a serious
slowdown. (I remind you that some object provide a normal only
for a previously computed intersection... so you cannot 'sample' around
the intersection to get a feeling about the variation of the normal...)

So, the only safe approach would probably be a new function per object, 
It should be easy for sphere, but already with a box the problems
start coming out... What is the derivative on a edge ? on a vertex ?

With CSG, it's even more difficult!
Blob is not funny either!
and Isosurface is probably better handled only by the user:
 user provide both the isosurface formulae and its derivatives!

quartic, quadric and all poly objects are on the contrary rather
simple to get the derivative automatically and easily.
And the same probably goes for superellipsoid (?).

-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,

Post a reply to this message

> 
> Until YOU are going to provide EACH pov object with a function which
> provide the derivative at any point of the object, including at the
> surface, but also inside and outside, the only approach would be
> to make a kind of guess by casting more rays.
> Thus it would require more rewrite of the pov-engine, and a serious
> slowdown. (I remind you that some object provide a normal only
> for a previously computed intersection... so you cannot 'sample' around
> the intersection to get a feeling about the variation of the normal...)
> 
[Snip]
Yes, I know all these problems.
Additional problem, which comes with use of RenderMan shaders, is the 
fact, that in RenderMan all surfaces are parametric (with respect to uv) 
and surface derivatives are usually taken with respect of u and v (this 
is done 'analytically' in BMRT (don't know about PRMan), other 
derivatives are made by 'supersampling': running shader in u+du or v+dv 
points and calculating required expression). This means, that using 
RenderMan shaders with surface derivatives could be done to small subset 
of POV-Ray objects (sphere, plane, box, mesh, ??).
I intend to create method for POV-Ray objects, which returns surface 
derivatives and implement it for 'parametrizable' objects (as you put 
it: 'safe approach'). For other objects dummy implementation (or 
approximation??) could be made. This is not 'perfect' solution, but it 
allows to use some advanced shaders with POV-Ray (current implementation 
of shader support is limited and it will not be fully supported anyway, 
for it would require too much work, easier would be to use RenderMan 
compliant renderer in such case).

Post a reply to this message

Vahur Krouverk wrote:

> [Snip]

> I intend to create method for POV-Ray objects, which returns surface
> derivatives and implement it for 'parametrizable' objects (as you put
> it: 'safe approach'). For other objects dummy implementation (or
> approximation??) could be made. This is not 'perfect' solution, but it
> allows to use some advanced shaders with POV-Ray (current implementation
> of shader support is limited and it will not be fully supported anyway,
> for it would require too much work, easier would be to use RenderMan
> compliant renderer in such case).

Before wasting to much of your time patching and for my own enlightment, 
is there any real interest for this kind of shader information ?
What does it allow to make ?
For the time being, I even hardly see any interest even just for
the edge detection/celluloid thing... 
so I wonder if it is really worth something.

P.S.: These questions are serious, not rethorical or ironical. 
I would really be interested in URLs which show the advantage of such
derivative information for a shaders, so feel free to reference pages
that contain Renderman pictures...

-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,

Post a reply to this message

> 
> Before wasting to much of your time patching and for my own enlightment, 
> is there any real interest for this kind of shader information ?

Don't know. Perhaps not, as POVMan itself is already niche product. But 
this is my way of wasting time and perhaps I can learn something during 
this process :-)

> What does it allow to make ?
Analytical anti-aliasing. Of course this can be achieved with POV-Ray 
means and probably more efficiently. Additionally, writing shaders which 
antialiase well ain't easy task (although one can use number of already 
created shaders).
But if analytical antialiasing is too complex for given shader, then 
shaders frequency could be limited, if we know sampling frequency (IOW 
surface derivatives). This approach could be applied to many shaders, 
which use noise or its variants. (Of course more-or-less similar results 
could be achieved by giving estimated derivatives as parameters, but 
this works only for fairly 'flat' shapes.)
Other application is nonphotorealistic shaders. Cel shading is one of 
them, other application could be shaders in 'Pen-and-Ink', woodblock or 
engraving style. (PDF document describing pen and ink rendering could be 
found at
http://citeseer.nj.nec.com/winkenbach96rendering.html
though not directly renderman related. ARM book contains shader, which 
gives similar results).


> For the time being, I even hardly see any interest even just for
> the edge detection/celluloid thing... 
> so I wonder if it is really worth something.
Yes, it could be discouraging. There is quite number of patches, which 
have very little recognition, either because they are hard to use or 
they are too specific or they copy already existing functionality.

But there are other areas in shader support, which could be implemented 
or improved. One of them is displacement shader, which could give nice 
support for displacement, other is light shader, which could be used for 
creation of user-specified light-sources. Or Imager shader, which could 
be used for post-processing image. Or support for transformations 
between camera and screen spaces, which give more flexibility to 
shaders. So possibilities for shaders are huge, if I had only time enough...

Post a reply to this message