|Version 1 (modified by martin, 9 years ago)|
- Developer Blog
- Mailing Lists
- Job Offers
- Job Requests
- Users Groups
- Past Events
- Language Wrappers
- Node Kits
- Windowing Toolkits
- Derived Software
- Data Resources
- Community Activity
- OpenGL/OSG advocacy
- Wiki Login Details
The itch - why osgViewer is needed
Over the last few years users have been pushing the existing viewer library osgProducer (based on Producer) beyond its initial design remit. Recurring areas of difficulty has been support for Windowing toolkits beyond Producer, and handling of applications with multiple independent views of the scene, particularly complicated when these applications use database paging, and/or open/close windows successively with their application.
Another difficulty users have with OpenSceneGraph is complexity of building, with the number of external dependencies being a barrier to entry. Also when learning the API having multiple API's to learn adds to steepness of the learning curve - if we can provide a native viewer library all using the same matrix, memory management, and coding style and design then hopefully it'll become easier to learn. Support for multiple windowing toolkits and complex viewer configuration will also lessen the learning curve more user will be able to use off the shelf components rather than having to "off" road it dealing with complex back-end implementation details that complex viewers throw up.
The goal of osgViewer
The concept behind osgViewer is to address the need for a set of viewer classes that allow seamless support for a wide range of windowing toolkits (i.e. QT, Win32, MFC, WxWindows?, Fox, FLTK, SDL, AGL/CGL etc.) and provide a convinent mechanism for managing both simple single window, single camera view applications, through to complex multi-window, multi-view, multi-threaded applications.
osgViewer is almost feature complete, with Windows, X11 and OSX Carbon support already integrated, along with two new viewer classes Viewer and CompositeViewer?. New threading models have also been introduced that provide much better use of modern dual core CPU. For this first time multi-threaded, multiple window usage is now fully supported under Windows, bringing it in line with other platforms in terms of scalability.
All OpenSceneGraph examples have now been ported across to use osgViewer, for the most part changes were trivial to move from osgProducer::Viewer to osgViewer::Viewer.
The 2.0 release of the OpenSceneGraph will see osgViewer as the standard viewer library that comes with the OpenSceneGraph, with the original osgProducer library moved out into its own separate distribution. osgProducer will be maintained alongside major releases of the OpenSceneGraph. With this change OpenSceneGraph will no longer require Producer as a dependency, so only OpenThreads? will remain as the major external dependency.
Major Classes associated with osgViewer functionality:
Core osg library:
- osg::Camera (previously called osg::CameraNode? - part of 1.0 onwards, a Node that contains a scene that it renders. Has projection and view matrix, viewport, and an optional osg::GraphicsContext? that it renders to, as well as options for configuring the render to texture back-end.
- osg::OperationsThread/GraphicsThread? - part of 1.0 onwards, a thread class for running a list of GraphicsOperation? in a seperate thread
- osg::GraphicsContext? -part of 1.0 onwards, base class for abstracting away from the implementation details of creating and using graphics contexts - be it a pbuffer or a conventional graphics window. The GraphicsContext? "has a" optional GraphicsThread?. This is currently used by osg::CameraNode? to manage pbuffer RTT implementations
- osg::View - class for managing all the cameras that work in unison to render a single coordinated "view" of a scene. View has a master osg::Camera that controls the view and projection matrices for the scene, and a list of slave osg::Cameras, with the slaves' view and projection matrices updated each frame to be relative to the master's view and projection matrices. Both the master and slave Cameras can be used for rendering at the same time.
- osgGA::EventQueue - part of 1.0 onwards, could be used almost as is, just with namespace change to osgViewer. * osgGA::GUIEventAdapter - part of 1.0 onwards, not ideal due to its heritage, and being only tied to mouse and keyboard events, but good enough to used a place holder for an eventual general purpose/extensible osgViewer::Event class.
- osgGA::GUiEventHandler - part of 1.0 onwards, a bit like GUIEventHandler - cludgy and in need of replacement for the final osgViewer library, but good enough to use while prototyping osgViewer.
- osgGA::EventVisitor - part of 1.0 onwards, will need a bit of work on it, but in usable shape for an osgViewer::EventVisitor?.
- osgViewer::View - subclass from osg::View, adds higher level viewer functionality.
- osgViewer::Scene - helper class for managing scene graph data.
- osgViewer::GraphicsWindow - a base class for implementing OpenGL graphics windows, differentiated for osg::GraphicsContext? that is derived from by adding event handling support.
- osgViewer::Viewer - functionally replacement for osgProducer::Viewer. osgViewer::Viewer "is a" osgViewer::View, so gains all its multiple window/multiple camera support from the View, and conceptually only manage a single View on to a single Scene.
- osgViewer::CompositeViewer - provides support for viewer that requires multiple views on to one one more Scene's at once, through use of a list of osgViewer::View's. Such complex viewer functionality hasn't been easy to implement in the OpenSceneGraph before, but now has been made very straight forward.
There are now three concrete implementations of the osgViewer::GraphicsWindow? which support all the major platforms that the OpenSceneGraph is released with.
- osgViewer::GraphicsWindowWin32 - windows support
- osgViewer::GraphicsWindowX11 - X11 support for all Unix platforms (including OSX).
- osgViewer::GraphicsWindowCarbon - Carbon support for OSX.
- osgViewer::GraphicsWindowEmbedded - A adapter version of GraphicsWindow? that does a non op for most functions, but allows the Viewer and CompositeViewer? classes to work embedded in an external windows, such as one created by QT, FLTK etc.
== Future work:
Support for pbuffers under Win32, X11 and Carbon.
Supoort for ascii configuration files.
For discussion on this topic please use the osg-users mailing list.
Robert Osfield, Last updated 6th June 2007.