Does anyone know of a way to determine the normal of a surface dynamically at
render time? trace() is static/parse time. Attempting to infer from a functions
using the slope pattern doesn't work; its not allowed in pattern syntax and
isn't evaluated dynamically during a render using pigment syntax.
And of course there isn't a f_normal() in functions include.

I created a generic box mapping function that works similar to uv_mapping for a
box and can use box map images made in UV Mapper or alternatively, one of up to
six other pigment functions. It behaves better with cutaway_textures than
uv_mapping for a box, and can be applied to spheres, or other arbitrary shapes.
However, it behaves more like the boxed pigment meaning it is better with mostly
convex objects whereas a proper implementation should take the direction of the
surface normal into account, thereby allowing proper behavior with more concave
objects as well.

I can think of a couple of other uses for having the normal available at
rendertime as well. Any ideas?


--
Batronyx ^"^
bat### [at] cadronhsacom //old & going away
bat### [at] alliancecablenet //new & active now.
http://www.batronyx.com

Post a reply to this message

Batronyx <bat### [at] cadronhsacom> wrote:
: Does anyone know of a way to determine the normal of a surface dynamically at
: render time?

  I don't think there's any.

  (The POVman patch probably has a way, though.)

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Batronyx wrote:
> 
> Does anyone know of a way to determine the normal of a surface dynamically at
> render time? trace() is static/parse time. Attempting to infer from a functions
> using the slope pattern doesn't work; its not allowed in pattern syntax and
> isn't evaluated dynamically during a render using pigment syntax.
> And of course there isn't a f_normal() in functions include.
> 
> [...]

Megapov MCP has an object_slope pattern which works in functions etc. but
i'm not sure if it's suited for your purpose.

It can be found on:

http://www.schunter.etc.tu-bs.de/~chris/povcyg.html

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Batronyx wrote:
> 
> Does anyone know of a way to determine the normal of a surface dynamically at
> render time? trace() is static/parse time. Attempting to infer from a functions
> using the slope pattern doesn't work; its not allowed in pattern syntax and
> isn't evaluated dynamically during a render using pigment syntax.
> And of course there isn't a f_normal() in functions include.
> 
> I created a generic box mapping function that works similar to uv_mapping for a
> box and can use box map images made in UV Mapper or alternatively, one of up to
> six other pigment functions. It behaves better with cutaway_textures than
> uv_mapping for a box, and can be applied to spheres, or other arbitrary shapes.
> However, it behaves more like the boxed pigment meaning it is better with mostly
> convex objects whereas a proper implementation should take the direction of the
> surface normal into account, thereby allowing proper behavior with more concave
> objects as well.
> 
> I can think of a couple of other uses for having the normal available at
> rendertime as well. Any ideas?
> 
Yes...


(Opening the pandora box...)
The normal is available at the rendering engine level, but is not given when
evaluating the pigment. It is possible(*) to modify the parameters of the relevant 
functions (just adding the normal), in order to propagate that information to 
your pattern.

But keep in mind that adding the normal information to a pattern means that you
break the orthogonality between textures and forms(**). So, doing that is not a thing
to be done as a quick patch, it must be the result of a long reflection regarding
the global philosophy of Pov. 

Do you really need that ?



(**): Pattern starting to depend on the object on which they apply is not the usual
behaviour for Pov.

(*): In fact, I did it some months ago. it's not that hard, just a bit extensive.
The problem I still have is warping the normal. It's not that simple and clear as it
might first seems.
PS: Do not dare to ask, I won't publish that (it was for 3.1 anyway)!

Post a reply to this message

> 
> [...]
> 
> (**): Pattern starting to depend on the object on which they apply is not the usual
> behaviour for Pov.
> 

But meanwhile officially sanctioned by the POV-Team (slope pattern)
although this is still marked as experimental of course.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
: But meanwhile officially sanctioned by the POV-Team (slope pattern)
: although this is still marked as experimental of course.

  I think that uv-mapping can be considered another one.

  I don't think there's anything wrong in a texture knowing the normal
