In article <39905AF9.28ABD3CB@sk.sympatico.ca>, Bruce L 
<dke### [at] sksympaticoca> wrote:

> The infamous quaternions? Have to admit I'm not up on them that much
> myself, but they seem to work well with the rotation aspects. How well
> they can (could) be applied to handling scaling/translation would
> require advice from some one with more expertice. There is a fair amount
> of code laying around though.

I don't really know anything about quaternions...but everything I have 
seen about them seems to be about storing and calculating rotations, so 
they probably wouldn't be very useful. And they would have the same 
problems with animating...


> I don't know enough about the internal workings to comment, other than
> to say you could dump out a source fragment and then reparse it with an
> #include. From my understanding though, this can already be done within
> plain old POV anyways, so guessing it's just to slow? 

I don't know how slow it would be. Just parsing a single transform 
shouldn't be too bad, and it should be more memory efficient than 
storing hundreds or thousands of matrices in an array.


> Back to the spline idea <g> They're just too slow? There's code all over
> POV for several different implementations. They're fairly memory
> efficient as long as you don't have to pre-compute to much. If you use
> something like a Catmull/Rom/Clark basis, you can compute only
> those/that single value needed for the current time.

The problem with splines isn't the memory efficiency or the speed, it is 
the versatility and consistency with the other POV-Ray syntax. You would 
have to go back to storing a spline+transform pair for every 
translation, rotation, or scaling done(and matrices would require more 
than one spline). And it wouldn't make sense for animating objects in 
one area to use a different syntax everywhere else.
However, if I figure out how to interpolate transforms, it is something 
that could be applied to the whole POV language.


> One possible advantage to using splines would be that you could
> re-interpret what the control points actually ment. Instead of them
> being <x,y,z> they could mean <acceleration,inertia,friction>. Or
> perhaps a varying gravity directional vector for creating gravity wells
> <g>
...snip...
You are no longer specifying a transformation, you are specifying 
parameters for a physics engine...you should keep "transform" for actual 
transformations. Heading, speed, gravity, etc. are not transforms. 
Rotate, translate, scale, matrix, axis_rotate(which I am considering 
adding) are transformations.
BTW, I am using splines for a similar purpose in my particle patch, and 
will be using them in the physics patch, assuming I ever get it started. 
The syntax is completely different from what you have shown though. And 
they will be used for settings, but not for specifying transforms, for 
the above reasons.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message