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.

Post a reply to this message

I think most folks would do this with one scene, but either will
work.  Chris Colefax created some cool utilities that allow you
to have "custom" clocks (i.e. functions applied to the standard
clock) for things like this that you might look into...

Chuck Roberts <rob### [at] accnorg> wrote in message
news:37C428F2.5837E4C7@accn.org...
> 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.

Post a reply to this message

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

If you had the Superpatch, you could say:

#declare righthere=spline{
    0, <0,0,0>
    0.3, <0,0,1>
    1.0, <0,0,2>
}

#declare overthere=spline {
    0,<0,0,10>
    0.3,<0,0,10>
    0.6,<10,0,0>
    1.0,<0,0,10>
}

camera {location righthere(clock)
             look_at overthere(clock)
            angle 30
}

This is a more elegant and intuitive situation than setting up a
complicated knot of if then's.  If you want extremely smooth motion, insert
more points, or master cubic splines!



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.

Post a reply to this message

Greg M. Johnson <gre### [at] geocitiescom> wrote:
: #declare overthere=spline {
:     0,<0,0,10>
: ...

:  look_at overthere(clock)

  Is this another inconsistency in the superpatch? It #declares an
identifier, but uses it as if it was a #macro.

  How many inconsistencies are there in the superpatch? I know of 2 right
now.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message