3D viewer viewport rotation control is absurd

[zenmetsu]

Is there any reason why rotation within the 3D view doesn't lock the Z-axis in place like every other tool out there (slic3r and repetierHost for instance). It is really confusing when you attempt to rotate around to look at the part from the left or right and suddenly the displayed bed is rotated off of horizontal, upside down, etc.

Left/Right should cause the camera to orbit around the Z-axis and Up/Down should change the camera elevation.

[iXce]

Agreed, that rotation is very confusing. I'll try fixing it asap.

[zenmetsu]

Thanks, that would be awesome. I'm trying to switch to Printrun from repetierHost as I'm finding that I am quite allergic to mono after a few crashes.

[ntoff]

There's a few programs that use the same kind of orbiting controls as pronterface, once you figure out how it works it's quite easy to use. How it rotates depends where you initially click.

[zenmetsu]

There are a few... but there are usually reasons for the controlcontrol scheme in those cases. GoogleEarth is an example... and even then a lot of people find themselves using the control button to reorient to north. In the context of printrun i can see no reason ever rotate the Z axis away for vertical alignment with the view window.

[ntoff]

uh, I use it all the time to get a better look all around the model and look down from what would be the top of the model.

[zenmetsu]

The control method I suggest is the one that Blender and Slic3r use. There is no view of your model that you can achieve that is unique to either control method. The only difference will be rotation of the view. Rotation will not allow you to see anything differently. It is a simple math issue.

[ntoff]

oh I thought you were proposing to only be able to rotate around an object, with no option at all to be able to view it from the top.

carry on.

[zenmetsu]

Let me simplify the statement to make sure that there is no confusion.

When you are positioning the camera, you are picking a point on a sphere surrounding the current viewpoint. When you pan the camera, you move the viewpoint, thus the center of that sphere around in X/Y/Z space. When you zoom, you scale the size of the sphere. This can get you any view of the object that you desire, as the camera can be placed at any X/Y/Z coordinate of your choosing.

In the traditional method of control, such as slic3r and Blender, and just about every CAD package known to man, left/right motion will change the camera's longitude on the aforementioned sphere, while up/down motion changes the latitude. This will allow you to put the camera ANYWHERE on that sphere, and zoom/pan will let you change the center of the sphere and the viewing direction.

With the method used by printrun and GoogleEarth, the control is not very straightforward. If you are looking down on the object, from the sphere's north pole, then dragging left/right will do different things depending where you start your drag. If you start your click/drag on the left or right of the viewport, then the camera changes LATITUDE towards/away from the place that you clicked. If you start near the bottom or top of the view, left/right dragging will change the LONGITUDE as it would in the traditional control method.

Conversely, up/down motion when the click/drag is on the left and right of the viewport will change the LONGITUDE of the camera, up/down motion from the top and bottom of the image will change the LATITUDE. The controls are crossed, and not at all intuitive. In order to constrain motion to latitude or longitude, the user must drag directly towards/away from the center of the viewport or radially around the center of the viewport respectively. Any error in these motions will start to tilt the global Z-axis away from the viewport's vertical alignment, and then things go downhill quickly.

The only difference between the two methods is that in the printrun case, you can get added rotation of the camera's "up" vector. This does nothing to change the context of the view, you could achieve the same by physically rotating your computer screen; the actual view of the image, and the stuff you can see, does not change in the least.

[kliment]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the clarification, this makes a lot of sense.

Would you be willing to implement this kind of rotation? It sounds
like you have experience with it. I'm absolutely willing to accept a
pull request to do this, and also willing to do it myself, but that
would be "in the indefinite future".

On 03/15/2015 12:43 AM, Jason Westervelt wrote:

Let me simplify the statement to make sure that there is no
confusion.

