"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