Trackball zoom with orthographic view

[dov]

I created a camera with an orthographic camera, and connected it to a vsg::Trackball. This worked fine for interaction, except for the zoom functionality (e.g. by the mouse scroll wheel) which doesn't change the view at all. Looking at the implementation this is not very surprising, as zooming is moving the "eye" in the lookat transform, which doesn't change the perceived view of an orthographic camera. What does work is to change the left, right, top, bottom members of the orthographic projection. Should I just override the zoom functionality, and change the projection myself if I'm using an orthographic camera? Am I missing something?

[robertosfield]

Othrographic views really don't behave at all like perspective ones. The interactions are between movements and on screen size, zoomining are all very different. A manipulator that works well for 3d perspective won't work well for an orthographic one.

One can dream up ways of trying to make a perspective camera manipulator "kinda of" work a bit little but full of lots of oddities. I know I've tried to make it work myself and deluded myself that I could get it to work but users just get confused that things just don't work the same as a manipulator that works with 3d perspective, the stumbling block is humans are used to moving around perspective worlds and getting in close for a closer view which make no sense in an orthographic view.

My advice is don't try to make an orthographic view work with the same type of manipulator that works well for a perspective, it's a fundamentally different type of projection which works well for very specific types of tasks - map views, side views etc. but not fully interactive views like work in natural human ways.

If you want an interactive orthographic view then write a specific manipulator for it and for what makes sense for you users when they have an orthographic view.

[AnyOldName3]

I've used plenty of 3D editors where the camera manipulator for orthographic and perspective modes was identical (or at least presented as identical - I imagine the implementations would have been pretty different to make something that felt the same). In Blender, it's the 5 key on the number pad that toggles between perspective and orthographic, and it really does feel natural in both modes. I don't think Blender's camera manipulator is equivalent to any of the ones the VSG provides out of the box, so it's not necessarily true that any of them could be made to work well in orthographic mode, and I imagine that a lot of work has gone into Blender's camera manipulator, so it's unlikely to be easy to clone, but plenty of software claims to have a Blender-style camera manipulator, so it's not impossible for an application that prioritises that feature to do so.

[robertosfield]

The special case for where a orthographic works OK with 3D camera manipulation is when the eye point is always outwith the object(s) being viewed, if you remain far enough away from the object(s) then orthographic and perspective aren't so different to have they behave.

However, a general purpose camera manipulator that works well for full 3d worlds like the vsg::Trackball then it becomes a horrible experience trying to reconcile how users expect interaction to work and how it can work due to the constraints of the projection.

I know if we grafted in "orthographic" support for zooming into vsg::Trackball users would immediately start complaining that it doesn't work like the perspective behaviors without realizing that their expectations are untenable. Been there, done that, and came away with the understanding that all too easily will misunderstand what an orthographic projection is and what it's useful. Folks even ask stereo orthographic projections and don't understand why this can never work.

[AnyOldName3]

I agree. I just thought it was sensible to clarify that it's not that no camera manipulator can work well for both perspective and orthographic cameras, just that the styles of manipulator the VSG provides can't do it. If someone reading this thread were using the VSG to make a Blender-like 3D editor, they'd want to be pointed in the direction of prior art so they can implement what they want themselves rather than being told it was impossible.