Godot: Spatial::rotate() can scale objects!?

[cooperra]

As a new user, I was giving rotate() wrongly-formed vectors (they weren't normalized), except instead of a crash or warning, my object shrank, which was very unexpected.

I would have expected auto-normalization, a warning, or an error, but not scaling!

Example:
Repeatedly call rotate(Vector3(0.2,0,0), 0.05) and watch your object spin and shrink.

Arch Linux - Godot 2.1.3
See also: #8113

[Zylann]

As I understood earlier, it's because there is no auto-normalization so float precision or not-normalized vectors will cause the transformation matrix to drift in an invalid state (remember maths, rotation uses the same matrix cells as scale does). I think it can even shrink after some time if you feed vectors coming from your object, because no normalization happens in the feedback loop. So whenever the API expects a normalized vector, make sure it is.

[ghost]

As I mentioned in #8113, the only proper way (without relying on the user) I can think of to fix this is to split the basis into rotation and scaling parts, and store them separately.

Under the hood, the rotation part could be stored as a quaternion, whose normalization is easier than orthogonalization of matrix, and the scaling part as a vector. Of course, these eventually need to be converted to a matrix (on write?) such that it can be used in rendering. Also, if we go to that route, we'd need to disable write access to basis matrix.

[Zireael07]

Uh, what's stopping you from enforcing normalization on whatever vectors are passed to Spatial::rotate?

[ghost]

@cooperra If you haven't done it already, can you please try using a proper axis vector, that is Vector3(0.2,0,0).normalized(), and see how fast this happens?

[ghost]

I would have expected auto-normalization, a warning, or an error, but not scaling!

I added errors for unnormalized vectors in 3.0 for debug builds for this kind of mistakes.

To be clear, you'd eventually see this kind of scaling even with a normalized vector, because of the precision errors, so this needs to be address properly somehow.

[cooperra]

@cooperra If you haven't done it already, can you please try using a proper axis vector, that is Vector3(0.2,0,0).normalized(), and see how fast this happens?

That's pretty much what I ended up doing, except with my game's vector instead of the example's. It worked perfectly.

[ghost]

Ah, OK. Apparently it happens slower than I thought. Feel free to close this issue, I'll open another one for separating basis into rotation and scaling.