One finger navigation, odd behaviour

Need help? We are here.
1

New here and not sure if I’m doing something wrong.

Rotating the model with a single finger works as expected from the standard view. However, if I change to, say, Left or I double click on a face (that is not parallel with the ‘bottom’) then any subsequent single finger rotation does odd and uninstictive rotation. For example, rotating the model in the opposite direction to finger movement or rotating model around an axis at 90deg to finger movement.

Really difficult to describe so hope what I describe makes some sense.

It makes it almost impossible to rotate the model how I want without double clicking the oriention cube top right every time.

Thanks

2

In this video, Justin shows how the different finger commands work as navigation: https://www.shapr3d.com/videotutorials/camera-navigation

3

Thanks Daniel. Justin’s video is exactly as I experiment when starting with the ‘standard’ view.

However, where I goes funny is if I change to, say, the Left view and then use the same single finger action to navigate, the model rotates in a different, uninstictive way.

So say I’ve drawn a cube, I then double click one of the faces so it rotates to face square on to the screen, I then draw a rectangle on that face and then try to rotate the view to the left so I can extrude the rectangle, it doesn’t rotate as expected. Moving my finger up and down the model does rotate up and down but moving left and right the model spins about an axis coming out of the screen, not left and right with my finger.

As I mentioned before it’s difficult to describe.

4

Ok. Been playing around a bit more.

My confusion comes from the changing rotation axis following a changed grid orientation (after picking the Left view for example or double clicking a face).

As an Architect the main model Z axis is always vertical relative to a building and so left-right ‘orbiting’ always rotates about that vertical axis. ‘Alining’ a face to the screen in SketchUp doesn’t change the main Z axis orientation and so the rotation action remains constant.

I now see that in Shapr3d I’m not just orienting a face to the screen but also altering the axis about which the left-right orbiting (finger movement) is acting.

I can overcome this by resetting the grid to the XY plane each time but might there be some logic in being able to control the ‘automatic’ behaviour of the rotation axis so it doesn’t necessarily have to change with a grid change but by request if needed to work on a particular component. I haven’t thought this through at all so there may be many reasons not to do this.

Thanks for your help and for listening.

2 Likes
5

This issue is from 2018? Wow, I’m just trying the app and I can still see this problem.
If I’m using a side view, for example left view and then I try to move the camera with my finger as always, now the grid is stuck at that axis, and the camera moves in a funny way.
I’m forced to double tap the orientation cube to reset the grid and the view, but this will zoom out the scene and show me everything!
Every time I’m working on details on my model with a close zoom and I double tap the cube, the zoom reset too and I have to zoom in again, Sometimes I have to do this like 10 times in 1 minute and it’s driving me crazy!

There is a workaround for this? Am I missing something?
I tried to search on the settings, but nothing related to this.

Thanks.

1 Like
6

Have you tried enabling two finger rotation under the cam settings (top right corner, next to the cube)? Some people find it more natural.

7

I found the 2 finger option to work fine compared to the one finger one.

1 Like
8

Hello Istvan nice to meet you.
Yes I have it enabled, this way I can fix the camera, but the grid it’s still locked and the rotation is weird. I will try to upload a short video.

9

Hi @Jotagenova, when you activate the side view (or any of the views via the orientation cube), the position of the grid is changed permanently regarding your selection. If you tap on the Views icon and select the X Y Plane for grid position, you will get back to the default rotation direction

image
image2732×2048 676 KB

Is this what you were missing?

10

As a new user I cannot upload videos, so here I uploaded to my Dropbox account, this is the link.

First I show you how I just want to move the camera after creating a sketch, to extrude it, or to do anything, and the camera acts very weird (I have to use two fingers to fix the rotation, and zoom out to see where am I)

And at the end of the video I show you that after double pressing the cube, the camera is functional again.

I’m not a pro 3D modeler, I’m just starting, but I’m just using my logic.
Maybe this is how other 3D apps works, or maybe this is how desktop apps works, I don’t know this is my first 3D app ever.
But I am a tablet heavy user, I’m using touch devices all day and for graphic design apps, I’m just using my logic and telling you how is expected to work for the kind of user like me.

Maybe this behavior can be deactivated with a toggle button?

11

Yes, but with this method you are doing 3 “clicks” instead of “none” and just dragging the camera.
It’s very frustrating. In a lapse of a few minutes maybe you did 400 “clicks” instead of 100. Or 4000 instead of 1000!

And this is not the only case I feel that this apps requires too much clicks.
For example, if I select a shape and choose to scale it, then if I want to move it I need to click on the with background and then choose again the shape, and use the move tool.

Maybe I’m using it very wrong, but I watched most of the tutorials, and I think this is the way the app is designed, there is no “back” button to go and choose another tool.

Examples like this I have a lot.

12

