Hi Rick, On Mon, Jun 16, 2008 at 8:26 PM, Rick Pingry <[EMAIL PROTECTED]> wrote: > I saw some porting notes on the Wiki, but they seemed to be mentioning the > REASONS for the change from Producer to Viewer, not necessarily step by step > porting directions as I would have hoped. There are a lot of paradigms > that I am used to in Producer that seem so very foreign in Viewer. I did > take a look at the osgkeyboardmouse example and that makes sense to me, so I > think I will be ok using osgViewer::Viewer and replace my > KeyboardMouseCallback with a osgGA::GUIEventHandler.
Your are on the right lines. osgViewer::View is roughly equivelant to osgProducer::OsgCameraGroup, where the View has a single master camera, and a series of of slave cameras. The different here is that View "has a" Camera, rather than CameraGroup which "is a" Camera, although not quite... The slaves in a View are entirely optional, as the master Camera can have a GraphicsContext/GraphicsWindow. In Producer your CameraGroup must have at least one slave Camera to do any rendering. The KeyboardMouseCallback in Producer is a single callback for capturing all events, while multiple GUIEventHandler's can be attached to the Viewer or scene graph, and the View can have its own CameraManipulator too. This means that osgViewer is quite a bit more fine grained w.r.t implementing keyboard handling. GraphicsContext is kinda equivelant to RenderSurface, except that its a pure virtual base class, and the implementations are subclassed from this (i.e. osgViewer::GraphicsWindowWin32/PixelBufferWin32 etc), and to create graphics context you'll typically use osg::GraphicsContext::createGraphicsContext(Traits*), rather than construct a RenderSurface like you've been used to. A singleton osg::GraphicsContext::WindowSystemInterface is what provides the glue between the implementations of GraphicsContext and your request to create windows and pbuffers. I expect once you get your head around the new viewer library it'll become quite natural, integrating well with the core OSG and handling a far wider range of usage models than previously possible with SceneView or osgProducer/Viewer. Good luck with the port, Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
