I'm stuck in a 'chicken or the egg' problem and I would definitely use a Producer::RenderSurface_QT. Any roadmap for this not-to-distant version of Producer in mind ?
regards,
Mathieu
2006/9/26, Don Burns <[EMAIL PROTECTED]>:
Hi Folks,
Not too long ago Robert wrote:
osgProducer::Viewer itself could be made more flexible, but there are real limits to its design and doesn't do the OSG or Producer real justice, so I'm inclined to not to continue too hard flogging this old horse.
I'm not sure about osgProducer::Viewer not doing OSG real justice, but I will vouch for it not doing Producer justice. I've felt for a long time that it didn't use Producer the way it should have and has kept much of the interesting information about how to write a viewer for osg tucked away in obscure constructs that required a lot of code reading to figure out.
Further, I think there is too much overlap in many of the constructs with Producer/OSG that cause confusion. I don't really want to bring up a camera war here, but truth is, the functionality of Producer::Camera, osgUtil::SceneView and osg::CameraNode overlap in ways that make understanding their use difficult. (and now we have osg::View which adds a bit more to the mix).
My original intent with Producer was that it _be_ the camera library and I feel strongly about camera's residing outside the scene graph - but that is a discussion for another day. Today, I'm making everyone aware of how I thought a simple viewer should be written using Producer. I've written Producer::OsgSceneHandler (local to the example) which contains the functionality of osgUtil::SceneView. Producer::OsgSceneHandler, however, does not attempt to be a camera, nor contain cameras, nor take any of the functionality belonging to a camera away from the Producer::Camera. It also does not contain a cameraNode. It simply manages (handles) the scene.
A well integrated Producer/OSG would pass the Producer::Camera information to Visitors, so that they could apply the attributes appropriately. This would simplify a great deal of information that is currently copied to SceneView, RenderStage, RenderGraph, CullSettings, CameraNodes and the Visitors as well.
So, for your evaluation, please do a cvs update of Producer and try Examples/OsgViewer out. A couple of things to notice that are exposed for example in this program.
Render Surfaces
Note the first executable line of main():
Producer::ref_ptr<Producer::RenderSurface> renderSurface =
new Producer::RenderSurface;
In not-to-distant versions of Producer, you will be able to replace this line with (for example):
Producer::ref_ptr<Producer::RenderSurface_QT> renderSurface =
new Producer::RenderSurface_QT;
Voila', OSG integration with QT. Replace QT with your favorite of FLTK, MFC, etc.
Input Devices:
This example uses a Producer::KeyboardMouse as it has always been used. It's usage is now exposed for your control, rather than buried in an osgGA::EventAdapter. It is also optional. Your viewer based on a windowing/GUI package of your choice (QT for example), will get Events from that windowing system. Producer does not impose upon its users the need to manage Producer events and will stay completely out of the way of the windowing package or your choice.
Future versions of Producer will probably separate the Mouse and the Keyboard and will also have support for Joysticks, Head Trackers, Tablets, etc. all seen as a generic InputDevice class.
Manipulators:
This example uses a Producer::Trackball, also exposed for your education and evaluation, not buried in a osgGA::Manipulator class, or dependent on osgGA::EventAdaptor. It's input interface takes two floats and an unsigned int, representing the mouse's X,Y position and button state. It outputs a matrix. A future version will also take an InputDevice as input, so that it can be used with Joysticks, etc.
Future versions of Producer will add more manipulators, probably starting with adapting osg's Fly,Drive,Terrain,UFO manipulators. Manipulators will be dynamically loadable rather than statically coded.
Camera View Control:
The CameraView control is exposed in this example as well, rather than being buried in an osg::Manipulator class's handle() method. This provides the programmer with direct access to moving the camera through the virtual world by providing a Matrix or Lookat parameters.
Finally, this example is a simple, single camera example. I think this represents the vast majority of OSG users' needs. This does not impose a multithreaded viewer where it is not needed and should make it simple to add cameras for applications that need more than one camera, but don't need parallel execution.
A second example, which does provide parallelism will be forthcoming, but for now, please enjoy this one example.
Note that this example removes the stereo functionality from osgUtil::SceneView. It is my feeling that this functionality belongs in the Camera, but I've procrastinated on implementing
it in the camera because of its presence in osgUtil::SceneView. However, Producer::Camera's will also have stereo functionalty soon and its control will be through the Producer::Camera API.
Cheers,
-don
PS. BTW, it even has a Visual Studio project file. Eric, want to do the honors for the Mac?
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
Mathieu
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