I’m running into the same problem and frustration as Jotagenova. Moving from Top/Bottom face to Left/right face or vice versa without then having to reorient the rotation is driving me crazy!

13

I thought I was crazy… but I’m also having single finger issues navigating. Like it gets stuck on an axis almost, or an imaginary axis… it’s hard to explain. But it’s only started doing this since maybe… the last update?
Double tapping on the orientation cube and resetting fixes it temporarily.
It does seem to do this with more often with very detailed/intricate models.

I also find the same behavior using Space Mouse on Mac OS. Resetting the orientation seems to temporarily fix it as well.

14

Ahh I just ordered the Spacemouse to see if that would fix it :confused:

You can see the issue clearly in the first couple of movements in Jotagenova’s video. For the first 10-15 degrees of movement it behaves as I imagine it should, rotating around the Z-axis, but shortly after that it then starts to rotate clockwise or counterclockwise around the X-axis, just as if we were rotating using two fingers. If that is what we wanted it to do we would just rotate using two fingers. Doesn’t seem to be a way to let it just continue rotating in the same manner around the Z-axis there. Or am I missing something? Maybe this is something that can be changed in a future update? Is there a way to toggle this off?

15

The problem is called gimbal lock. It’s a side effect of using Euler angles instead of quaternions to rotate a system. An implementation change is needed way down in the math somewhere, not a UI or input device change. It has nothing to do with the complexity of the model.

The easiest way to see it happen is to start a new design, tap the Top surface of the orientation cube (so we’re looking down the Z axis at the XY plane), then swipe left-to-right on it. Expected behavior is that the world rotates around the Y axis and the Left face comes to the front. That happens at first, but partway through the rotation, X and Y lock together and it starts rotating about the Z axis instead. It’s completely impossible to pan the view from Top to Left directly (you can do it in two steps by tapping Left and then tapping the clockwise arrow). But if you try the same motions in Fusion360, it behaves as expected.

Here’s a short video that explains what’s going on and how to fix the math with nice animations.

3 Likes
16

In this post I’ll try to illuminate why these things behave the way they do, hoping that you’ll understand the constraints we’ve considered when we came up with the current behaviour…

In 2D, bodies have one degree of rotational freedom, so things are pretty simple in an app like Photoshop, which only deals with 2D stuff. On the other hand, when we add one more dimension, things become much more complicated! 3D modellers know that 3D bodies have three degrees of rotational freedom, which poses a problem: our commonly used input devices work with two dimensional data (i.e. cursor x,y position), which is not enough to cover the space of possible rotations.

Various applications use different techniques to work around this problem, each with their own tradeoffs. One way to do it is to simply throw away one degree of freedom, and map the x,y coordinates of the mouse to a two-dimensional subspace of all rotations. Basically all FPS games do this, where the x-displacement of the mouse rotates the camera around the world Z axis (here Z = up), and the y-displacement rotates around the camera’s X axis. This is mostly intuitive, because humans don’t often tilt their heads like dogs do, so people don’t miss this lost degree of rotational freedom from FPS games. This way of rotation is the default behaviour of most 3D modelling tools as well, because if you have a “ground plane” in your model (like the grid in Shapr3D), this technique will ensure that the horizon always stays level. This is also what Blender does by default, and this is what Fusion360 calls “Constrained Orbit”. This is also called “turntable-style camera motion”.

In Shapr3D, this means that the horizontal motion of your finger/cursor will rotate the camera around the normal vector of the grid (the Z axis with the default grid). This works very well in 3D, but consider what happens when you look straight down: horizontal motion of your finger causes the image to rotate clockwise/counterclockwise, and you will keep facing the grid. This is due to the fact that the normal vector of the grid points straight towards you. In 3D this is a pretty rare occurrence, so the turntable-style camera rotation is fine while we’re in 3D. But when you enter 2D mode by e.g. double-tapping a face, it is precisely this head-on grid scenario that we end up with! Some of you might remember that back in 2018 Shapr3D was using this turntable-style rotation even for rotating out of a 2D view, which was very annoying and counterintuitive, so we sought to improve on it: we knew that when rotating out of a 2D view, people expected the object on the screen to rotate as if they were dragging the surface of a ball. Geometrically speaking, this meant that the camera should rotate around an axis that’s perpendicular to the direction of the motion of your finger. This is sometimes called “trackball-style camera motion”, or “Free Orbit” in e.g. Fusion360.

The only problem with it, is that it produces a path-dependent camera trajectory: moving your cursor up 100 pixels and to the left 100 pixels produces a different camera orientation than moving it 100 pixels to the left and 100 pixels up. To get a feeling of what this means, play around with the demonstrations on this page: Internal Combustion Engine – Bartosz Ciechanowski . You will find that once you rotate the models a bit, it is very-very hard to get them back to their original upright orientation! This is due to the path-dependence of this rotation mechanism (which is due to the non-commutativity of 3D rotations), and this is why free orbit is not really a good choice when there’s a specific upright orientation of your model or a ground plane (i.e. grid).

