The turntable orbiting method, while being the preffered one by most users has one big problem in Blender. The fixed rotation axis is always fixed to be the global Z axis. While this works perfectly fine in most cases, it starts to cause problems when the viewport is rolled (e.g. using shift 4 or shift 6). Unlike one might expect, the fixed axis rolls with the viewport but the left/right orbiting directions (whatever you call them) stays fixed. Apart from causing unpredictable behaviour during viewport orbiting, effectively making it impossible to orbit, it also creates some really bad problems. One of these is something akin to gimbal lock, which can be achieved by rolling the viewport by 90 degrees. Trying to orbit the viewport using the mouse will now result in Blender completely acting up, but if you press numpad 2,4,6,8 it confirms that we indeed lose one degree of freedom.
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.
I consider this behaviour to probably be an oversight by the developers or a result of bad viewport navigation design. Either way it should be fixed as soon as possible.
Viewport behavior when the viewport hasn’t been rolled, seems to work as intended.
However there still is a bug when the viewport is rolled.
Do the following:
Open the differential version
Roll viewport by 90 degrees
Orbit right/left to the cube by 90 degrees.
Now orbit up/down.
Instead of orbiting up/down it now rolls the viewport.
In the master version this doesn’t happen because while orbiting it always makes sure that the fixed axis aligns with the view Y axis. You probably forgot to do that.
Apart from that:
When rolling the viewport by any amount other than 90 degrees e.g. 45 degrees the orbiting behavior doesn’t work.
Numpad keys are still broken.
Not sure how to fix that.
Have you considered trying my other suggestion of rolling the world?
If you start those actions from front view, at this moment you will have top view, but with inverted controls so orbiting up/down rolls instead of rotating and orbiting left/right rotates instead of rolling. Numpads at this moment works in the original way.
I guess it is because turntable trends to “keep the horizon” - as it is expected from turntable navigation, which follows global Z axis to achieve this (that is the reason of the original gimbal lock problem).
Do you want to propose the ability to switching to trackball behaviour if rolling was used, until using numpads or widget will reset the view, returning turntable behaviour at this moment?
Or do you want turntable always following viewport Y axis instead of global Z since rolling was used?
I also would like to mention viewport wobbling during horizontal orbiting that breaks turntable principle at local non-ortho rolled conditions.
The point of turntable navigation is clear axis-restricted circular viewport rotation during horizontal orbiting (when mouse moves horizontally across viewport during orbiting).
Here is a video - the sphere following accurate circular path during horizontal viewport orbiting except if initial conditions are obtained with non-ortho (for example, 45 deg) rolling. In this case the path of the sphere is not circular anymore:
Aw, okay, that indeed will be useful, since will provide a better navigation flexibility.
I think that description like “Ability for turntable navigation to follow the viewport y-axis instead of the global z-axis when viewport rolling is used” is a better wording for such kind of a task, that may sound shorter and clearer to devs, since describes a desired system instead of listing symptoms to avoid.
Indeed, in current version of a build turntable navigation does not properly follow viewport y-axis when rolling is used.
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.
What is proposed here I think could also solve the inverted orbit. Currently after crossing one of the poles (north and south), orbiting to the left reverses to the right and vice versa.
T98338 Rolling the viewport causes unpredictable behavior when orbiting using turntable method. (blender.org)
D15028 Fix T98338: Rolling the viewport causes unpredictable behavior when orbiting using turntable method (blender.org)
