|
![](/i/fill.gif) |
In article <39905AF9.28ABD3CB@sk.sympatico.ca>, Bruce L
<dke### [at] sk sympatico ca> 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] mac com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |