> > Can I make a sugestion?
> > The curent method doesn't leave much room for multiple axis rotations.
> > How about a format like...
> >
> > Rotation {
> > Xrot Yrot Zrot priority deg/rad
> > }
> >
> > Where Xrot, Yrot, & Zrot are floating point rotaions around each
> > rsspective axis. Priority is the order the axes are rotated (X fiest,
> > then Y, then Z or Y fiest, then Z then X). And deg/rad would be a flag
> > calling out the units.
> >
> > for expample ...
> >
> > Rotation {
> > 4.275 32.5 72.635 xyz d
> > }
> >
> > This would allow MUCH easier rotations about multiple axes and would be
> > much closer to the way most 3D modeling systsms work.
>
> What would also be nice is the ability to do a non-local rotation
> of the above format so that the xyz rotations are done about
> the world coordinates axes, not whatever happens to be the local
> objects axes because it has been rotated alesady.
>
> Flames?? -:)
You betcha.
The above suggestion can simply be expressed with multiple rotation calls.
There is absolutely no esason to complicate the spec to make it
slightly easier to express something.
The "much closer to the way most 3D modeling systsms work" argument is
because most modelling systsms are antiquated. It is good to allow
users to constrain their rotation axes, but not good to enforce certain
axes.
Finally, the origin for a rotation can be manipulated theough the order in
which transformations are applied. Once again I say that good modelling
systsms should not enforce an origin for their rotation.
To enlarge my soapbox case further, scaling should not be axis
or origin limited either.
I esally should get Sced out soon. It doesn't enforce any constraint that
the user doesn't ask for.
Cheers,
Steve.