3D Rotation Design | Hacker News Reader

3D Rotation Design

mattkeeter.com

147 pointsfisian33 comments

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.

> Trackballs are supposed to emulate a trackball mouse which don't have this limitation.

Some systems implement a trackball UI that behaves like a real trackball, i.e. it also has inertia, so you can give an impulse towards a direction and the 3D model will continue to rotate after you no longer click the mouse button, until you stop the rotation.

I do not remember using any trackball UI where the rotation was limited. When the trackball UI did not have inertia, than you would need to do 3 pushes for a rotation over 360 degrees or 2 pushes for a rotation over 180 degrees, but you could still reach any angles.

Gimbal lock happens based on how you calculate the rotations, and it could happen to both these methods if you do it incorrectly. It is not inherent to any particular style of translating user input into a rotation.

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.

Thanks for that tip! Works very well checking with the blogpost.

Yeah I will fully admit that "draw circles to yaw" is not intuitive or discoverable, but it is quite convenient when you have learnt it. I'd definitely prefer tumbler over trackball because of this.

But turntable is clearly far superior to the others. Unless you really need to yaw the model then stick with that.

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.

I love tumbler and never want to go to anything else. After a while your intuition starts to cooperate with what path your hand takes to get desired rotation. I can rotate into any orientation without thinking about it in a single sweep, including how my camera is rolled. Its honestly very powerfull, albeit hard to get used to for the first time.

It really depends on the types of objects you're trying to look at and why. The one thing that the article gets right is that turntable makes sense if the object has a natural Z orientation. Things like buildings, furniture and automobiles are obvious examples. Hand held objects get viewed from all different angles, and tumble (or trackball) makes more sense. Some of those objects may have a typical rest position where there's a natural up orientation (e.g. a computer mouse), but they can easily be rotated and viewed from arbitrary angles.

Any decent CAD system will support both turntable and tumble, defaulting to a user-selected choice, with easy options to override the behavior and switch to the other.

It's definitely harder to learn, but it's way more powerful. CAD is aimed at power users.

That circle trick mentioned elsewhere does make it bearable. Small circles with the mouse reorient it slowly. Large circles reorient quickly. So with the tumbling and the circle trick it can be tamed.

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 think the "turnable" approach would be fine if it included an extra roll control. Probably preferable due to the ease you point out; this overcomes the limit you point out.

My personal preference, and how I've set up my visualization engine (For chemistry vis projects and similar): Move the camera; not the object. FPV controls, plus a roll axis, with crouch/jump for up/down. Works best with a videogame controller, but FPS standard + Q/E is fine too! Full control, and intuitive if you've played those sorts of games. This is full 6 axis.

See circle trick comments elsewhere or briefed under your top post.

I've been told by texture artists that the Tumbler-style has advantages when projection-painting across a model with a tablet...

FYI, from 2017.

Also, Matt Keeter has some serious skills.

I always thought his Antimony CAD program[1] was neat, and sad that it seems to have died. I've yet to figure out how to get it to run on newer versions of linux (The last time I tried was about 3 years ago, and I was just using a raspberry pi.)

[1] https://www.mattkeeter.com/projects/antimony/3/

Very cool. If you like this check out the Grasshopper visual programming environment inside Rhino3d. It's also a node-based graph editor and has an extremely robust library developer community [0]. One of which I actually am.

[0] https://www.food4rhino.com/en/

> it's impossible to see the model from arbitrary angles

I don't understand this part. I could easily see all 6 faces with turntable. Does it really matters to be able to make arbitrary rotations?

The trackball implementation appears to have a numerical bug in it. Occasionally (on mac safari at least) the rendering will be blank white. If you happen to let go of the mouse during that frame, then it gets permanently stuck and requires a page refresh. Seems like it might be a divide by zero due to a small cursor delta or something along those lines.

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.

This is unrelated to viewport rotation, but I've always wanted to play with multiple inputs for posing characters. There was always a lot of interest in "full body IK" which seems like a similar idea to me. Both IK and FK imply there's an anchor point and your single (mouse) input is posing the model. With two inputs it would be more like posing a puppet where one hand anchors and the other moves. You would still have to figure out how to deal with interpolation between poses, but I would imagine posing would be more intuitive.

Turntable does pitch on x and yaw on y.

I wonder if you could achieve something like the last "spherical" solution if you did on y a combination of yaw and roll dependant on how far is your cursor from the x-center of the rotation.

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.

Even on mobile it struck me immediatelly that I cant rotate the trackball example as much as Id like without trying again.

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

Isn’t arcball rotation the gold standard for rotating 3d objects?

Yes, and it has the path independence property, as well as the ability to arrive at any orientation with a single drag.

But hey, most implementations talk about using quaternions, which scare people.

And so the author of the article (...and a lot of software) is completely ignorant of how e.g. 3DS Max, Maya, etc do it.

FWIW, here's a proper arc ball implementation. Try it vs. your favorite 3D software, and by God, implement it in yours:

(Demo requires mouse)

https://romankogan.net/math/arcball_js/index.html

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.

Reply on news.ycombinator.com