osgGA. My approach is to bundle all touchpoints into one custom data
structure which is attached to an GUIEventAdapter.
The current approach simulates a moving mouse for the first touch-point,
so basic manipulators do work, sort of.
I created a MultiTouchTrackballManipulator-class, one touch-point does
rotate the view, two touch-points pan and zoom the view as known from
the iphone or other similar multi-touch-devices. A double-tap (similar
to a double-click) resets the manipulator to its home-position.
The multi-touch-trackball-implementation is not the best, see it as a
first starting point. (there's a demo-video at http://vimeo.com/15017377 )"
osg/Camera. The ::glName issue masked the fact that the "(..)" isn't handled
well in doxygen and leads to "(." in the generated files.
I'm also submitting a minor documentation fix to osgGA/DriveManipulator to get
it out of my patch queue ;)"
Changes:
- new mouse wheel zoom/movement/center functionality
- ability to fix vertical axis (important for CAD)
- possibility to specify values as absolute values or relative to model size
- kind of backward compatibility by flags passed to constructor
- and much more
- restructuring classes to use kind of hierarchy and standard way of event processing (handle methods). This way, there is much more code reusability and it is more easy to develop new kinds of manipulators.
Briefly, the new architecture keeps MatrixManipulator as base abstract class. StandardManipulator is the feature-rich standard manipulator with two main descendant classes: OrbitManipulator and FirstPersonManipulator. OrbitManipulator is base class for all trackball style manipulators, based on center, rotation and distance from center. FirstPersonManipulator is base for walk or fly style manipulators, using position and rotation for camera manipulation.
"
Changes by Robert: Replaced osg::Vec3 by osg::Vec3d, introduced DEFAULT_SETTINGS enum and usage. Added frame time member variables in prep for improving throw animation when vysync is off.
dependent on the complexity of the geometry. For complex scenes this
meant that it looked like you were "throwing" the display into molasses.
For simple geometry things get over-excited once thrown.
The fix is to factor in the frame rendering time to the caluclated
motion. I've implemented this for rotation and panning.
Now when things are thrown they maintain a rate very close to what was
happening when the mouse button was released."
This makes it possible to redefine the viewing direction of 'home' in the other manipulator - so home in a GIS app could be a plan view.
Since _homeUp is set to (0,0,1) and no current code changes it there shouldn't be any difference for current users."
TrackballManipulator. The purpose of this is to disable throwing when
you release the mouse button while moving the mouse. The default
settings is true (ie, allow throw). The two source files are attached.
"
A Collada camera will be added to the scenegraph as osg::CameraView. This allows the user to create a set of predefined camera viewpoints. I also added a new MatrixManipulator to osgGA called CameraViewSwitchManipulator and added usage of this to the osgviewer example. This manipulator allows switching between the predefined camera viewpoints. The current design limition I ran into is that a MatrixManipulator only manipulates the ViewMatrix, but for this particular manipulator I also want to update the projectionMatrix of the camera when switching to a new viewpoint. This is not implemented because I don't know what would be the best way to design it. Any ideas?
Furthermore Collada also supports orthographic camera's, where an osg::CameraView only supports a perspective camera. Would it be useful to create a CameraView with customizable optics for this?"
from: DEEP_COPY_STATESETS = 8,
to: DEEP_COPY_STATESETS = 1<<3,
showing clearly that this isn't the _value_ 8, but the _bit_ 8. this is an old pattern i see (and like to promulgate) to make code a bit more readable and maintainable.
"
hyper keys defined already, but these modifiers were missing in
GUIEventAdapter::ModKeyMask, and the EventQueue ingored them as well.
The attached diff/archive adds the missing parts for Super/Hyper
modifier key support.
I'm aware that this might not be supported on all systems/keyboards
out of the box, but decided to submit it anyway because:
- developers are aware of differences between input devices
(Some mice have scroll wheels, others don't. Some have five or
more buttons, some have only one. Some keyboards don't have
numpads, some have AltGr, some don't etc.)
- even if someone relies on Hyper/Super in distributed software,
this is easy to fix and doesn't create lock-in conditions
- while the names Hyper/Super may only be common on X11, they are
just symbol names and not OS-specific
- even though some systems might not offer these additional modifiers
by default, it's likely that all of them have at least 8 modifier
levels internally, so it should only be a matter of OS configuration
to make them work
- having super/hyper available is useful to offer a user ways
to define local key definitions that are safe from collisions with
predefined "official" key assignments"
osgViewer::StatsHandler and other handlers which allow you to change the
key(s) you would press to get them to do something. Pretty simple change
but useful in our context and possibly in others too."
multiple GraphicsWindows, this singleton is accessable via GUIEventEvent::getAccumulatedEventState().
Added use of this new singleton in GraphicsWindow* implementations.
Added WindowSizeHandler to osgkeyboard to help with debugging of event state
between windows.
