I don't understand how radial works with non integer frequencies.

Let's take a simple one :
#declare MyP = pigment{ radial
         frequency F
         phase P
         pigment_map {
                [0.5 Black]
                [0.5 White]}}

I want F to grow from .1 to 10, and I want the Black color to start at the 
fixed position (+x, -z, I don' t care). What is the value of P which achieve 
this ?

It looked simple to me at first, but I must say that I going to give up. Any 
one can help ?


Alain

Post a reply to this message

Wasn't it Alain who wrote:
>I don't understand how radial works with non integer frequencies.
>
>Let's take a simple one :
>#declare MyP = pigment{ radial
>         frequency F
>         phase P
>         pigment_map {
>                [0.5 Black]
>                [0.5 White]}}
>
>I want F to grow from .1 to 10, and I want the Black color to start at the 
>fixed position (+x, -z, I don' t care). What is the value of P which achieve 
>this ?
>
>It looked simple to me at first, but I must say that I going to give up. Any 
>one can help ?

I couldn't get radial itself to behave predictably for non-integer
frequencies, but I've managed to write a pigment function that behaves
in a predictable manner and gives the same results as "radial" for
integer frequencies.

#include "functions.inc"
#declare MyP = pigment{
         function {F * (0.5+f_th(z,0,-x)/2/pi)}
         pigment_map {
                [0.5 Black]
                [0.5 White]}}

The "/2/pi" bit compensates for the fact that f_th() returns radians.

The "0.5" compensates for the fact that the implied atan operation
returns negative values in the second hemisphere. We want values between
0.0 and 1.0 rather than between -0.5 and +0.5.

Using "(z,0,-x)" instead of "(x,0,z)" flips the axes, so that the
pattern starts at +x and goes clockwise, like "radial" does, rather than
starting at -z and going anticlockwise.

Note that you won't always see a black/white transition at +x, because
for some values of F the pattern ends on black, and you can't see where
the end black ends and the start black starts. (Similarly, for negative
values of F you can get two whites next to each other).

If you animate with "#declare F=clock*10;" you can see how the starting
point behaves.

Don't try using "phase" to change the starting point because it
interferes with the "0.5" compensation factor.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Thank you Mike to share your findings. It is like fresh air coming from a
door that I did not realize it existed.

I like your idea of getting rid off native radial (see my comments below).
You get similar results to my best shot so far, which is :

#declare MyP = pigment{ radial
         frequency F
         phase -(F/4+F+.5)
         pigment_map {
                [0.5 Black]
                [0.5 White]}
         }

The black starts nicely at -z going
anti-clockwise, except when F becomes N+]0,0.5[ . Then the start shifts
continuously and join -z again when F becomes N+0.5. And it stays there
until N+1. etc... This is annoying !!

Your solution has the exact same behavior (minus orientation) as mine but 
looks to be much more open
to dedicated tuning. I will explore.

My current point of view is that radial pattern feature has a serious flaw
or even bug?. At least everybody will admit a severe weakness of the
documentation which states : "Values from 0.0 to 1.0 cause a fraction of the
map to be used."

I keep you posted if I find a decent solution

Alain

Comparison can be rendered with :
-----------------------------------------------------
#include "colors.inc" #include "functions.inc"
camera {orthographic angle 90 location <0,2.5,0>
        right x*image_width/image_height look_at <0,-4.7,0>}
light_source{< 0, 30, 0> color White shadowless}
plane{ <0,1,0>, 0 texture{ pigment{color rgb <0.7,0.5,0.3>}}}

#macro Draw(Max)
#local J=0;
  union {
  #while (J<6)
     #local I = 1;
     union {
        #while (I<Max)
                text {ttf "timrom.ttf" str(I/2+J/10,3,1), 1, 0 scale .2
                        pigment {Yellow} rotate x*90 translate 
<I-Max/2+.3,1,-.3>}
                cylinder {0,y,.3 pigment {R(I/2+J/10)} translate 
x*(I-Max/2)}
                #local I = I+1;
        #end
        translate -z*(.8*J-4) }
    #local J=J+1;
  #end
  }
#end

#macro R(F) // RADIAL
#local Tmp = pigment{radial
         frequency F
         phase -(F/4+F+.5)
         pigment_map {
                [0.5 Black]
                [0.5 White]}
         rotate y*90
         }
Tmp
#end


object {Draw(14)}

#macro R(F) // FUNCTION
#local Tmp = pigment{
         function {F * (0.5+f_th(z,0,x)/2/pi)}
         pigment_map {
                [0.5 Black]
                [0.5 White]}
         }
Tmp
#end
object {Draw(14) translate -z*5}
------------------------------------------------------



HFH### [at] econymdemoncouk...
> Wasn't it Alain who wrote:
>>I don't understand how radial works with non integer frequencies.
>>
>>Let's take a simple one :
>>#declare MyP = pigment{ radial
>>         frequency F
>>         phase P
>>         pigment_map {
>>                [0.5 Black]
>>                [0.5 White]}}
>>
>>I want F to grow from .1 to 10, and I want the Black color to start at the
>>fixed position (+x, -z, I don' t care). What is the value of P which
>>achieve
>>this ?
>>
>>It looked simple to me at first, but I must say that I going to give up.
>>Any
>>one can help ?
>
> I couldn't get radial itself to behave predictably for non-integer
> frequencies, but I've managed to write a pigment function that behaves
> in a predictable manner and gives the same results as "radial" for
> integer frequencies.
>
> #include "functions.inc"
> #declare MyP = pigment{
>         function {F * (0.5+f_th(z,0,-x)/2/pi)}
>         pigment_map {
>                [0.5 Black]
>                [0.5 White]}}
>
> The "/2/pi" bit compensates for the fact that f_th() returns radians.
>
> The "0.5" compensates for the fact that the implied atan operation
> returns negative values in the second hemisphere. We want values between
> 0.0 and 1.0 rather than between -0.5 and +0.5.
>
> Using "(z,0,-x)" instead of "(x,0,z)" flips the axes, so that the
> pattern starts at +x and goes clockwise, like "radial" does, rather than
> starting at -z and going anticlockwise.
>
> Note that you won't always see a black/white transition at +x, because
> for some values of F the pattern ends on black, and you can't see where
> the end black ends and the start black starts. (Similarly, for negative
> values of F you can get two whites next to each other).
>
> If you animate with "#declare F=clock*10;" you can see how the starting
> point behaves.
>
> Don't try using "phase" to change the starting point because it
> interferes with the "0.5" compensation factor.
>
> -- 
> Mike Williams
> Gentleman of Leisure

Post a reply to this message

Wasn't it Alain who wrote:
>Thank you Mike to share your findings. It is like fresh air coming from a
>door that I did not realize it existed.
>
>I like your idea of getting rid off native radial (see my comments below).
>You get similar results to my best shot so far, which is :
>
>#declare MyP = pigment{ radial
>         frequency F
>         phase -(F/4+F+.5)
>         pigment_map {
>                [0.5 Black]
>                [0.5 White]}
>         }
>
>The black starts nicely at -z going
>anti-clockwise, except when F becomes N+]0,0.5[ . Then the start shifts
>continuously and join -z again when F becomes N+0.5. And it stays there
>until N+1. etc... This is annoying !!

But, as I said, that's simply because the end colour is the same as the
start colour. The colouring starts in the same place, but you can't see
the colour transition.

If you temporarily change it to 
         pigment_map {
                [0 Black]
                [1 White]}}
then you can see what's happening more clearly.


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message