|
|
siggi-gross wrote:
> "Nicolas Alvarez" <nic### [at] hotmailcom> wrote:
>
>>Why not using splines?
>>
>>
>>news:web.40a4ebc89de6780ab2365a790@news.povray.org...
>>
>>>I actually work on a bigger project, showing a gothic cathedral. I am
>>>planning a cam-flight from far away toward and round the building, later a
>>>walkthrough inside the building (90-120 secs).
>>>For animating the cam-track, I was not very happy whith the implemented
>>>POV-animating possibilties.
>>>I used POV-Ray many years and even under DOS I did a lot of scene scripting
>>>by using external script-generating tools. First POV-vrersions had no
>>>#macro, so I scripted some tools, generating from a text file whith mixed
>>>POV- and Expression-code complete POV-scene files. Since I am using
>>>UNIX-System my possibilities got a lot better, especially using perl:-)
>>>Back to animation: to creat my cam-track, i make a simple text file, where
>>>all relevant cam-options are listed in keyframes e.g. like this:
>>>
>>>frame distance<0,0,0> height rotation look_at_x look_at_y look_at_z
>>>0000 500 200 0 0 23 0
>>>0200 200 100 45 0 23 0
>>>
>>>For my current project for each keyframe I declare about 26 options
>>>including cam-angle(for Zooming and wide-angle), focalblur, fog, lights as
>>>dynamical options.
>>>
>>>This KEY.INC-file runs through a perl-process which generates a
>>>POV-include-file for each frame of the animation by interpolating curves
>>>through the given control points in the keyframes. After the
>>>POV-Include-file is generated for a frame (or a set of frames), these
>>>frame(s) are rendered and attached to the animation. All these processes
>>>are managed by one perl script and can be stopped, continued or changes can
>>>be made to the cam-track whithout losing all rendered data.
>>>At the moment, this wroks only with global keyframes, but I am working on
>>>the implementation of the possibility to key each single option on
>>>different frames.
>>>Also I'm working on the possibility to change the orientation of the cam
>>>between global look_at-mode and relative rotate_xyz-mode to the actual
>>>moving vector of the cam.
>>>
>>>Anyone tried this or something similar?
>>>Coments welcome ...
>>>Siggi
>>>
>>>
>>>
>
> I've tried it with splines, but if your moving options get more than only
> position and rotation (for Cam Pos and look_at) and the pathes got longer
> and have more than 10 control points, splines have the tendency to
> interpolate not accurate enough e.g to set a proper path of the cam between
> columns of a building. The other point is, that if you change a single
> sequence of a spline, it can change the whole curve. Defining each sequence
> separate avoids this.
> Third, if I define the cam-position path not as one single 3D-curve, but as
> three curves for height, distance from <0,0,0> and Y-rotation gives me the
> opinion, that the cam moves slightly around my building (Y-rotation &
> distance are constant curves) while the cam is moving up and down even with
> hard changes in the movement.
>
> Regards Siggi
>
>
I have an old system I used to use for 'random' paths that merges an
external data file with a povray 'template' to create a series of pov
files, each one was rendered from there, I realize that dosn't take
advantage of some things, but you can have as many 'random' variables as
you want going on in a scene.
I posted a demo a long time ago of a walking creature made of
paperclips, I should put it back up on the net
interested?
--
Dan Williams, Owner
http://eds.dyndns.org:81/
Electronic Device Services
(604) 886 0316
RR8 855 Oshea rd
Gibsons BC Canada
V0N 1V8
Post a reply to this message
|
|