So community, what are your thoughts? Robert.
Since we're taking a close look at the glue between OSG and Producer, I have another option, but it involves some heavy refactoring: In their current states, I see OSG as a graphics rendering library and Producer as a library for windowing and keyboard/mouse input. If that's wrong, please correct me because everything else I have to say is based on that. OSG is much more complicated than Producer (judging by the quantity of code in each), and to use OSG effectively it requires many more example programs. For this reason, I think the glue between OSG and Producer belongs where it is as part of the OSG's distribution. Without windowing, a scenegraph can't have decent example programs, but the reverse is not true. Producer can still have example programs, but they mainly need to focus on setting up windowing configurations and using input. This can all be accomplished without a scenegraph. If graphics are required, some simple OpenGL should suffice. As for what osgProducer should actually be, I recommend something much, much simpler than what it is right now. As its name suggests, it should be the glue between OSG and Producer. If the funamental rendering tool in OSG is SceneView, then I don't think osgProducer should go much further than spawning a SceneView per camera if it even goes that far. Alternatively, it could just provide hooks for connecting SceneViews created by the app. Making osgProducer a thin layer like this would also make it a better example of how to connect OSG to other windowing libraries. As for navigation and model manipulation (the meat of osgProducer::Viewer), I think all of this stuff belongs in a separate utility library that is still part of the OSG distro. If it was separate, it could be used in conjunction with any windowing library. osgProducer should provide nothing more than a way of passing Producers keyboard/mouse input data into this separate library. It seems like there might be work headed in this direction with osgViewer, but I don't know the plan for all these pieces. Right now I just see a lot of duplicate functionality everywhere. Ultimately, I'd like to see OSG just render, Producer just open windows and collect input from them, and osgProducer be a minimal layer. Scene navigation should be a library apart from windowing so that it can be used with any windowing system. Of course, all of this probably requires cooperation between OSG and Producer, and I don't know if we're going to see that. Anyway, that's my two cents.... -- Terry Welsh - mogumbo 'at' gmail.com www.reallyslick.com | www.mogumbo.com _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
