One topic that comes up relatively often, particularly with animators, is that the “Trackball” rotation mode (double tap R or clicking on the middle area of the rotation gizmo) can feel clunky and unintuitive. Part of the reason for this is the rotation is applied as a single axis+angle calculation based only on the mouse start and end position, which leads to unintuitive and strange rotation results if the mouse is moved tangentially to the rotation direction.
I would propose adding an alternative trackball mode, probably as a global settings option similar to viewport navigation, which applies the rotation continuously (as an accumulation of the rotation from each individual mouse movement)
Left is the standard trackball, right is with a prototype “additive” trackball rotation
There are some technical considerations and design challenges:
Proportional editing - it’s not practical to store a separate rotation matrix for each and every primitive element, but not doing this would change the proportional editing behaviour (as it would have to interpolate the final rotation matrix instead of the input axis+angle)
Non-determinism - moving the mouse from one location to another on the screen will produce a different rotation depending on the path taken (which also means details such as polling rate and viewport FPS might subtly affect rotation results). This may be a non-issue, since the purpose of the proposal is more intuitive feedback-based rotation input, but it’s worth considering
As with the above point, this would introduce an inconsistency with how other transform operators work, and we would need an alternative way of representing the final cumulative rotation for Redo operations and the F9 menu
I think it’s worth noting that the Trackball rotation isn’t designed for use with a mouse; it’s designed for use with a trackball. Trackballs were a lot more common 20 years ago, I don’t know anyone that uses one today, so it might be a good time for a re-name and re-work of this functionality
That’s interesting to hear. Just the word “track” had me thinking differently about this tool, and now I can see that’s exactly what it’s doing. It feels like it’s setting up a temp track to the cursor, so where the tool is initialized is important if one wants it to feel intuitive. Also, it has a locked in twist / up-vector, which might be less flexible for some.
In UE and Maya you click on a location near the option, over the widget, thus forcing a more intuitive setup. Also, the twist/up-vector changes during the operation, so you can twirl the mouse around to massage the twist (note: in UE, you have to active “Arcball Rotate”).
In Blender, we’re used to the cursor being off at an arbitrary position in space when doing grabs, rotations or scale, so this is probably how one expects the trackball to feel, and when it doesn’t… it feels terrible. Plus, once the object has flipped around past 180 degrees, things break. So if (for some reason) you wished to flip an object 360 degrees… it will not behave intuitively, forcing you to deactive and reactive the tool with the object in the new position. Maya and UE (4.27) basically just limit you, preventing you from fully spinning the object, thus preventing the unintuitive behavior demonstrated in @Lateasusual 's demo.
To digress a bit… maybe worth noting that in Maya you can do something similar to Blender’s rotate relative to camera, but it’s not so intuitive. In Maya, try pressing “E” to rotate, then move the cursor around the object while pressing MMB… ew.
That all said, curious to see how this “accumulative trackball rotation” feels.
I think any which way it’s added wouldn’t remove the old functionality, it would have to be optional regardless.
but in theory this will behave exactly the same as a normal trackball if the mouse is moved in a straight line, or for small motions so it realistically won’t affect people’s workflows much, given that the issues with the current trackball mostly show up more the further you rotate it.
I do appreciate understanding the default Blender trackball rotation more (target!), and see how limitations can fix the unintuitive feel of it (i.e. stay within 180 degrees).
Most of the time, animators won’t be flipping character limbs around 180+ degrees in one shot, but in other situations (i.e. inspecting a model) this behavior has a high likelihood of getting to a “broken” state after 180 degrees of rotation.
To illustrate the issues that appear when using this with Proportional Editing, I made a hacky test case with the two potential ways that proportional edits can be interpreted
In the first case, the proportional rotation when using the new trackball is limited to +/- 180 degrees - if the active element rotates further than 180 degrees away from the view direction, the proportional items will snap around to the other side:
The alternative, is to store the local rotation for each transform element and apply the proportional edit to that continuously, separately to the active object/selection. This means you can rotate beyond 180 degrees, but since the accumulation isn’t uniform (due to the falloff) and the rotation being stored per element, it can lead to some unintuitive behaviour - for example, if you change the proportional falloff distance during the rotation, it wouldn’t reset the already-rotated points:
Personally, I think that while there might be some versatility in being able to keep rotating things over and over, it almost definitely makes more sense to just limit the proportional rotation to 180 degrees (the behaviour in the top example) and to just take the snapping as a compromise with this input mode over the standard trackball version.
Change the “#if 0” in transform_mode_trackball.c:54 to toggle between the locked 180 degree mode or the persistent rotation for proportional edits (if proportional editing is disabled this has no effect anyway)
the thing is, it isn’t intuitive and right now it creates uncontrollable results when you are trying to achieve a pose, the current system rotates and twists all around and makes for either having to use XYZ separately or using the handles clicking on manipulator or having to do a lot of screen space rotations, and just quickly adds up the number of clicks that it takes to get a result that is wanted. For modeling you might not have an issue or the way you are used to is just what you are used to and don’t see it as a problem and that is fine. We are looking to improve the feel, cut down on clicks and add an option to allow users preference.