I always thought that the PHASE keyword for pigment patterns caused the pattern
to shift or move in a 'particular' direction-- for gradient x, to the right; for
gradient y, toward the top; for radial (on a cylinder), rotating clockwise (or
'to the left'.) But in v3.7.1 beta 9, it looks like it's shifting the patterns
in the opposite direction.

In the docs concerning 'phase', it says this (about the radial pattern--
applied to a tall cylinder, I assume):
"...In the example above if you render successive frames at phase 0 then phase
0.1, phase 0.2, etc. you could create an animation that rotates the stripes. The
same effect can be easily achieved by rotating the radial pigment using rotate
y*Angle..."

But PHASE actually rotates it in -y.

Try this code-- animate it for, say, 20 frames...
//------------
#version 3.71;

global_settings {assumed_gamma 1.0}

// perspective
camera {
  perspective
  location  <.5, .5, -3>
  look_at   <.5, .5,  0>
  right     x*image_width/image_height  // aspect
  angle 67
}

box{0, <1,1,0>
   texture{
     pigment{
        gradient x // or gradient y
        frequency 2
        phase 0 + clock
            }
     finish{ambient 0 emission 1 diffuse 0}
        }
  translate -1*x
   }

cylinder{0,1*y .4
  texture{
   pigment{
        radial
        frequency 10
        phase 0 + clock
        // OR...
        //rotate 90*clock*y
        color_map{
              [0.5 rgb <1,0,0>]
              [0.5 rgb 1]
                 }
            }
     finish{ambient 0 emission 1 diffuse 0}
        }
        translate 1*x
        }

Post a reply to this message

I suppose that my own conception of phase 'direction' could be backwards-- based
on 'visual' expectations vs. how phase 'looks at' a pattern's color index values
and shifts them.

But in the case of the radial pattern, "rotating the pigment by y*angle" is
definitely opposite to  phase 90*clock*y -- they visually rotate in opposite
directions.

Post a reply to this message

Am 10.02.2018 um 23:55 schrieb Kenneth:
> I always thought that the PHASE keyword for pigment patterns caused the pattern
> to shift or move in a 'particular' direction-- for gradient x, to the right; for
> gradient y, toward the top; for radial (on a cylinder), rotating clockwise (or
> 'to the left'.) But in v3.7.1 beta 9, it looks like it's shifting the patterns
> in the opposite direction.

Did you also test with v3.6 and/or v3.7.0?

If the behaviour differs from v3.6, it is certainly to be considered a
bug. If the behaviour is the same, it is probably to be considered an
error in the documentation.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Did you also test with v3.6 and/or v3.7.0?
>

Just tried it in v3.7.0, and the behavior is the same.

But I've been giving this behavior some more thought-- assuming that phase is
working *correctly* (disregarding the radial pattern for the moment.)

I'll use the gradient x pattern as an example (on a flat box, as a 'view or
window into the pattern'):

