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 _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
