|Version 2 (modified by robert, 5 years ago)|
osgProducer To osgViewer
- Developer Blog
- Mailing Lists
- Getting Started
- Platform Specifics
- User Guides
- Programming Guides
- Reference Guides
- Tips And Tricks
- Knowledge Base
- Trac Usage Examples
- TracGuide Documentation
- Software Patents
- Software Patents Europe
The new osgViewer library has been written a series of improvements over the original osgProducer library:
- Easier to integrate with a range of Window toolkits
- Remove the need for external dependency to make build the OpenSceneGraph easier
- Unify the classes used Cameras in a scene graph, and Cameras in a viewer and avoid clashes in concepts and naming conventions.
- Provide a set of viewer classes that provide functionality specific to different styles of applications:
osgViewer::Viewer - a viewer class which manages a single view on to a single scene, but this view can be composed of a single camera on a single window up to multiple cameras or multiple windows such as for multi-channel simulators. osgViewer::Viewer is equivilant to osgProducer::Viewer, but by design doesn't provide the same "everything and the kitchen sink" functionality that osgProducer::Viewer did.
osgViewer::CompositeViewer - a viewer class which manages one or more independent views on to one of more scenes, there is no equivalent in osgProducer, and creating such functionality was very awkward so this new class makes life much easier for developers that need this functionality.
- Higher level viewer functions that allow one to run the main frame loop using a single line of code. This allows a viewer to to be set up in just 3 lines of code.
- More coherent handling of events
- Support for distortion correction
- Better native windowing support, include multi-threading support for Windows for the first time.
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:
- osgViewer supports Producer .cfg configuration files via the cfg plugin. So you can do with call Viewer::readConfiguration(filename) or run:
osgviewer cow.osg -c MyProducer.cfg
- osgProducer::Viewer maps to osgViewer::Viewer
- Producer::Camera is kinda equivalent to an osg::Camera
- Producer::CameraGroup is roughly equivalent to an osgViewer::View, althoug the later defers the threading to the Viewer/CompositeViewer.
- Producer's ThreadPerCamera threading model is equivalent to osgViewer's CullDrawThreadPerContext.
- 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.
- Producer has a KeyboardMouse class that manages all events, while osgViewer uses osgGA event support, and manages it on a per View basis.
- 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
- 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.
- 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.
- Lots has been discussed about osgViewer over the past two years so the archives are good source to mine.
- The osgcamera, osgwindows, osgcompositeviewer and osgviewer examples are all good places to learn about setting up osgViewer.