I wonder if better rotation modes would be possible with multitouch inputs, I.e. using two "touch points" instead of one. Then you could span a plane between the two points and the origin and use this to better derive the user's intention which axes should be rotated.
Interesting but lacking some information. First up, of course, most people are familiar with rotating the camera rather than a single object. This is how most 3d viewers work, even if the orbit point is locked to the center of an object (e.g. in a 3d product display). So it's important to specific which we're talking about in an introductory article on 3d rotation methods.
But, ok. We're talking about schemes to rotate a single object rather than the camera.
The turntable controls they talk about are a special case of gimbal controls where we lock rotation to one or two axes. But in my personal experience, when it's two or three axes people still call it gimbal controls whereas turntable controls is rotation in a single axis (as if on a turntable, hence the name). But then again, 3d terminology is so mixed up across different fields that maybe some people have only heard the two axes version called a turntable. Not a big deal, but why no mention at all of gimbal controls?
Then, trackballs. In my experience, when it's limited to a single hemisphere of rotation, these are called arcball controls. Trackballs are supposed to emulate a trackball mouse which don't have this limitation.
And finally, no mention at all of the dreaded gimbal lock (where two of axes end up overlaid on each other and the controls loses a degree of freedom), which is a major reason for choosing one type over another.
Overall, not an amazing article. I checked it again to see if I missed anything and realized it's a blog post for some app - so, basically an ad - which probably explains the lack of effort.
Gimbal lock purely a consequence of implementation detail, completely independent from the three modes of interaction. Otherwise, I agree with the rest of your comment.
Yeah the very first comparison in the article between Blender and Mesh lab is mixing camera rotation vs object rotation.
It's also missing the absolute most natural user interface for rotating objects, which is when you are in VR or with hand tracking. If you have only one hand controller you attach the object to it so you can simply inspect it under any angle, and if you have two-hand tracking you can have translation, scale and rotation based on a virtual segment between the hands. The little Leap motion device worked like this it was very natural.
> There's another, more subtle critique of this system: it lacks path independence. This means that if you start and end a drag with your mouse at a particular location, the rotation will depend on the path that your mouse took.
Actually, when I accidentally tumble models with that kind of UI, I just drag it in a circle until it's right side up.
I accidentally found how to do this while using a solid modeling software and use it quite a bit. I don’t see a formal name for this maneuver, or anyone teaching it. ‘Gimbal tumbling’ is the closest description.
For freely rotated objects, trackball rotation is only ever appropriate for touch screens, mice should use tumbler instead so that you don't have to pay attention to the absolute position of the cursor.
I can't defend tumbler. But with regards to turntable vs non-turntable (which if you are unlucky might default to tumbler), I have some ideas. In general I feel more comfortable with turntable mode (and have used it in Blender, game engines, and robotics software). When I started learning CAD I initially switched from the default trackball to turntable as well but after a while I switched back to trackball.
Turntable makes most sense when there is well defined and easily identifiable up direction like when you are working with 3d environments or humanoid models. With mechanical parts that you make in CAD software up direction isn't always as clear, you can easily forget where the up was if you don't pay attention to axis gizmo. Plenty of parts can have critical features on all sides, and the preferred "up" direction in most useful views for the part doesn't necessarily match with the up direction of whole assembly.
Turntable view has one downside which the article didn't mention - lack of "state independence". The behavior of mouse movement depends on the angle from which you looked at the start. This can result in situations where you meant to rotate around one axis but it rotates around different one or the rotation happens in opposite directions. Tumble and trackball don't have this problem as rotation isn't affected by global axis direction.
One more potential factor is use of 3d mice. I haven't used one myself, but I would assume that it somewhat avoids the most confusing aspects of non turntable modes. Thus in the best case reducing the need to improve default behavior for regular mice, in the worst case hacky 3d mice integration depending on the chosen rotation style which might brake if something other than tumbler is chosen (I really hope that no 3d software does this, but I lack the experience to confirm this).
This makes me wonder has any software tried dynamic turntable. That is turntable where the role of z axis is replaced by whichever axis was closer to up at the start of mouse drag. Always one of the 3 axis, not the local rotation up direction.
It's more flexible. For example, compare the "Turnable" and "Tumbler" rotations in the article; you will be able to set arbitrary orientations in the latter, but not the former.
More like you are accidentally forced into arbitrary rotations with the tumbler, because of how moves correspond to inconsistent axes depending on the way you're turned.
Honestly I don't see that supposed failing as much of a downside really, because A) most of those extra rotations don't change the camera view in any meaningful way, they just roll it, B) you can typically rotate the object on top of the camera if you really need these rotations, and C) it makes control much more accurate.
I once implemented tumbler, but always used the starting position and current position to determine the rotation. This make it behave the same way when the mouse follows a straight path, but also makes it path independent.
I wonder if better rotation modes would be possible with multitouch inputs, I.e. using two "touch points" instead of one. Then you could span a plane between the two points and the origin and use this to better derive the user's intention which axes should be rotated.
Interesting but lacking some information. First up, of course, most people are familiar with rotating the camera rather than a single object. This is how most 3d viewers work, even if the orbit point is locked to the center of an object (e.g. in a 3d product display). So it's important to specific which we're talking about in an introductory article on 3d rotation methods.
But, ok. We're talking about schemes to rotate a single object rather than the camera.
The turntable controls they talk about are a special case of gimbal controls where we lock rotation to one or two axes. But in my personal experience, when it's two or three axes people still call it gimbal controls whereas turntable controls is rotation in a single axis (as if on a turntable, hence the name). But then again, 3d terminology is so mixed up across different fields that maybe some people have only heard the two axes version called a turntable. Not a big deal, but why no mention at all of gimbal controls?
Then, trackballs. In my experience, when it's limited to a single hemisphere of rotation, these are called arcball controls. Trackballs are supposed to emulate a trackball mouse which don't have this limitation.
And finally, no mention at all of the dreaded gimbal lock (where two of axes end up overlaid on each other and the controls loses a degree of freedom), which is a major reason for choosing one type over another.
Overall, not an amazing article. I checked it again to see if I missed anything and realized it's a blog post for some app - so, basically an ad - which probably explains the lack of effort.
Gimbal lock purely a consequence of implementation detail, completely independent from the three modes of interaction. Otherwise, I agree with the rest of your comment.
Yeah the very first comparison in the article between Blender and Mesh lab is mixing camera rotation vs object rotation.
It's also missing the absolute most natural user interface for rotating objects, which is when you are in VR or with hand tracking. If you have only one hand controller you attach the object to it so you can simply inspect it under any angle, and if you have two-hand tracking you can have translation, scale and rotation based on a virtual segment between the hands. The little Leap motion device worked like this it was very natural.
> There's another, more subtle critique of this system: it lacks path independence. This means that if you start and end a drag with your mouse at a particular location, the rotation will depend on the path that your mouse took.
Actually, when I accidentally tumble models with that kind of UI, I just drag it in a circle until it's right side up.
I accidentally found how to do this while using a solid modeling software and use it quite a bit. I don’t see a formal name for this maneuver, or anyone teaching it. ‘Gimbal tumbling’ is the closest description.
For freely rotated objects, trackball rotation is only ever appropriate for touch screens, mice should use tumbler instead so that you don't have to pay attention to the absolute position of the cursor.
I used to spend hours reading source code for 3D designs such as this. And sometimes having to reverse it. I like these systems a lot
I never understood why most CAD software prefers the tumbler style rotation, it's so completely horrid to use.
I guess lots of people (somehow) got used to it without knowing there's an alternative?
I can't defend tumbler. But with regards to turntable vs non-turntable (which if you are unlucky might default to tumbler), I have some ideas. In general I feel more comfortable with turntable mode (and have used it in Blender, game engines, and robotics software). When I started learning CAD I initially switched from the default trackball to turntable as well but after a while I switched back to trackball.
Turntable makes most sense when there is well defined and easily identifiable up direction like when you are working with 3d environments or humanoid models. With mechanical parts that you make in CAD software up direction isn't always as clear, you can easily forget where the up was if you don't pay attention to axis gizmo. Plenty of parts can have critical features on all sides, and the preferred "up" direction in most useful views for the part doesn't necessarily match with the up direction of whole assembly.
Turntable view has one downside which the article didn't mention - lack of "state independence". The behavior of mouse movement depends on the angle from which you looked at the start. This can result in situations where you meant to rotate around one axis but it rotates around different one or the rotation happens in opposite directions. Tumble and trackball don't have this problem as rotation isn't affected by global axis direction.
One more potential factor is use of 3d mice. I haven't used one myself, but I would assume that it somewhat avoids the most confusing aspects of non turntable modes. Thus in the best case reducing the need to improve default behavior for regular mice, in the worst case hacky 3d mice integration depending on the chosen rotation style which might brake if something other than tumbler is chosen (I really hope that no 3d software does this, but I lack the experience to confirm this).
This makes me wonder has any software tried dynamic turntable. That is turntable where the role of z axis is replaced by whichever axis was closer to up at the start of mouse drag. Always one of the 3 axis, not the local rotation up direction.
It's more flexible. For example, compare the "Turnable" and "Tumbler" rotations in the article; you will be able to set arbitrary orientations in the latter, but not the former.
More like you are accidentally forced into arbitrary rotations with the tumbler, because of how moves correspond to inconsistent axes depending on the way you're turned.
Honestly I don't see that supposed failing as much of a downside really, because A) most of those extra rotations don't change the camera view in any meaningful way, they just roll it, B) you can typically rotate the object on top of the camera if you really need these rotations, and C) it makes control much more accurate.
I once implemented tumbler, but always used the starting position and current position to determine the rotation. This make it behave the same way when the mouse follows a straight path, but also makes it path independent.