When you are positioning the camera, you are picking a point on a
sphere surrounding the current viewpoint. When you pan the camera,
you move the viewpoint, thus the center of that sphere around in
X/Y/Z space. When you zoom, you scale the size of the sphere.
This can get you any view of the object that you desire, as the
camera can be placed at any X/Y/Z coordinate of your choosing.

In the traditional method of control, such as slic3r and Blender,
and just about every CAD package known to man, left/right motion
will change the camera's longitude on the aforementioned sphere,
while up/down motion changes the latitude. This will allow you to
put the camera ANYWHERE on that sphere, and zoom/pan will let you
change the center of the sphere and the viewing direction.

With the method used by printrun and GoogleEarth, the control is
not very straightforward. If you are looking down on the object,
from the sphere's north pole, then dragging left/right will do
different things depending where you start your drag. If you start
your click/drag on the left or right of the viewport, then the
camera changes LATITUDE towards/away from the place that you
clicked. If you start near the bottom or top of the view,
left/right dragging will change the LONGITUDE as it would in the
traditional control method.

Conversely, up/down motion when the click/drag is on the left and
right of the viewport will change the LONGITUDE of the camera,
up/down motion from the top and bottom of the image will change the
LATITUDE. The controls are crossed, and not at all intuitive. In
order to constrain motion to latitude or longitude, the user must
drag directly towards/away from the center of the viewport or
radially around the center of the viewport respectively. Any error
in these motions will start to tilt the global Z-axis away from the
viewport's vertical alignment, and then things go downhill
quickly.

The only difference between the two methods is that in the printrun
case, you can get added rotation of the camera's "up" vector. This
does nothing to change the context of the view, you could achieve
the same by physically rotating your computer screen; the actual
view of the image, and the stuff you can see, does not change in
the least.

--- Reply to this email directly or view it on GitHub:
#622 (comment)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVBVQHAAoJEC9FHFwEZzqVGMcP/A1ttKlSj1BVWh7SkiK7dBBf
YnfGAl0pLPaPBN4bIV2fuHNdB4MN/9uNE5SOhSur5LSFJWVLub3OT9TlTyq3Qy56
uMU9hsGclnxtoaMwfwheXnRJ5b2QlXMgQhJyplYu/irx/0OXEzshmD3XGFLbJUeJ
JMBasA23l2RqTe57taxVJWe435MRUvJi9rdYSgheLEhcHz0GeUx/A1oS3nL5AgFJ
bQx3f1ObMix5PSvfT3QD9BXjEBQepe3nb3HycIsE3TK/WUodeprRaPc/XRtvC+68
qmGp0qiNwYdkvvxMBG0zPWSqitSt5yAWb71iP2b3rKp8FjGCjJGXX3qKOdJ2U+tW
43N4mGrr0u/d3XYUQK/JqpYY9zp0YAC0dhASN5OlyJWcs/4M+wCBklPMwXWvNhg+
m5zcL96TyhDR8riz2XuJHzT67xZ+ZO6lDm+aK+ICYUvNh9+lxoLYOWPMsqJRAY9W
5vgtoIfX1IVEF1F8CRmee1+4jQUTDwB6nsHzyx2X38DYZoy1XgA1LWOIPTlHe4ok
rSKfokRg4LatOM3Z5ZQTj4xYHHir1DYICRmPHRp9CcVip9EirVTDMaodkE84oBmr
aEAJORMzWcZvi8m2uRfzlNCbuoj+LHcxRsrHDaW06TianJcP7soJGLGL7gS+DBe8
bZ6PUsJO64F9daGjKvWX
=OOoG
-----END PGP SIGNATURE-----

[pavlog]

You could use a pavlog@4b41b5d

[rockstorm101]

Hi guys, I know the issue is quite old, but what is the status of it?

• @afuzzyduck, I see it was assigned to you back then, did you work on it?
• @pavlog, I see you made some commits on a fork, would you be willing to submit a pull request?

Thanks

[kliment]

I applied the changes in the commit @pavlog linked to the 2.x branch. This resolves this issue.