pigment{
     gradient x
     frequency 1
     phase 0.5
....

I was originally expecting the gradient x pattern *itself* to move 0.5 units to
the right. But the 'opposite' concept is that phase 0.5 shifts the *view* of the
pattern to the right-- as if phase is a 'camera' looking at a (static) pattern.
If this 'camera' moves to the right, then the VIEW of the pattern naturally
appears to shift to the left. In more technical terms, a positive phase 'climbs
through' the pattern's color_map index values: instead of 'seeing' the pattern
from index 0.0 to 1.0, it now sees it from 0.5 to 1.5 (actually, the index
starts repeating.)

If this is so, then my original expectation was wrong.

And in the case of the radial pattern, it's just a simple mistake in the docs:
Instead of "...rotate y*angle", it should be "...rotate -y*angle".

Honestly, it has been quite awhile since I used the phase keyword; my memory of
its long-ago operation is probably 'backwards' ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But in the case of the radial pattern, "rotating the pigment by y*angle" is
> definitely opposite to  phase 90*clock*y -- they visually rotate in opposite
> directions.

I think my own confusion stems from a lack of clarity in the documentation. The
only clue of what to *visually* expect from 'phase' is the one sentence about
the radial pattern (comparing it to "rotate y*angle)-- which happens to be
wrong, apparently. I think the docs need something else-- perhaps another
'movement' example, or a small explanation of the movement as it relates to a
pattern's index list. Simply describing phase as "causing the map entries to be
shifted so that the map starts and ends at a different place" isn't quite
detailed enough.

Post a reply to this message

I think that I'd expect the shift to occur in the opposite direction as well.

It seems to be rotating the pattern in the counterclockwise direction.
It would handy to know that phase is in radians instead of degrees as well.

Try this code - it makes 36 cylinders with pattern rotations of 5 degrees each
step, left to right, top to bottom.

//------------
#version 3.71;

global_settings {assumed_gamma 1.0}

#declare W = image_width;
#declare H = image_height;

#declare Zoom = 1;
camera {
  orthographic
  location <W/2, -H/2, -10>    // position & direction of view
  look_at  <W/2, -H/2,   0>
  right 1*x*image_width/Zoom            // horizontal size of view
  up 1*y*image_height/Zoom               // vertical size of view
}



#for (Y, 0, 5)
 #for (X, 0, 5)
  cylinder { <0, -1, 0>, <0, 0, 0>, min (W/14, H/14)
   texture {
    pigment {
     radial
     frequency 1
     phase radians(Y*5+X)
     color_map {
      [0.5 srgb <248, 196, 121>/255]
      [0.5 rgb 1]
     }
    }
    finish {ambient 0 emission 1 diffuse 0}
   }
   rotate -x*90
   translate <(W/12+X*W/6), -(Y*H/6+H/12), 0>
  }
 #end
#end

Post a reply to this message

Am 13.02.2018 um 03:40 schrieb Bald Eagle:

> It seems to be rotating the pattern in the counterclockwise direction.
> It would handy to know that phase is in radians instead of degrees as well.

That's only true for the radial pattern, and AFAIK only for unit frequency.

In other patterns, phase has entirely different effects; for instance,
in a gradient pattern it effectively just translates the pattern. No
radians nor degrees there.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 13.02.2018 um 03:40 schrieb Bald Eagle:
>
> > It seems to be rotating the pattern in the counterclockwise direction.
> > It would handy to know that phase is in radians instead of degrees as well.
>
> That's only true for the radial pattern, and AFAIK only for unit frequency.
>
> In other patterns, phase has entirely different effects; for instance,
> in a gradient pattern it effectively just translates the pattern. No
> radians nor degrees there.

Well, I have a habit of thinking about it like this:
http://mpec.sc.mahidol.ac.th/radok/physmath/MAT1/mor123.jpg

So once it's "unrolled", then rotation in degrees becomes offset in translation.
 pi radians would be 3.14.... scalar.

Not sure if that's how it's handled by POV-Ray internally, but that should be
easy to test and document the magnitude and direction of the shift.

Post a reply to this message

On 2/12/2018 7:55 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>> But in the case of the radial pattern, "rotating the pigment by y*angle" is
>> definitely opposite to  phase 90*clock*y -- they visually rotate in opposite
>> directions.
> 
> I think my own confusion stems from a lack of clarity in the documentation. The
> only clue of what to *visually* expect from 'phase' is the one sentence about
> the radial pattern (comparing it to "rotate y*angle)-- which happens to be
> wrong, apparently. I think the docs need something else-- perhaps another
> 'movement' example, or a small explanation of the movement as it relates to a
> pattern's index list. Simply describing phase as "causing the map entries to be
> shifted so that the map starts and ends at a different place" isn't quite
> detailed enough.

sounds like you're volunteering...come up with an additional usage 
example and brief description of what's going on and i'll add it to my 
todo list

Post a reply to this message

Jim Holsenback <spa### [at] nothanksnet> wrote:
> On 2/12/2018 7:55 PM, Kenneth wrote:
>
> > I think the docs need something else-- perhaps another
> > 'movement' example, or a small explanation of the movement as it relates to a
> > pattern's index list...
>
> sounds like you're volunteering...come up with an additional usage
> example and brief description of what's going on and i'll add it to my
> todo list

Thanks! It's going to be an interesting challenge; I'll give it a try.

At this point, I'll assume that phase *is* operating correctly (but that the
radial pattern example is wrong.) Barring any last-minute brainstorms in this
newsgroup thread about the reverse being true, I'll go with that assumption.

Post a reply to this message