Ball-orientation-Nan-fix

[Cupiii]

This fixes the ball orientation lock that occoured after a while playing.

The Skew Matrix produced more and more longer vectors in the orientation matrix.
Fix is to "kind of" normalize the single vectors inside the orientation matrix.
"Kind of": we don't need to normalize fully (dividing by sqrt(x^2+y^2+z^2)), since we don't use the vector lengthes anywhere (and also should not use them anywhere).
So we can divide by the sum of absolute values of x, y and z). Giving "somewhat" normalized vectors.

Also made the BallMovementsystem a little bit more clear, introducing some inbetween-vectors. I think the clearity is worth the small performance cost.

While analysing I added some comments about general ball-physics that may be useful in the future.

[freezy]

Awesome. I'm wondering how you came across the orthonormalization thing. But it looks solid.

The only question I have is why is it that VP doesn't seem to have this NaN issue? Is there code fixing the symptom that I've missed when porting?

[Cupiii]

Actually I debugged the vector and the values grew and grew until the two vectors used in the balltransform.localrotation were almost the same (maybe because of rounding errors with higher values) That gave assertion errors in the localrotation method. I just looked at the self-written VP-Orthonomalization code and it seems that VP does a Orthonomalization (including a normalization) there, but I'm actually not sure. Usually Orthonomalisation does not "normalize" the vectors length wise. So if VP does it within orthonormalize, it's at least unusual.

So I took a look:
VP's code is here: https://github.com/vpinball/vpinball/blob/be08b04d61096272df97bd45e6f0682043228a73/math/matrix.h#L208
VP actually does not do a true Orthonormalisation... and normalizes while orthonomalizing.

Maybe VP is faster - gave hint in the code for optimization.