Sane Way To Set Scale of Entity?

[bryanedds]

Hi all!

I'm wondering if there's a sane way to scale an Entity? I see that I can mutate the WorldTransform property, but that hardly seems appropriate since enough scale up / down operations would corrupt the matrix. It would be nice I suppose to have a generalized Scale property that can be applied to the WorldTransform when it actually gets composes by the engine.

Any ideas?

[Norbo]

Currently, no, there is not a unified method to set the scale of an entity. Setting the world transform with a scale-including matrix would (should) strip the matrix of any scale and use the rigid transformation component internally.

This is definitely something I want to revisit in the upcoming collision detection system rewrite. The only tricky part is integrating the scale into special cases, but there aren't really too many of those.

As for right now, it pretty much has to be done on a case by case basis. There's no good workaround to scaling a sphere into an ellipsoid (or other similar transformations) at the moment, but they could be approximated with other shapes like a ConvexHull.

[bryanedds]

Thanks for the help!

Perhaps you can clear up some deeper confusion for me. Outside of BEPU, I have only ever seen a world transform as being the instantaneous result of the composition of some local fields such as orientation and position. 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? 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?

Please let me know where I'm off here

[Norbo]

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.

[bryanedds]

Thanks Norbo! This will help me move forward with our BEPU-based game.