"attached you'll find some modifications to Producer, osgGA and
osgProducer to enable Mac OS X support for
+ scrollwheels,
+ mightymouse-srollballs
+ new tracking-pads with scroll feature
+ tablet-support (pressure, proximity and pointertype) (Wacom only tested)
I think there was a bug in the windows-implementation of scroll-wheel
support (wrong order of ScrollingMotion-enum, casting problem) which is
fixed now.
The scrollwheel-code is a bit klunky across platforms, some devices on
OS X can report an absolute delta in pixel-coordinates not only the
direction, so for now there is scrollingMotion (which describes the
direction) and scrolldeltax and scrolldeltay. I decided to leave the
scrollingmotion-stuff to not break old code relying on this."
osg::DisplaySettings class. OsgCameraGroup will now read the setting
from the DisplaySettings instead of hardcoding the value. I added the
following commandline option to be able to set the multisample value:
--samples <num>
One thing to note, OsgCameraGroup would previously check if the
computer is an SGI and set multisample to 4. I retained this check in
DisplaySettings to be backwards compatible."
keyboard and mouse events.
Added osgGA::EventQueue class to support a thread safe event queue and adaption
of keyboard and mouse events.
Removed osgProducer::EventAdapter as GUIEventAdapter replaces it.
Adapted osgProducer and examples to work with the new changes to osgGA.
FrameBufferObject.cpp there is also another fix: when initializing a FBO
attachment from a CameraNode attachment, the renderbuffer's format must be
set to the attachment's internal format, not to the image's pixel format.
Another problem is that attaching a renderbuffer to the FBO through
CameraNode is not simple (if not impossible) if you don't intend to specify
an Image object. Probably CameraNode could be enriched with an
"attach(buffer, width, height, format)" method. For example if you attach a
color buffer as a texture whose size is different than that of the
CameraNode's viewport you also need to attach a depth buffer of the same
size, because the depth buffer that is automatically attached by RenderStage
has the viewport's size. FBOs require that all attachment have the same
dimensions, so said setup will fail if you can't specify a custom depth
renderbuffer"
