I read that I "should really be storing the component vectors (rotation, translation, scale) in addition to the quaternion and matrix forms." The reason for this is that, over time, compound numerical numerical errors can build up over time from floating point limits.
This seems a bit excessive to me. I was planning on creating a Transform class that just manipulated a glm::mat4 model matrix. But now I'm concerned that this might not be the best way, however I don't really understand why. Could someone explain why and now numerical errors can build over time using quaternions?
And what should I really be doing instead? Store component vectors, but convert euler rotations to quaternion using glm::angleAxis while setting rotations, and then return a glm::mat4 model matrix that combines these things upon request? That's a whole lot of matrix math flying around every frame. I guess I could check to see the glm::mat4 has changed before assembling a new one but maybe there's a better way.
One advantage I'd have by storing the component vectors is trying to return what the current component vectors actually are. Pulling that from a glm::mat4 seems tedious. I know I can decompose a matrix, but I don't want all the decomposed components when I'm just trying to return, for example, a rotation. But... as I understand it, it needs to be decomposed fully in order to get any of the component vectors. In other words, it's all or nothing.
To restate my questions:
- What sort of use case makes matrices and quaternions lose their accuracy over time and why?
- How can I avoid this problem (or what should I be doing)? Hoping for something fast AND accurate.