[4.2 beta] Top Perspective and Ortographic view is unsmooth and unstable

[Liger0]

Application version
4.2 beta

Platform
Win 10 x64

Printer
Any

Reproduction steps
Select Top view

Actual results
If you try to rotate with right mouse usage, it will be unsmooth for some seconds (even 10+ in ortographics mode, since it won't read up/down movement of the mouse) and change type of top view .
If you click the top view icon again, it will change type of top view the same way as before.

Also, only using ortographics mode, the red/green axis from the top view are not visible at any zoom level.
Using perspective mode, the axis only disappear zooming out a lot.

Expected results
Top view should work like other views.

Additional information
https://www.youtube.com/watch?v=OZf8UvdUzBA

[smartavionics]

I get the same behaviour when using both perspective and orthographic views. With top view selected, rotating the view causes an immediate "flip" through 90 deg.

[Liger0]

How do you switch between perspective and orthographic view?

[smartavionics]

There's a menu item (View -> Camera View) and you can also set your preference in the settings dialog.

[Liger0]

Thanks. I recorded the video in perspective mode. Using ortographics mode I can't really see the axis colours, they are mostly hidden by the plane as the lines are extremely thin at any zoom level.
This doesn't happen with perspective unless you unzoom a real lot. Updated report.

[nallath]

Your youtube link doesn't work :( I also don't get what you mean by "unsmooth"

[smartavionics]

For me, selecting the top view and then rotating the view causes an instant "flip" through 90 deg.

[smartavionics]

Perhaps it's always done that but as I don't normally use the top view, I wouldn't know.

[smartavionics]

Isn't it just that the initial orientation you get when you click on top view is wrong, here's an image immediately after selecting top view...

Notice where the red/blue/green lines are, the're in the top left corner instead of the bottom left corner as you would expect.

As soon as you rotate the view, it flips to the correct orientation.

[nallath]

Weirdly enough, it only does that on the first time it's pressed.

[Ghostkeeper]

This is occurring because of the Gimbal lock. Because of orthographic view, we made the top view display an exact top view now so that things can be measured more easily. Previously we limited the camera so that it could not come within 0.1 radians of the very top to prevent the gimbal lock.

The top view button sets the camera to the exact vertical, on top of the gimbal lock. Since you can't move the camera upside down, you can only drag the cursor in one direction, the one that would tilt the camera more horizontally. In the gimbal lock though any sideways motion is an infinite amount of rotation which then changes the direction of "down". So if you drag the cursor sideways and then down there is basically only 50% chance that you're actually going to be able to move the camera down.

It's a well-known problem in computer science and the reason why we've avoided the gimbal lock so far, but due to Orthographic we decided to allow going to the gimbal lock via the Top view button.

When rotating the camera it should snap back to 0.1 radians away from the gimbal lock, and then allow you to move the camera normally.

I'd say this is expected behaviour.

[smartavionics]

I'd say this is expected behaviour.

Given your description above, that may be true, it's not my area of expertise. Nonetheless, it still looks like a bug from the user's point of view.

[Ghostkeeper]

That's true, but we're talking about one of the most common game UX bugs out there. The only real solutions are the one that we had previously (prevent getting too close to the gimbal lock which would make the mouse rotate the camera infinitely fast) or to allow the camera to go upside down.

Many 3D modelling applications choose the second route, to allow the camera to go upside down, since they don't really have an up or down side apart from what you model in yourself. But since we have a build plate it's logical to keep the camera pointed upright.

When the camera needs to be pointed upright (the UP vector always has a positive Z coordinate) you need to stay away from the gimbal lock. We've only made an exception in this case when you press that top view button because you want to be exactly on the top view then. So yes it's going to be slightly hard to deal with infinitely fast rotation.

[Liger0]

I made the youtube video public I'm sorry. Take a look please. The vertical movement doesn't work for a good amount of time when you are in top view. The flip also happens every time you select or double select top view after a view movement.
And axis in perspective mode are hidden.

[JohnEdwa]

@Ghostkeeper So right now it's "working as intended" that you actually can't use the mouse to rotate the model in a way that shows it straight from above or below, instead it seems to stop maybe 10 degrees too early and to get the top view or bottom view you have to select it with the camera position buttons/menu item?

When you do select the top view, it locks it to that unless you do a quick and large enough move with the mouse to "free" the camera again - would it make sense to do this in reverse as well, where once the user has rotated it to as top-view as it can go, it would snap to the actual locked top view automatically?

---

Also, I do also think that the axis colour bars should be thicker. The build volume outlines are always drawn one pixel wide, would it be possible to make sure the axis bars would always be at least two?

[Ghostkeeper]

@Ghostkeeper So right now it's "working as intended" that you actually can't use the mouse to rotate the model in a way that shows it straight from above or below, instead it seems to stop maybe 10 degrees too early and to get the top view or bottom view you have to select it with the camera position buttons/menu item?

Yeah, that's right. This has been the case since the first Cura release. This is to prevent the Gimbal lock.

When you do select the top view, it locks it to that unless you do a quick and large enough move with the mouse to "free" the camera again - would it make sense to do this in reverse as well, where once the user has rotated it to as top-view as it can go, it would snap to the actual locked top view automatically?

It should move away from the top view as soon as you drag. There is some lenience though of what Cura considers "dragging", otherwise a simple right-click of someone with mild Parkinson's will start dragging.

The axis bars are the same size in ortho. However they are a bit thin if you zoom out far (also in perspective). They haven't changed in years, but maybe we could make them a bit fatter.

[Liger0]

If you see my screenshot, in ortho mode the axis are not visible no matter the zoom.
Also, wouldn't forcing Cura to believe the top view has been double clicked instead of clicked once bypass the rotation bug? This would work because only the first time you do it the rotation will change, unless you drag and move the visual again.

[Ghostkeeper]

We've made the axis bars thicker in 4.3: bb34e0d

The gimbal lock problem still exists as far as I know.

[GregValiant]

I'm cleaning house.
Is this still a problem with current Cura versions (5.8.0 and up)? Can I close this?

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.