Subclick <no### [at] spam> wrote:
> say about this
> > Unlike some animation packages, the action in POV-Ray animated scenes
> > does not depend upon the integer frame numbers. Rather you should
> > design your scenes based upon the float identifier clock. By default,
> > the clock value is 0.0 for the initial frame and 1.0 for the final
> > frame. All other frames are interpolated between these values. For
> > example if your object is supposed to rotate one full turn over the
> > course of the animation, you could specify rotate 360*clock*y. Then as
> > clock runs from 0.0 to 1.0, the object rotates about the y-axis from 0
> > to 360 degrees.
> > The major advantage of this system is that you can render a 10 frame
> > animation or a 100 frame or 500 frame or 329 frame animation yet you
> > still get one full 360 degree rotation. Test renders of a few frames
> > work exactly like final renders of many frames.
> > In effect you define the motion over a continuous float valued
> > parameter (the clock) and you take discrete samples at some fixed
> > intervals (the frames). If you take a movie or video tape of a real
> > scene it works the same way. An object's actual motion depends only on
> > time. It does not depend on the frame rate of your camera.
> > For new scenes, we recommend you do not change the Initial_Clock or
> > Final_Clock from their default 0.0 to 1.0 values. If you want the
> > clock to vary over a different range than the default 0.0 to 1.0, we
> > recommend you handle this inside your scene file as follows...
> > #declare Start = 25.0;
> > #declare End = 75.0;
> > #declare My_Clock = Start+(End-Start)*clock;
> > Then use My_Clock in the scene description. This keeps the critical
> > values 25.0 and 75.0 in your .pov file.
Good point. I got a little carried away with the idea that since the song is a
fixed length and certain key frames have to match certain musical events that a
deviation from the norm might be in order. As the project is progressing though
I see that clock is still the best option. Since the music is time-based,
converting between time and frame numbers just adds another element of
complexity and possibility of error. Also, the worst case scenario of being one
frame off is totally imperceptible. (Especially at 60 FPS!)
On another note, using the spectral view of Izotope RX 8 to locate the beat
marks is working out extremely well. The software allows one to place visual
markers at any point so beats can be marked, which makes it easy to see what's
been done and what's still left. The list of markers can be exported as a text
file (including comments). Editing with the POV-Ray editor into an include file
is trivial, especially with the block selection feature.
Have an awesome day!
Post a reply to this message