So in Shapr3D, we do something clever: when you start dragging your finger to rotate out of the 2D view, we start rotating the camera with the “free orbit” way, but only until a certain threshold! Past this threshold, we start incrementally adjusting the rotation axis, so that at the end of the dragging, it will nicely line up with the normal vector of the grid, and you end up with the usual turntable-style rotation in 3D. This also ensures that there’s no way of quitting the 2D view such that you would end up with a non-level horizon in 3D.

In certain cases, this rotation axis correction can be up to 90 degrees, like when you try to rotate from the Top view to the Left/Right. It might feel similar to the gimbal lock phenomena that @dwineman talked about, but I can assure you that there’s no such thing going on - I have the source code in front of me, and it uses quaternions throughout :slight_smile:

@robischulze, using a SpaceMouse will eliminate all of these issues, because unlike a regular mouse it has all 3 degrees of rotational freedom, so there’s no impedance mismatch between the input device and the geometric nature of 3D rotations.

4 Likes
17

Wow, it really does feel exactly like gimbal lock. I was convinced but I appreciate the correction. I notice now that when I put F360 into “Constrained Orbit” mode, its cube behaves more like Shapr’s. Sorry for doubting you!

However. Could I suggest that maybe a different strategy is called for when using the orientation cube vs. panning the canvas? With the cube, small movements are magnified (which makes sense; you’re using a tiny lever to move the world), and it’s right up against the corner, which complicates things when your finger/mouse hits the edge of the screen. The result is that even though, as you say, large axis corrections only happen in certain cases, it’s very easy to pan through one of those cases by accident, so I often find my model spinning chaotically and have to reset to the origin view and try again. Going through this several times while trying to select, say, the inner faces of a hexagonal hole in a zoomed-in part of the model (and you have to zoom WAY in to avoid mistapping and deselecting everything) is massively frustrating. And even if I learn to do my rotations in the right order without careening off into space, that muscle memory doesn’t translate to other models, or even to other parts of the same model that are oriented differently with respect to the X/Y/Z axes.

This would be solved if the cube always worked in free orbit mode. It would give me absolute freedom to pick the orientation I need at any moment. If I get a crooked horizon, that’s my fault — but I don’t always care about the horizon or even the grid; I just need to get a particular edge into view so I can select it, or find that one perspective where the control handles of a large object are onscreen. Fine adjustments to the camera angle are maddeningly unpredictable because the behavior of every navigation method is dependent on the orientation of the model. There needs to be at least one that isn’t.

18

@zaza_Shapr3D Thank you so much for talking through this process. It’s really fascinating. I’m coming from fusion360 and understand now how I have the “free-orbit” way ingrained in my brain. Hopefully once the SpaceMouse arrives I’ll feel completely at home again.

However, after digesting your post a little bit I went back into a couple of my project files and noticed that the orientation of my models never actually matched the orientation of the cube. This makes a HUGE difference! Simply rotating my models with the transform function so that the Front/Top of the model matched the Front/Top of the cube, the movement felt wayyy more natural all the way around. I can confirm that not having the orientation match in Shapr3D is a recipe for frustration! After playing around with it for just a little, I my brain with retrain quickly. But, having the orientation of the model correct is KEY.

I guess with Free-Orbit the orientation of the actual model doesn’t matter as much as it relates to camera movement as it would all behave the same, correct? Hopefully that explains my negligence of orienting my model correctly to begin with as it never made this drastic of a difference to me previously. Your clarification helps a lot and thank you for explaining this to us!

19

However, after digesting your post a little bit I went back into a couple of my project files and noticed that the orientation of my models never actually matched the orientation of the cube. This makes a HUGE difference! Simply rotating my models with the transform function so that the Front/Top of the model matched the Front/Top of the cube, the movement felt wayyy more natural all the way around.

Indeed, it makes sense to organize your model in a way that the top of the model corresponds to the Top (i.e. +Z direction) in Shapr3D. Actually, it’s not really about the Top/Left/Front/etc. directions on the orientation cube that matter, rather it’s the position of the grid plane that determines how camera rotation works in 3D. By default the grid is on the XY plane, so the Top side of the orientation cube will correspond to the upwards direction, but you may as well place the grid on the YZ or ZX planes if that suits your model better - you don’t need to transform the model itself.

I guess with Free-Orbit the orientation of the actual model doesn’t matter as much as it relates to camera movement as it would all behave the same, correct?

Correct! The “free orbit” behaviour has no intrinsic “upwards” direction baked into it. The price we would pay for that is the path-dependence I’ve described in my previous post, that makes it hard to control for most people.