[QGIS-Developer] 3D View Interface Usability

[Martin Dobias]

Hi Jed

Thanks a lot for all the input - there is a lot of value in there. I like
the idea of having a modifier like Space to temporarily switch from the
current tool to navigation - right now we only have some basic tools like
identify or measure, but in the future we will likely have editing tools
where this will be very handy. Some of your suggestions mean that we would
also need to change the existing associations to various mouse keys - that
needs a bit more consideration. In the short term one of the big wins would
be to fix the camera rotation ("tumble") as you mentioned.

The good news is that a "fly" navigation mode is on its way - hopefully we
can get it merged for QGIS 3.18:
https://github.com/qgis/QGIS/pull/40893

Cheers
Martin


On Wed, Jan 6, 2021 at 2:31 AM Jed Frechette <jedfrechette at gmail.com> wrote:

> Hi Martin,
>
> I’m glad to hear my impressions weren’t too far off. I do think there
> are benefits to the GE style controls, especially for users that are
> already familiar with that software. Perhaps it makes sense to keep
> those controls as a separate navigation mode in addition to a new mode
> that is better suited to more complex tasks? Although I guess there’s
> the risk of muddying the interface by not picking one clear consistent
> set of controls and optimizing them.
>
> It’s interesting that you mention multiple viewports, as that would
> actually be fairly low on my wish list. This may be a personal
> preference, but I don’t use multiple views very often in applications
> where I have access to them. There are definitely certain tasks which
> are easier with multiple views so they are nice to have, but if I had
> to choose I’d much rather have a single viewport that is very
> efficient than multiple viewports that are less fluid. That’s what
> most of my suggestions below are geared toward; a single viewport
> where an experienced user can almost instantly navigate to the exact
> view they want, potentially edit/create some data, and within a few
> seconds be moving on to the next part of the scene.
>
> I’ll provide links to a couple examples and videos at the end of my
> post, but since there is so little consistency between 3D apps I want
> to provide some justification for what I think works rather than just
> say “Make it like my favorite program.”
>
> Regardless of the exact control scheme, I think the most important
> observation to make when designing a 3D interface is that for any type
> of interactive task the user is constantly switching between
> navigating around the scene and using tools to perform actions, e.g.
> identify, measure, digitize, etc.. Therefore, switching between those
> two modes of interaction needs to be as quick and easy as possible.
> Clicking toolbar icons to switch modes works but is probably the
> slowest way to do it. Some applications try to overload the mouse
> buttons so you can navigate and use tools at the same time, but I’ve
> never used a system like that which I thought worked well. I think
> it’s much better to make a clear distinction between navigate mode and
> tool mode and make the user responsible for switching between them via
> hotkey. That way your tools can make use of all 3 mouse buttons
> independently of your navigation control scheme, which can also
> utilize all 3 buttons.
>
> Although various applications have made different choices about the
> hotkey to use, to me the space bar is the obvious choice. The space
> bar is the most used key when typing and the navigation hotkey will be
> the most used key while navigating in 3D view so it should be the
> space bar too. The navigate hotkey could be used as a toggle, e.g.
> with a tool active tap the spacebar to switch to navigate mode then
> tap it again when you want to go back to the tool. Alternatively, the
> hotkey could be a modifier, e.g. hold down the spacebar to navigate
> then release it to return to the tool. Both can work well, but I
> prefer the modifier approach. A modifier removes the need for an
> indicator, e.g. different cursors, for which mode you’re currently in
> like you would need with a toggle. In addition a modifier can act as a
> hint to stay in dynamic mode if your viewport is set up to improve
> interactive performance by rendering different LODs based on whether
> the camera is currently static or dynamically moving.
>
> The specific navigation control scheme I would advocate for is:
>
> Dolly along camera z-axis (Space + RMB or Scroll wheel)
> ==========================================
> QGIS already behaves this way so no changes here. Usage of the scroll
> wheel is also consistent between the 2D and 3D views so that’s good.
>
> Track along camera x & y axes (Space + MMB, Space + Shift + RMB)
> ===================================
> The middle mouse button is used for the same movement in the 2D view
> so it would be good to stay consistent with that. The alternate
> mapping, Space + Shift+ RMB, is for laptop users that only have 2
> trackpad buttons. By tracking along the camera x & y axes instead of
> GE style tracking navigation is much more intuitive in a fully 3D
> world and you eliminate the orientation dependence I referred to in my
> first post.
>
> Tumble (Space + LMB)
> =================
> Tumbling in QGIS is already pretty good. The only change I would make
> is to pivot around the cursor’s current position rather than the
> center of the viewport. uclaros already suggested this in the tracker
> [1] and it would make precise navigation much easier.
>
> Roll around camera z-axis (Space + Ctrl + LMB)
> ===================================
> This is really useful when you just want to level the camera relative
> to the horizon.
>
> Box zoom (Space + Ctrl + RMB)
> ========================
> Good for zooming in to a specific region of the scene.
>
> Other navigation controls could certainly be added, e.g. restricting
> tumbling around additional axes, but I think the controls above cover
> the majority of needs.
>
> Two applications I think serve as good examples of what works well are
> Houdini and PolyWorks. They have both been around for decades and even
> though they serve very different types of users and are used in very
> different ways their control schemes are remarkably similar. I used
> their control schemes as the basis for the one I described above.
> Houdini has good documentation, including lot’s of videos [2], and has
> a free version so it is the easiest to observe in use. In contrast,
> PolyWorks might cost you a kidney to evaluate. I do, however, have a
> video I recorded a while ago showing it being used for some simple
> feature extraction [3]. This is the kind of task I would love to be
> able to do in QGIS. If I was designing a UI from the ground up for
> that specific type of feature extraction it would be a little
> different than what’s shown in the video, but it does give a good idea
> of the type of fluid, highly interactive workflow, I’d be aiming for.
>
> Hopefully, some of this is useful and provides some inspiration. I’m
> afraid I’m not familiar enough with Qt to implement any of it myself,
> but would love to be able to help in any other way that I can.
>
> Best wishes,
>
> [1] https://github.com/qgis/QGIS/issues/40530#issuecomment-742092974
> [2] https://www.sidefx.com/docs/houdini/basics/view.html
> [3] https://youtu.be/d5__-Vu6RkA?t=155
>
>
> --
> Jed Frechette
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210108/edd20b48/attachment.html>