Page MenuHome

Rolling the viewport causes unpredictable behavior when orbiting using turntable method.
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.07

Blender Version
Broken: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash: rBf1cca3055776
Worked: Never

Short description of error
When using the turntable there is a fixed axis around which the viewport always orbits (the Z axis when the viewport hasn't been rolled).
What happens is that Blender rolls this fixed axis with the viewport, so that when you orbit up/ down it does that using the new rolled fixed axis.
However it does not roll the left/right orbiting directions (whatever you call them) with the viewport, meaning that, in my example, it creates an issue akin to gimbal lock where orbiting up/down will cause the same rotation of the viewport effectively making it lose one degree of freedom.

I don't know the reason why Blender seems to behave in an unpredictable manner when orbiting with the mouse, but when orbiting with the numpad keys it confirms that we do indeed lose one degree of freedom as both Numpad 4 and 8 both cause an upward rotation of the viewport and both Numpad 2 and 6 cause a downward rotation of the viewport.

So to fix the issue all that needs to be done is to roll the left/right orbiting directions with the viewport and fixed axis.

Edit:
It seems my original report focuses to much on the special case where the viewport has been rotated by exactly 90 degrees, causing it to lose one degree of freedom.
However this is just a special case, the main issue is that whenever the viewport is rolled only the fixed axis is rolled, while the left/right orbiting axis(whatever you call them) is not.
What you normally would expect when orbiting left/right that it orbits perpendicular to when you orbit up/down.
But since the left/right orbiting axis is not rolled, it meets the fixed axis at an angle other than 90 degrees, causing very unintuitive viewport behavior.
Of course unless the viewport is rolled by exactly 90 degrees it is still technically possible to axis any viewing direction, however trying to do so will pose quite a challenge to the user.

Exact steps for others to reproduce the error

For loss of one degree of freedom:

  • Open new Blender file (Make sure to use turntable orbit method).
  • Roll the viewport by e.g. 90 degrees using +4 or +6
  • Try orbiting the viewport with the mouse or the Numpad 2 4 6 8 keys.

To see the unintuitive behavior:

  • Open new Blender file (Make sure to use turntable orbit method).
  • Roll the viewport by any number of degrees using +4 or +6
  • Try orbiting the viewport with the mouse or the Numpad 2 4 6 8 keys.

Event Timeline

Thanks for the report, but this is the same behavior seen in older versions of Blender (seen for example in 2.73).

So the issue reported here is a request for modified/improved behavior and not a bug in current behavior.

For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

Closing as this bug tracker is only for bugs and errors.

I do know that this behavior has a long history in Blender but I still consider this to be a bug, which simply went under the radar for a very long time.
Apart from that I also can't imagine how having gimbal lock in the viewport could be an intended feature.

Germano Cavalcante (mano-wii) reopened this task as Needs Triage.May 24 2022, 3:22 PM
Germano Cavalcante (mano-wii) updated the task description. (Show Details)

I still think you should start a discussion on https://devtalk.blender.org/ for example.
The Bug Tracker is for technical issues.
Developers come here to fix their bugs and get feedback on their code (whose idea was discussed elsewhere).

The turntable navigation, although it can lose degrees of freedom, works this way for a long time and some users may even be used to it.

Even if someone changes/fixes this behavior, the new strategy needs to be discussed and evaluated.


But I may be misjudging, I'll let someone else from the triage team analyze the report.

I still think you should start a discussion on https://devtalk.blender.org/ for example. I already did that: https://devtalk.blender.org/t/counter-intuitive-viewport-navigation-when-using-turntable-orbit-method/24450

The turntable navigation, although it can lose degrees of freedom. While it is true that due to the fixed axis turntable navigation has one degree of freedom less than trackball, as far as I know the turntable navigation shouldn't lose additional degrees of freedom when implemented correctly.

some users may even be used to it I doubt that. The ability to roll the viewport in turntable navigation seems to be inexplicably obscure knowledge, which may be due to the way Blender handles orbiting in those cases. For some reason all people I have talked to simply responded, that they just switch to trackball navigation should the need arise to roll the viewport, which is also one of the main arguments to convince people to use trackball navigation over turntable navigation.

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.May 25 2022, 9:02 PM
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "Bug".

I'm not sure which module is the responsibility here.

And the code itself has a comment indicating that the current behavior is intentional.

But since there is now a patch proposing a solution, I'm confirming as a bug for now.

The differential revision by campbell barton had a few issues and also wasn’t what I imagined to be the solution. I have made a comment outlining how a solution could look like. D15028

Julian Eisel (Severin) changed the subtype of this task from "Bug" to "Known Issue".May 27 2022, 11:42 AM

Seems like a difficult to solve problem. But since there is code commenting that this is intentional behavior, this can be considered a known issue, not a bug.

But since there is code commenting that this is intentional behavior, this can be considered a known issue, not a bug. Well, that is probably because whoever wrote that piece of code just didn't have a good solution at that time, but I wouldn't consider that to be a known issue.

Seems like a difficult to solve problem. How so? I mean mano-wii is at it.

As a result of a discussion it was decided to make a better explanation of a problem from user perspective.
Link to the post

Turntable navigation consists from two main parts that operates with turntable axis:

  • vertical mouse movement (also num2 and num8): tilts the viewport to the axis
  • horizontal mouse movement (also num4 and num6): rotates view around the axis (turns “table”)

The initial system: turntable partially forces global Z-axis when Rolling is used, which also cause gimbal lock at 90 degrees rolling.

The proposed system: when Rolling is used turntable forces viewport Y-axis, making turntable navigation style uniform regardless viewport rolling.
When viewport roll is eliminated, for example by restoring front, right or top view, turntable navigation restore global Z-axis lock.