On May 4, 2009, at 5:54 PM, Javier Ángel Velázquez Muriel wrote:
1) I found problems with Rotation3D when designing project(). I coundn't make it work as I needed it. Hence the matrices.
If there are problems/limitations with Rotation3D, we should fix them rather than add a new class.
I agree.
2) EulerAnglesZYZ is a way of enforce the ZYZ convention when using EulerMatrixZYZ. Just a nice way of constructing a EulerMatrixZYZ whitout passing a Vector3D, as you suggested with SphericalCoords.
We already have constructing a Rotation3D from your choice of Euler angles (and you can get a matrix from that if you want). So there isn't much reason to be passing them around at all.
No, that is not true. Given that no convention was established, there is freedom to use anyone. I checked, and ZYZ was not in the code, so I added myself. This convention is common in EM (Rot, Tilt, Psi). I didn't pass anything around.
I definitively need the code.
Sure, the question is more whether it should be part of the API or in an internal header or .cpp file where it is used. So far I don't see anything that justifies creating an alternative rotation passing convention (which would require lots of functions to be eventually duplicated to support both)._______________________________________________
I will be happy hearing about any improvement in the API. I'm worried though about project(). It should work at least as it is working now, and respecting my choice of angles and rotation interface requesting a matrix, because that function is at the core of my project and I want that performance. If it can be improved, I gladly will acknowledge any contribution. As long as the function is able to access what requires, I don't mind the way it is done. I can provide stringent tests that I decided not to finally put in actual tests.