Rotate Gizmo and CFrame Rotation have different rotation matrixes

The problem is simple: When the rotate gizmo is used it will give out an entirely different rotation matrix than rotating a part with CFrame angles directly

In the video I print the UpVector to demonstrate the problem more easily

I’m optimistic this is not a bug, so I come here to understand why that happens and, potentially, how I could handle these cases (since it outputs “wrong” directional vectors)

2 Likes

This is a floating point issue but is extremely close to the number you specified in properties. It looks like a relatively large number, but it is what you specified, it’s just in scientific notation.

Floating point issues look like:
1.600000000000000000000000…1
1.700000000000000000000000000…4

It’s too big and so they display it in scientific notation.

1 Like

To better explain it.
-4.37113e8 is actually 0.0000000437113, a really tiny number.

Also you have to consider gimbal lock issues. If you rotate an object by 90 degrees on one axis like you do with the X axis here, technically the Y and Z axes become the same (imagine the green circle stays in the same position, but the red circle is dragging the blue circle around) so angles at exactly 90 degrees using CFrames can get messed up.

You can use CFrame.FromEularAngles as mentioned here: https://devforum.roblox.com/t/cframeangles-help-needed/37332/5 and CFrame | Roblox Creator Documentation

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.