Patrick Elliott wrote:

>> 
> And you are missing the point that you can't functionally work things
> that way in animation. Lets put it any other way, you have a matrix:
> 
> |0 0 0 1|
> |4 3 1 0|
> |1 0 2 3|
> |5 2 3 0|
> 
> Or something, this is just random made up, but it serves the point.
> Where in that matrix is the "rotate this after moving it to point X, so
> that it acts like an arm, instead of rotating at the object center"?
> Even if you revert, you **still** have to then move it to the point on
> the object needed to rotate it, before also doing what ever else you
> need to make it work right. The fact that the cumulative matrix contains
> everything done to that point is ****meaningless**** from the standpoint
> of animation, because when animating you don't give a frack what the
> "final" result is, you want to render based on intermediary results,
> which changes that matrix "for every frame". If you revert it, you still
> have to keep track of what transforms you did, and in what order, so
> that you get the right matrix, which means you are **still** using up
> the memory to keep track of them in some fashion, while your seem to
> imagine that you can just wave a magic wand and have the memory issue go
> away. Either way, you have to reapply all the transforms "in each
> frame". I don't see how storing those in something that references them
> as part of the object they belong to does "anything" to change how much
> memory ends up being used.
> 
> Basically, you are still thinking in terms of a script that goes through
> in one pass, producing one "single" final result, which has to be
> rebuilt in the next frame. All objects in a script that doesn't reparse
> "never" reach that "complete" state you are going on about, they are in
> continual transition, so its not possible to just generate a static
> matrix, which automatically solves every problem. You still have to
> change that matrix in a way that produces the result you want, which
> isn't practical if you are working with an already transformed objects,
> which has multiple changes to the matrix, all of them interdependent on
> each other. And, even if you are right, I have yet to see you provide
> any example to prove either of us discussing the issue from our side of
> the line with proof that you are right and we don't get it. In fact, the
> only solution you can come up with is basically the same thing we are
> already saying, just separated from the object.
> 

I'm not all that technical as far as Povray goes, but I have made quite a
few animations of robot arms (industrial ones) with multiple joints and
tools. I never had a need for an array of transformations but always
applied transforms "from the hand back".
Sorry, can't show any code here but it's basically something like :
object { Hand rotate x * Something }
object { Wrist rotate z * SomethingElse }
object { LowerArm rotate z * AnotherSomething }
object { UpperArm rotate z * AnotherSomethingTo }
object { Shoulder rotate z * JetMoreSomething }
object { Base rotate y * Avalue }

In the end the Hand object goes through a bunch of transforms that will put
it where I want it
-- 
Ger

Post a reply to this message