* MultiTouchTrackball: some code cleanup and support for normalized touch-points
* oscdevice: receiving and sending multi-touch-events via the Cursor2D-profile from TUIO
* added some documentation
The solution for to refactor the way that events are checked so I add a bool return type to checkEvents() method across osgViewer::GraphcisWindow, osgGA::Devive and osgViewer::Viewer/CompositeViewer classes
Added template readFile(..) function to make it more convinient to cast to a specific object type.
Added support for osgGA::Device to osgViewer.
Added sdl plugin to provides very basic joystick osgGA::Device integration.
10.6), which will forward all multi-touch events from a trackpad to the
corresponding osgGA-event-structures.
The support is switched off per default, but you can enable multi-touch
support via a new flag for GraphicsWindowCocoa::WindowData or directly
via the GraphicsWindowCocoa-class.
After switching multi-touch-support on, all mouse-events from the
trackpad get ignored, otherwise you'll have multiple events for the same
pointer which is very confusing (as the trackpad reports absolute
movement, and as a mouse relative movement).
I think this is not a problem, as multi-touch-input is a completely
different beast as a mouse, so you'll have to code your own
event-handlers anyway.
While coding this stuff, I asked myself if we should refactor
GUIEventAdapter/EventQueue and assign a specific event-type for
touch-input instead of using PUSH/DRAG/RELEASE. This will make it
clearer how to use the code, but will break the mouse-emulation for the
first touch-point and with that all existing manipulators. What do you
think? I am happy to code the proposed changes.
Additionally I created a small (and ugly) example osgmultitouch which
makes use of the osgGA::MultiTouchTrackballManipulator, shows all
touch-points on a HUD and demonstrates how to get the touchpoints from
an osgGA::GUIEventAdapter.
There's even a small example video here: http://vimeo.com/31611842"
OpenSceneGraph/src/osgGA/NodeTrackerManipulator.cpp:32:1: warning: base class ?class osg::Object? should be explicitly initialized in the copy constructor
OpenSceneGraph/src/osgGA/TerrainManipulator.cpp:31:1: warning: base class ?class osg::Object? should be explicitly initialized in the copy constructor
OpenSceneGraph/include/osgSim/ShapeAttribute:99:9: warning: base class ?class std::vector<osgSim::ShapeAttribute>? should be explicitly initialized in the copy constructor
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::gi?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::byte_before_the_zipfile?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::num_file?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::pos_in_central_dir?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::current_file_ok?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::central_pos?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::size_central_dir?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::offset_central_dir?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::cur_file_info?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::cur_file_info_internal?
OpenSceneGraph/src/osgPlugins/zip/unzip.cpp:3102:14: warning: missing initializer for member ?unz_s::pfile_in_zip_read?
OpenSceneGraph/src/osgViewer/CompositeViewer.cpp:30:1: warning: base class ?class osg::Object? should be explicitly initialized in the copy constructor
OpenSceneGraph/src/osgViewer/View.cpp:159:1: warning: base class ?class osg::Object? should be explicitly initialized in the copy constructor
OpenSceneGraph/src/osgViewer/Viewer.cpp:196:1: warning: base class ?class osg::Object? should be explicitly initialized in the copy constructor
OpenSceneGraph/src/osgViewer/Viewer.cpp:196:1: warning: base class ?class osgViewer::ViewerBase? should be explicitly initialized in the copy constructor
OpenSceneGraph/include/osgManipulator/Dragger:47:9: warning: base class ?class osg::Object? should be explicitly initialized in the copy constructor
disable pragmas that turn off specific warnings for MSVC.
Unfortunately it's presence is only checked in osg/Export header,
making other Export headers disable warnings no matter what, which is
kind of incoherent.
My fix adds #include <osg/Config> to every Export header. I've also
unified checking whether to disable warnings to current osg/Export
way:
#if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS).
Attachment contains all changed Export files in their original locations."
and another problem is:
example osgkeyboard is not work (keys not highlight) if user have 2 keyboard layout native and english and current user layout is native
I try to explain my changes
we need something that is identify key without modifier keys and layout -> this is UnmodifedKey
I think osg must have its own UnmodifiedKeys table. Code must be run same on different platforms. This can de guaranteed by UnmodifiedKeys table.
Mikhail Izmestev helped me. He implemented VirtualKey changes in GraphicsWindowX11"
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."
