How is it that BEPU's entity world transform can be mutated while remaining consistent with the fields used to compose it? Do you do some sort of matrix decomposition when the WorldTransform setter is called?
Yup, that's it. The world transform property is really just a convenience method that wraps the center position and orientation matrix. Reading the value from the worldTransform creates a matrix from the orientationMatrix and centerPosition, and setting it sets the orientationQuaternion (which also updates the matrix representation) and centerPosition.
Earlier I said that scaling within the matrix would be stripped out. I'd like to clarify that- in the sense that your objects won't suffer from corrupted data, it is stripped out. However, for the sake of speed, the decomposition used assumes that the worldTransform provided is, in fact, a rigid transform. Under that assumption, it can simply take the translation from the matrix for the position, and the rest is considered the rotation. It will try to convert the rotation matrix into a quaternion and then normalize it.
In effect, you're guaranteed to get
some valid orientation if there is scale in the worldTransform, though it's hard to know which valid state it will be. The (internal)worldTransform property would then read back the 'interpreted' rigid transformation version of the set matrix.
If so, aren't there mathematical limits to how accurate that decomposition can be? Further, wouldn't the accumulated inaccuracies of several de- and re-compositions conspire to drift or corrupt the matrices?
If each frame built on a previous frame's repeated recomposition of a matrix, there would indeed be a little bit of drift. The main issue there would be the rotation component becoming something other than a pure rotation. It's possible to 'normalize' rotation matrices to fight this drift.
In BEPUphysics, the 'core' data used and integrated is the Vector3 position and an orientation quaternion. Normalizing a quaternion to fight drift is a straightforward procedure compared to normalizing a rotation matrix. All of the other properties are there for convenience or optimization purposes. Matrix representations of orientation, for example, are re-used many times per frame and as such are computed right after the quaternion is integrated.
