Can you try orthonormalizing RealCFrame in this loop?
I do not know what that is. How would I do that?
The line would be
self.RealCFrame = self.RealCFrame:Orthonormalize()
I’m not too keen on the where it should be in the loop, so some experimentation might be needed. Maybe after the increment?
If orthonormalizing doesn’t work, is there any chance keyframe.Length is 0? Dividing by 0 will give you nan
WOW, I think it works! I’m totally unsure how it works, but it’s not glitchy at ALL now, I will do some more testing on it.
And, it doesn’t go nan, or explode.
I manually set those parameters, for the animation. I would definitely know if it’s 0.
It returns a copy of the CFrame whose rotation matrix vectors are unit vectors (divided by their own magnitude (length of 1)) and orthographic. A CFrame is not really valid unless the rotation matrix is comprised of unit vectors that are orthographic, it can lead to issues like inverted backfaces if used on a part, skewing if used on the camera, or nan as you were experiencing when doing calculations using them
Question, does this change the magnitude of the CFrame I use it on? Does it affect it in some weird way?
These are my cframes now. Looking clean. I want to mark you as a solution but I want to be SURE that everything works so I don’t have to waste my time making a duplicate post.
So it would be the exact same cframe but represented in a different way? Got it.
For the most part it is the same CFrame, but it’s a “normalized”/“validated” copy (for exact details see the gram-schmidt process) so it won’t be exactly equal in the case of calling it on an invalid CFrame, which is why you were seeing the length of the vectors change
I wouldn’t say it has an effect on the magnitude of the CFrame. @7z99 gave great information on this. Orthonormalizing can only help you in this case.
Thank you very much for this. I finally got an answer.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.