HI Gianluca, On Wed, Nov 5, 2008 at 3:22 PM, Gianluca Natale <[EMAIL PROTECTED]> wrote: > Is there any tutorial that explains how to do that without any pain?
I'm afraid that isn't a tutorial for porting across. We have a porting page but it isn't filled out enough to help too much: http://www.openscenegraph.org/projects/osg/wiki/Support/Porting Porting across may be very quick if you just using osgProducer::Viewer, but if you use Producer extensively then the port is likely to be a bit more difficult. A few pointers to help you on your way (I'll be adding this to the above pages): 1) osgViewer supports Producer .cfg configuration files via the cfg plugin. So you can do: osgviewer cow.osg -c MyProducer.cfg You can also invoke the configuration programatically. Via Viewer::readConfiguration(filename); 2) osgProducer::Viewer maps to osgViewer::Viewer 3) Producer::Camera is kinda equivilant to an osg::Camera 4) Producer::CameraGroup is roughly equivilant to an osgViewer::View, althoug the later defers the threading to the Viewer/CompositeViewer. 5) Producer's ThreadPerCamera threading model is equivlant to osgViewer's CullDrawThreadPerContext. 6) With osgProducer::Viewer/Producer::CameraGroup the master the camera "is a" viewer, but also "has a" list of one or more slave cameras. You must have at least one slave Camera in Producer. With osgViewer::View, the view "has a" master Camera , and an optional list on slave Cameras. 7) Producer has a KeyboardMouse class that manages all events, while osgViewer uses osgGA event support, and manages it on a per View basis. 8) osgViewer handles complex viewer arrangements conveniently via the CompositeViewer class, there is no direct equivalent in Producer - the best you could do is have a CameraGroup with unsync'd slaves and have the app manage each slave camera manually, and if the cameras had different scenes then the shared DatabasePager would things screw up for paged databases. CompositeViewer solves this mess with an API that uses the same ViewerBase and View classes as the standard osgViewer::Viewer. osgViewer::View "is a" View. osgVewer::CompositeView "has a" list of View 9) osgProducer::Viewer contained many event handling features by default, but made it awkward to disable these. osgViewer::Viewer doesn't have any default event handlers, save for a TrackballManipulator that is only added as a fallback if you don't specify your own when you call run(). Rather than have lots of defaults the event handling features are added manually. The examples, including osgviewer illustrate how this is done. 10) The osgViewer library adds DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext threading models that allow the draw thread to run in a parallel with the update, event and cull traversals, and the by default the threading model is chosen to suit your hardware - so if you have dual core you'll end up with DrawThreadPerContext. The gotcha with this is that you need to set the DataVariance to DYNAMIC on any Drawable and StateSet's that contain data that vary. 11) Lots has been discussed about osgViewer over the past two years so the archives are good source to mine. 12) The osgcamera, osgwindows, osgcompositeviewer and osgviewer examples are all good places to learn about setting up osgViewer. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
