Babylon.js: Mesh rotation in inspector breaks when changing sliders, particularly on X axis

Created on 19 Oct 2020  路  18Comments  路  Source: BabylonJS/Babylon.js

Repro

  • Load a mesh into the sandbox
  • select the mesh root and open the inspector
  • use the rotation sliders to change the mesh rotation one at a time on X, Y, and Z and slide the value from 0-360 using euler angles.
  • Expected result: you can set any angle on an axis without incurring a change on the other axes. You can also smoothly rotate the mesh 360 degrees in any axis
  • Current result: For Y and Z the mesh rotates fairly smoothly, but there are a couple of points where the values seem to jump. On X once you hit around 90 degrees, the Y and Z axes start jumping around and the X axis actually reduces in value as the slider continues to move to the right. The mesh also seems to jump to different rotations on incremental changes in the X rotation making the mesh feel as though it's spinning randomly.

Video
Repro of issue attached below:
rotationBug.zip

bug

Most helpful comment

I think this is a reasonable solution. Let's go with this and test.

All 18 comments

I'm afraid this is inherent to how we compute the eulers from the rotationQuaternion. This is the problem with the UI hiding the quaternion. We are constanly converting from euler to quaternion and at some point (like 90) we can have multiple solutions hence the jump.

Adding @RaananW to get a second thought

I guess an input field instead of the slider will make it feel a little less buggy. Showing quaternion axes make no sense, and the only other solution would be to actually show a box with orientation texture on it.

@PatrickRyanMS ok for an input field?

Sounds like a plan. Was on my list since I already did the work for NME! 馃憤

I've been thinking about it and while a slider is much nicer for quickly rotating an object, we do have the rotation gizmo that duplicates that behavior. So if we need to go to an input field, I think that is ok since we still have a backup path to do interactive rotation.

Another suggestion (very unpopular, i guess :-) ) would be - whenever someone changes the input, revert back to euler instead of quaternion in code. Instead of constantly converting, convert once and store it in code.

The only issue i see is that the user will still think that quaternions are being used. What we could do is - on component unmount, convert back to quaternions (of course, only if it was a quaternion in the first place). this might change the euler values if the user goes back to this tab, but will allow using the sliders correctly.

Sounds like it could work. Since this is just in the inspector, we aren't saving the values anywhere so I don't think we lose anything by converting to euler and leaving it there until it's unmounted. What do you think of that, @deltakosh?

@RaananW, wouldn t this break the recorder to which creates the replay of the inspector actions by forcing it into euler ?

I would rather prefer to not change that core behavior honestly. I commented on the other PR to simply let the sldiers when eulers are used and always have a visual indicator for the users that they are manipulating a quaternion behind the scene

Furthermore if the rotation is being manipulated when we open the inspector panel

they are manipulating a quaternion behind the scene

The issue here is that it is impossible to fluently convert euler to quaternions. at a certain point the axes flip (becuase we convert on each frame euler -> quaternion -> euler). Maybe ignoring the final part (back to euler) will be an acceptable solution? On load we create a cached euler vector, and only convert it to quaternion, but never back. so the quaternion is internally updated, we don't reset anything, and the sliders are smooth.

but you miss all the transform done outside of the inspector (like animations)

Yep, you are right. But otherwise it's unusable for quaternions. We could of course show the quaternion values instead, but we need to notify the user that they need to know how to work with them to set a proper rotation

yep hence I think we should keep the slider for rotation, use input text when rotationQuaternion and simply add a label which says:" current rotation is using euler / quaternion"
We should also then add a button to switch between both (like I click on the button and my node uses euler or quaternion)

I think this is a reasonable solution. Let's go with this and test.

how are we on this topic @msDestiny14 ?

On it right now! :D Makes sense to me. Will update the PR with screenshots to double check.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

deltakosh picture deltakosh  路  23Comments

deltakosh picture deltakosh  路  23Comments

deltakosh picture deltakosh  路  17Comments

individ2016 picture individ2016  路  39Comments

innerground picture innerground  路  59Comments