Chuck Roberts wrote:
> 
> I have POV 3.0 and want to try a little animation. If I move a camera,
> say forward a little, turn right 90 degrees, then move forward some
> more, do I have to create 3 different POV scene files? Or is there some
> way to do this in a single POV scene file with animation?
> 
> Thank you.

This is straight out of the Docs:


  Clock Dependant Variables And Multi-Stage Animations

Okay, what if we wanted the ball to roll left to right for the first half of the
animation, then change direction 135 degrees and roll right to left, and toward
the back of the scene. We would need to make use of POV-Ray's new conditional
rendering directives, and test the clock value to determine when we reach the
halfway point, then start rendering a different clock dependant sequence. But
our goal, as above, it to be working in each stage with a variable in the range
of 0 to 1 (normalized) because this makes the math so much cleaner to work with
when we have to control multiple aspects during animation. So let's assume we
keep the same camera, light, and plane, and let the clock run from 0 to 2! Now,
replace the single sphere declaration with the following...

  #if ( clock <= 1 )
    sphere { <0, 0, 0> , 1
      pigment {
        gradient x
        color_map {
          [0.0 Blue  ]
          [0.5 Blue  ]
          [0.5 White ]
          [1.0 White ]
        }
        scale .25
      }
      rotate <0, 0, -clock*360>
      translate <-pi, 1, 0>
      translate <2*pi*clock, 0, 0>
    }
  #else
    // (if clock is > 1, we're on the second phase)
    // we still want to work with  a value from 0 - 1
    #declare ElseClock = clock - 1;
    sphere { <0, 0, 0> , 1
      pigment {
        gradient x
        color_map {
          [0.0 Blue  ]
          [0.5 Blue  ]
          [0.5 White ]
          [1.0 White ]
        }
        scale .25
      }
      rotate <0, 0, ElseClock*360>
      translate <-2*pi*ElseClock, 0, 0>
      rotate <0, 45, 0>
      translate <pi, 1, 0>
    }
  #end

If we spotted the fact that this will cause the ball to do an unrealistic snap
turn when changing direction, bonus points for us - we're a born animator.
However, for the simplicity of the example, let's ignore that for now. It will
be easy enough to fix in the real world, once we examine how the existing code
works.

  All we did differently was assume that the clock would run 0 to 2, and that we
wanted to be working with a normalized value instead. So when the clock goes
over 1.0, POV assumes the second phase of the journey has begun, and we declare
a new variable Elseclock which we make relative to the original built in clock,
in such a way that while clock is going 1 to 2, Elseclock is going 0 to 1. So,
even though there is only one clock, there can be as many additional variables
as we care to declare (and have memory for), so even in fairly complex scenes,
the single clock variable can be made the common coordinating factor which
orchestrates all other motions.

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message