If you can't manage to construct a Rotation3D from your Euler angles and rotate things, which us all the classes are doing, then that is a problem with Rotation3D or its docs as such should be simple enough :-)
Also, the 2D rotation should be Rotation2D by symmetry. Whether it is stored as a matrix or not is just an implementation detail.
I'll be in shortly.
On May 5, 2009, at 8:38 AM, Javier Ãngel VelÃzquez Muriel <">> wrote:
It is a great advice. Sounds good. I just thought that reporting problems with my own function would not be very helpful to anybody. Instead, I created the functionality that I needed and was not there.
It seems to me the old interface with
- Rotation3D which has a rotate function
- functions to create Rotation3Ds from various Euler angles (including ZYZ, if it is not already there)
- possible caching of the rotation matrix in Rotation3D if that does speed things up
covers everything that is needed without the addition of any of the new classes and conflicting conventions. Is this right?
No. I tried building a Rotation 3D and using it and it didn't work with project(). I can provide the details of what was failing, and maybe somebody can find what I couldn't after fighting for some weeks. It would be very helpful.
Please do. Please always report any such problems, whether or not you work around them some other way. And report them immediately rather than fighting for a while as other people are more familiar with that code and so might have good ideas how to fix it. Otherwise, they won't get fixed and someone else will run into the same thing. The best thing is to provide a simple example of incorrect behavior and stick it in the bug tracker or email it to the list.
Fine, as long as project() can be accessed the way I want/need and works after the changes, I don't mind the internal way it calls rotations.