Of course there is no native thingy in povray that allows you to assign colors
based on radius of curvature. So things with small radius of curvature could be
black and large white.  But is there any way within SDL to simulate this?

I was starting thinking along the lines of slope in pigment_maps, and
translating averaged pigments, but only got so far with this.  Any ideas?

Post a reply to this message

Am 16.02.2011 03:49, schrieb gregjohn:
> Of course there is no native thingy in povray that allows you to assign colors
> based on radius of curvature. So things with small radius of curvature could be
> black and large white.  But is there any way within SDL to simulate this?
>
> I was starting thinking along the lines of slope in pigment_maps, and
> translating averaged pigments, but only got so far with this.  Any ideas?

Noe that I know of. Proximity maps possibly come closest to what you're 
thinking of.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 16.02.2011 03:49, schrieb gregjohn:
> > Of course there is no native thingy in povray that allows you to assign colors
> > based on radius of curvature. So things with small radius of curvature could be
> > black and large white.  But is there any way within SDL to simulate this?
> >
> > I was starting thinking along the lines of slope in pigment_maps, and
> > translating averaged pigments, but only got so far with this.  Any ideas?
>
> Noe that I know of. Proximity maps possibly come closest to what you're
> thinking of.


Thanks.  Just for my education, what happens when you translate a slope map? My
experience is "nothing", and understanding why would help me understand the
inner workings of the function.  I was hoping it would be like "the slope of the
model at a [vector V] away", but it wasn't.   thanks.  As I'm typing, I think I
should re-read section on warps!

Post a reply to this message

Am 16.02.2011 13:25, schrieb gregjohn:

> Thanks.  Just for my education, what happens when you translate a slope map? My
> experience is "nothing", and understanding why would help me understand the
> inner workings of the function.  I was hoping it would be like "the slope of the
> model at a [vector V] away", but it wasn't.   thanks.  As I'm typing, I think I
> should re-read section on warps!

I guess you're talking about the slope pattern, not slope maps for 
normal pertubation.

The slope pattern is not a true 3D pattern - it is only defined on the 
surface of an object (after all it needs a normal vector); so it doesn't 
make sense to move it around separately from the object. Instead, the 
slope pattern always "sticks" to the object it is applied to, as far as 
translations go. (Note however that the slope pattern's "up" vector 
stays fixed all the while.)

The same goes for the aoi pattern, by the way.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> The slope pattern is not a true 3D pattern - it is only defined on the
> surface of an object (after all it needs a normal vector); so it doesn't
> make sense to move it around separately from the object. Instead, the
> slope pattern always "sticks" to the object it is applied to, as far as
> translations go. (Note however that the slope pattern's "up" vector
> stays fixed all the while.)
>

Just making sure I understand the "not make sense."  It could be either
geometrically indeterminate or a massive coding headache to enable, I'm not able
to say. But artistically there could be cases were allowance of warps/
transforms to the slope pattern could be very useful.  One application was in
making a radius of curvature texture for applying high and low values of SSS.

Post a reply to this message

Am 27.02.2011 13:19, schrieb gregjohn:
> clipka<ano### [at] anonymousorg>  wrote:
>>
>> The slope pattern is not a true 3D pattern - it is only defined on the
>> surface of an object (after all it needs a normal vector); so it doesn't
>> make sense to move it around separately from the object. Instead, the
>> slope pattern always "sticks" to the object it is applied to, as far as
>> translations go. (Note however that the slope pattern's "up" vector
>> stays fixed all the while.)
>
> Just making sure I understand the "not make sense."  It could be either
> geometrically indeterminate or a massive coding headache to enable, I'm not able
> to say.

It would be geometrically indeterminate for virtually all primitive 
types (with a few exceptions like blobs or isosurfaces where the normal 
vector can be defined as the gradient of some potential).

> But artistically there could be cases were allowance of warps/
> transforms to the slope pattern could be very useful.  One application was in
> making a radius of curvature texture for applying high and low values of SSS.

That may well be - but enabling this would be a major /definition/ 
headache (as well as an inconsistency headache), because the way warps 
work on any other pattern is totally unsuited for perturbing slope patterns.

Maybe the easiest way to implement something close would be to add a 
mechanism to directly add, multiply or average multiple patterns, so 
that you could modulate the slope pattern with a bozo pattern for instance.

Post a reply to this message