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

Jérôme Grimbert wrote:
> 
> [...]
> 
> (**): 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

> > 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 ?
>

In the case of the box mapping function I mentioned, the normal isn't tied to
the pattern but rather used as a pattern selection criterion. Once chosen it is
applied in the usual manner.

However, as Warp and Christoph have already mentioned, there are the slope and
uv_mapping types that fit your description already. I would further answer your
question to say yes. In the case of the slope pattern I would like to see it
optionally evaluated on a per ray basis. :

It is possible to create toon effects with the slope pattern by aiming the
direction vector at the camera. Use high ambient colors for the fill and do the
pen outlines with an overlayed, zero-ambient, color map that is mostly
transparent except for some black centered on the perpendicular vector. In the
case of a wide angle perspective shot (i.e. looking up at a tall skyscraper) the
pen outline will disappear in various places. Although fixing this is probably
more a case of breaking its orthoganality to euclidian 3-space rather than the
object itself.

I do thank you for your suggestion though. As I mentioned in my reply above to
Warp, a direct patch implementation for the box mapping would probably be the
best way to go eventually.


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

Post a reply to this message

Batronyx wrote:

> I do thank you for your suggestion though. As I mentioned in my reply above to
> Warp, a direct patch implementation for the box mapping would probably be the
> best way to go eventually.

If the box mapping is your solution to have six sided box (and not only three
perpendicular one), I believe you do not need the normal information for that
pattern.

Maybe you could explain more what your new box mapping does.
(or even show us a picture in p.b.i ?)

Post a reply to this message

Batronyx wrote:
> 
> 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?
> 

Chris Huff has developed this further using an absolute sampling grid
rather than a relative one with usually leads to smoother results.  

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

> 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

can you explain why it's not a good idea ? (so i can change it :)
does the slope pattern not use the modified normal ?

M

Post a reply to this message

Mael wrote:
> 
> can you explain why it's not a good idea ? (so i can change it :)
> does the slope pattern not use the modified normal ?
> 

The slope pattern uses the unperturbated normal.  

In your aoi pattern, the syntax with normal is something like:

texture {
  pigment { aoi pt_cam } 
  normal { ripples .6 }
}

Which means it uses the normal statement to influence the pattern value. 
This is against the general concept IMO.  

For example what should happen with:

  normal { aoi pt_cam 0.5 }


The advantage of your pattern is quite clear (apart from the different
handling of normals it seems identical with the slope pattern) but it
would be better IMO to make the use of warps possible in such patterns by
making them influence the normal vector. 

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

> The slope pattern uses the unperturbated normal.

i think it does use the normal .. try the scene joined
as you've noticed i took the example of the slope pattern to write aoi patch
so that not too surprising if they have the same behavior :)
however i agree with you, it would be better not to use the normal pattern
to compute the pigment



#version 3.5;

#include "colors.inc"

global_settings {
  assumed_gamma 1.0
}

// ----------------------------------------

camera {
  location  <0.0, 0.5, -4.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.0,  0.0>
}

sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [0.7 rgb <0.0,0.1,0.8>]
    }
  }
}

light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}

// ----------------------------------------

plane {
  y, -1
  pigment { color rgb <0.7,0.5,0.3> }
}

sphere {
  0.0, 1
  texture {
    pigment {

      slope
      y              // direction vector for slope
      color_map {
        [0.00 color rgb <1.0,0.4,0.2> ]
        [0.33 color rgb <0.2,0.4,1.0> ]
        [0.66 color rgb <0.4,1.0,0.2> ]
        [1.00 color rgb <1.0,0.4,0.2> ]
      }
    }
    finish{
      specular 0.6
    }
    normal { wrinkles 1 }
  }
}

Post a reply to this message

Mael wrote:
> 
> > The slope pattern uses the unperturbated normal.
> 
> i think it does use the normal .. try the scene joined
> as you've noticed i took the example of the slope pattern to write aoi patch
> so that not too surprising if they have the same behavior :)

Oops, learned something new again...

But what's the difference between slope and aoi pattern then?

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

> But what's the difference between slope and aoi pattern then?

slope uses a fixed direction, while aoi uses the incident ray as direction
(or a direction = intersection to a fixed point)

M

Post a reply to this message