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"
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"
between the contexts, using the GraphicsContext::Traits sharedContext
and setting the same contextID.
When one of these shared contexts is closed, GraphicsContext::close
deletes all GLObjects for that contextID, regardless of the fact that
they are shared. This means that all of the other contexts sharing the
objects have to recompile them.
The attached tweak makes GraphicsContext::close a bit less brutal for
shared contexts. I have also changed a misleading diagnostic message.
"
to ensure the correct methods on constraints and callbaks are called for each Command. Also fixed the handling of
Constraints when applied to composite Draggers.
To reproduce the problem I attach a minimally modified osgviewer that just prints resize events. You can check what's printed in the console when you go fullscreen and windowed a few times.
The attached version of GraphicsWindowX11 fixes the problem for me, but I'm not sure this is the right approach. Maybe you can see a fix for the problem clearer.
The only place where the RESIZE event is generated in GraphicsWindowX11 is in CheckEvents and it then depends on the ConfigureNotify message. For some reason, either ConfigureNotify is not sent when going fullscreen or the traits already reflect the latest window size."
This patch add "FirePro" to the black list of renderers in State.cpp / initializeExtensionProcs
It allows to avoid an OpenGL error on Viewer initialization.
Tested on FirePro M7740 / Windows7 x64 Driver 8.85.7.2"
I used the latest version available via subversion.
My fix is using some API only available on 10.4 and later. I used some preprocessor statements to gain compatibility with 10.3 and earlier using (now) deprecated API.
Only tested on OS X Lion (10.7). Please do some testing as well since I'm fairly new to OpenSceneGraph. Someone should also test the code for 10.3 and earlier."
parameter in osg::Image. To support this Image::setData(..) now has a new optional rowLength parameter which
defaults to 0, which provides the original behaviour, Image::setRowLength(int) and int Image::getRowLength() are also provided.
With the introduction of RowLength support in osg::Image it is now possible to create a sub image where
the t size of the image are smaller than the row length, useful for when you have a large image on the CPU
and which to use a small portion of it on the GPU. However, when these sub images are created the data
within the image is no longer contiguous so data access can no longer assume that all the data is in
one block. The new method Image::isDataContiguous() enables the user to check whether the data is contiguous,
and if not one can either access the data row by row using Image::data(column,row,image) accessor, or use the
new Image::DataIterator for stepping through each block on memory assocatied with the image.
To support the possibility of non contiguous osg::Image usage of image objects has had to be updated to
check DataContiguous and handle the case or use access via the DataIerator or by row by row. To achieve
this a relatively large number of files has had to be modified, in particular the texture classes and
image plugins that doing writing.
the type of the virtual function ImageStream::getCurrentTime(), and with this fixing a compile and runtime error.
Changed time variables all to use doubles rather than float to be consist with the change to getCurrentTime().
the required header mathematics.h is not being included explicitly.
I have just included it, and verified that this also works with current
version 0.7, since the header is also available there."
"From David Glenn and Paul Martz. This change adds support for the NO_COLOR bit in the Vertex records' flags field. If NO_COLOR is set, and PACKED_COLOR is not set, the code will now properly default to using the face color at those vertices. See the osg-users thread "Open Flight characteristic not reflected in the current OSG" for more info."
and
"In consultation with David Glenn, it appears we needed to change a second file to correct how OpenFlight handles transparency when vertices have NO_COLOR. "
functionality when using Terrain::setVerticalScale. This was caused by
the following call sequence resulting in a lockup:
void Terrain::setVerticalScale(float scale)
CALLS dirtyRegisteredTiles();
void Terrain::dirtyRegisteredTiles(int dirtyMask)
SETS LOCK OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_mutex);
and CALLS (on every tile) setDirtyMask(dirtyMask);
void TerrainTile::setDirtyMask(int dirtyMask)
CALLS _terrain->updateTerrainTileOnNextFrame(this);
void Terrain::updateTerrainTileOnNextFrame(TerrainTile* terrainTile)
SETS LOCK OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_mutex);
******* PROBLEM - since lock has already been set! ********
The suggested fix submitted changes from using Mutex to ReentrantMutex.
"
You can now set a "intersection mask" and it will be used when looking for intersections.
So you can now easily "hide" some objects from manipulators."
I don’t have access to an OSX or Linux dev machine to make the changes required to the quick time plugin. This plugin will just default to returning 0."