vector of the object at the evaluation point. I can't think of any reason
why this would be a bad thing.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp wrote:
> 
>   I don't think there's anything wrong in a texture knowing the normal
> vector of the object at the evaluation point. I can't think of any reason
> why this would be a bad thing.
> 

Agreed, although of course these patterns are not defined apart from
directly on the surface and therefore can't be used for other than
texturing purposes.  For exactly the same reason warps and transformations
don't work with the slope pattern. 

Something different that i won't consider as a good idea is using the
normal perturbation in a pattern, like done in the AOI patch:

http://martial.rameaux.free.fr/mael/aoi.html

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Warp wrote:
> 
> Christoph Hormann <chr### [at] gmxde> wrote:
> : But meanwhile officially sanctioned by the POV-Team (slope pattern)
> : although this is still marked as experimental of course.
> 
>   I think that uv-mapping can be considered another one.
> 
>   I don't think there's anything wrong in a texture knowing the normal
> vector of the object at the evaluation point. I can't think of any reason
> why this would be a bad thing.

There is good and bad things.

The bad thing is that traditionnally the procedural textures do not depend 
on the objects there are used over. The objects are immerged into the
pattern spaces.

The good thing is that it would avoid strange code just like in checker
and allow an easier code which would not scale/translate the point 
in order to avoid the hard transition for integer number. Assuming of course
that the normal provided is ALWAYS to the outside...
But it would require a rewrite of most of the patterns.

May be it's time for the next megapov documentation to have a distinction
between 3D traditional patterns and 2D (uv-like and normal dependant) patterns.
Even if they are both called patterns, they are really two different beasts!

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3bc91851@news.povray.org...
> Batronyx <bat### [at] cadronhsacom> wrote:
> : Does anyone know of a way to determine the normal of a surface dynamically
at
> : render time?
>
>   I don't think there's any.
>
>   (The POVman patch probably has a way, though.)
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

I was afraid of that. Thanks for the suggestion. I was really hoping for a 3.5
solution though. In the case of the box mapping, my implementation is a clumsy
workaround. If I have to work from a patch for a workaround, I think it would be
better to create a patch to implement the feature directly.
Of course since that is non-trivial, if I really need it before one is
available, I can certainly consider other patches. :)
Thanks again.


--
Batronyx ^"^
bat### [at] cadronhsacom //old & going away
bat### [at] alliancecablenet //new & active now.
http://www.batronyx.com

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3BC9496A.12672868@gmx.de...
>
>
> Batronyx wrote:
> >
> > Does anyone know of a way to determine the normal of a surface dynamically
at
> > render time? trace() is static/parse time. Attempting to infer from a
functions
> > using the slope pattern doesn't work; its not allowed in pattern syntax and
> > isn't evaluated dynamically during a render using pigment syntax.
> > And of course there isn't a f_normal() in functions include.
> >
> > [...]
>
> Megapov MCP has an object_slope pattern which works in functions etc. but
> i'm not sure if it's suited for your purpose.
>
> It can be found on:
>
> http://www.schunter.etc.tu-bs.de/~chris/povcyg.html
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> IsoWood include, radiosity tutorial, TransSkin and other
> things on: http://www.schunter.etc.tu-bs.de/~chris/

Thanks Christoph. For the sake of brevity I'll refer you to my answer to Warp's
post.

I will add though, I checked your link and was impressed to see a blur patch. I
was wondering just the other day how I might blur a texture in POV. I have to
ask though, "Why do you have it implemented where the pigment must be specified
twice rather than just as a pigment modifier?" Also, have you considered
allowing some optional jitter as with area lights to help break up some of the
aliasing artifacts at lower samples?


--
Batronyx ^"^
bat### [at] cadronhsacom //old & going away
bat### [at] alliancecablenet //new & active now.
http://www.batronyx.com

Post a reply to this message