RFC: Changed mouse controls #121
Conversation
* Double click for select point and recenter * Right click becomes pan. In standard mode it pans in the x-y plane. In trackball mode it pans in the image plane. Might be nice for touchscreen interface? * Seperate codepath for mouse wheel (same UI effect though)
|
Hi Andy, thanks for looking at this. The middle mouse button problem is definitely something that needs improving. After playing with this for ten minutes, I'm afraid it drives me completely nuts though! Impressions:
So for now, I'm still not convinced that panning this way is going to be better. On the multi touch front, perhaps that system should just be a bit different from the mouse-based one. vrui has some interesting multi-touch like interaction: https://www.youtube.com/watch?v=cyoJKbzqpZA |
Yes I agree that it definitely needs improving significantly!
I'd add that the double click was more precise in my experimentation - the cursor was less likely to move when I double left-click as opposed to middle click. Downside: finger fatigue.
Probably a good point, but I'd wager there are more mice with a scroll wheel than a good middle button. Touchpads, apple magic mice, etc all support two finger scroll. Does that work currently?
A second set of crosshairs is an absolute must!
It is a bit strange, but I think there is a call for allowing continuous movement. I did receive a lot of informal feedback from people wanting to do something like that for a long time. I would like to implement continuous movement with WASD keyboard controls and see how that works out. It would be like pushing a wheelbarrow (except you can strafe). Perhaps a third camera mode, "free look" mode, which behaves like a computer game would be intuitive for some users. We would have to absorb the mouse focus (perhaps with double-click to enter and exit free-look?). The crosshairs could be used to select points. The zoom level currently sets the distance scale, so it would have to also set the velocity of movement - otherwise I don't see how we'll get scale-invariant exploration in free look mode. On the technical side, I'd need to implement an event loop or at least a timer-event whenever a movement key is held. |
Two finger scroll worked fine on ubuntu when I tried it - it was mapped to scroll events. Not sure about other OSs, I don't have them sitting around for ease of testing. I'd definitely welcome a well implemented first-person mode (#15), just not enough to do it myself yet ;-) |
This allows us to put the early bailout logic in one place, which is a nice cleanup.
* System to limit total number of warnings with a given format expression and log level. * Use this for warnings generated when parsing polygons
Normally the GUI will inherit an instance lock from the command line tool, but this makes debugging quite hard; add a -server option to allow the GUI to be started manually.
Ensure that the framebuffer resource management is watertight. glDeleteFramebuffers() was being called on uninitalized memory - looks like something left over from debugging.
No functionality should change here, just a code cleanup - renaming, adding comments, etc.
This gives less of the nasty mixture of Qt wrapped vs raw OpenGL calls.
Do not pass an argument to glCheckFramebufferStatus(), because this is just asking for bugs - it always applies to the currently bound framebuffer. Remove associated bug!
OMSDLFKJG this was hard to find, thank goodness for apitrace. The bug It leads to some VBOs (particularly that used by PointArray) being randomly deleted before we're done with them, intermittently leading to segfaults inside the driver. Driver- and OS-dependent madness! Another effect of this bug was that vertex array handles continually leaked. This is probably the cause of some lower powered cards eventually locking up under resource starvation.
|
@andyferris something odd has happened to this branch. You probably need to rebase against origin/master to make my commits go away. |
|
Right... git and I aren't really friends at the moment. I did try to rebase the first commit on top of your changes, but I must have done something backwards. |
I'd like some feedback on some possible UI modifications I'm playing with in displaz. Some things I'm considering when designing this include the fact that its difficult to press the middle mouse button on modern mice, a UI which is consistent with possible future touch controls, and an analogue/continuous method for translating the centre of view.
Specific modifications are:
trackball mode it pans in the camera/image plane. Might be nice for
touchscreen interface with two finger pan, one finger rotate, and pinch-to-zoom?
For panning, the choices I've made specifically ignore the point cloud and the location on the screen the user initiates the drag from. We still need controls (maybe keyboard bindings) for z displacements.
Also, possibly standard WASD controls would obviate the need for pan-by-mouse mode and be more familiar to gamers. I think we'd want Q/Z or something for going up/down.