Cupiii
commented
2 years ago 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.
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.