|
 |
On Thu, 07 Jan 1999 19:16:50 -0800, Tony Vigil <tvi### [at] emc-inc com> wrote:
>Ronald,
>
>Thank you very much for your in-depth lesson on tranformation sequences! This is
>basically what I thought I would have to do, but didn't want to. It would be so much
>less convoluted if we could just use local coordinate systems.
Perhaps. One way to do so, I would think, is to have a set of macros to do
global transformations that has the side-effect of storing the current
transformation matrix into an array. This will require a touch of linear
algebra on the part of the macro writers, though. Then, in addition, have
another set of macros to do local transformations that first transforms by
the inverse of the current matrix, then performs the appropriate local
transformation, then transforms by the current matrix. Finally, these macros
would have to update the current matrix using multiplication from the left.
(i.e. if the matrix is M and the new transform is T, the matrix should be
updated to TM) Note that the way POV's matrices are implemented they are not
square. I think one has to add a fourth column consisting of the transpose
of (0 0 0 1) to make such multiplications work, and ignore that column when
using the matrix to do transformations within POV, but I haven't verified
that.
Of course, as you say, a patch to do this (or at least a patch to retrieve
the current transformation matrix for an object into an array) would be quite
useful. The problem is, not all objects keep the current transformation
matrix as such. If you take an otherwise untransformed sphere, for example,
and scale isotropically, it just adjusts the center and radius appropriately
and leaves the current transformation matrix empty. Rotating or translating
such a sphere only affects the center, again leaving the transformation
matrix empty. So unless you apply a matrix or an anisotropic scale to a
sphere, it has no transformation matrix to retrieve. Changing this might
have a serious impact on rendering time.
Post a reply to this message
|
|
