Changes between Version 1 and Version 2 of Support/Porting/OsgProducerToOsgViewer

Show
Ignore:
Timestamp:
11/05/08 18:07:08 (6 years ago)
Author:
robert (IP: 217.155.192.154)
Comment:

Added various suggestions on mapping of osgProducer to osgViewer

Legend:

Unmodified
Added
Removed
Modified
  • Support/Porting/OsgProducerToOsgViewer

    v1 v2  
    1414 * Better native windowing support, include multi-threading support for Windows for the first time. 
    1515 
     16---- 
     17 
     18Porting 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. 
     19 
     20A few pointers to help you on your way: 
     21 
     22 * osgViewer supports Producer .cfg configuration files via the cfg plugin.  So you can do with call Viewer::readConfiguration(filename) or run: 
     23{{{ 
     24osgviewer cow.osg -c MyProducer.cfg 
     25}}} 
     26 
     27 * osgProducer::Viewer maps to osgViewer::Viewer 
     28 
     29 * Producer::Camera is kinda equivalent to an osg::Camera 
     30 
     31 * Producer::!CameraGroup is roughly equivalent to an osgViewer::View, althoug the later defers the threading to the Viewer/!CompositeViewer. 
     32 
     33 * Producer's !ThreadPerCamera threading model is equivalent to osgViewer's !CullDrawThreadPerContext. 
     34 
     35 * 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. 
     36 * Producer has a !KeyboardMouse class that manages all events, while osgViewer uses osgGA event support, and manages it on a per View basis.  
     37 
     38 * 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.[[BR]] 
     39{{{ 
     40osgViewer::View "is a" View. 
     41osgVewer::CompositeView "has a" list of View 
     42}}} 
     43 * 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. 
     44 
     45 * 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. 
     46 
     47 * Lots has been discussed about osgViewer over the past two years so the archives are good source to mine. 
     48 
     49 * The osgcamera, osgwindows, osgcompositeviewer and osgviewer examples are all good places to learn about setting up osgViewer. 
     50 
     51