We now have two code paths for applying rotations, affine matrices and quaternions. Affine matrices are faster for applying simple translation and rotation operations, but fall short when you have time evolving dynamics / kinematics. In this case the quaternion path is more elegant.
To allow both paths to co exist the python transform() functions should accept both objects, but behind the scenes the type is detected and handed to cdef transform_affinematrix() and transform_quaternion() functions. This would result in a much more powerful framework overall, but represents a significant API breaking change.
All the components required are being added now, but this change should be held back for the next major API breaking release, e.g. Raysect V2.0.
We now have two code paths for applying rotations, affine matrices and quaternions. Affine matrices are faster for applying simple translation and rotation operations, but fall short when you have time evolving dynamics / kinematics. In this case the quaternion path is more elegant.
To allow both paths to co exist the python transform() functions should accept both objects, but behind the scenes the type is detected and handed to cdef transform_affinematrix() and transform_quaternion() functions. This would result in a much more powerful framework overall, but represents a significant API breaking change.
All the components required are being added now, but this change should be held back for the next major API breaking release, e.g. Raysect V2.0.