Hi Jan, On 8/14/07, Jan Ciger <[EMAIL PROTECTED]> wrote: > You obviously do not have to maintain large application compatibility. > If somebody told me now that I have to remove OSG and change to another > scene graph in our application, I would shoot him on the spot. There is > too much time and resources invested in this. I am tracking the OSG > development because incremental changes are easier to make, but starting > over, no thanks.
I wonder if it would be possible for use to write some analysis tools to find out what OSG API's users are using, to try and get some profile for what parts will be the most problematic to migrate. Perhaps one can take an evolutional approach. > Regarding the OSG 2.x long-term viability in parallel with a separate > OSG 3 branch - I do not think that that is realistic. There simply > aren't resources to maintain it. This is a real issue, splitting user base can be a killer, with neither branch having sufficient critical mass to make a successful project. In general I'm trying to consolidate the user base onto classes/libraries that everybody users so that these classes get more testing and debugging, and avoid supporting disparate classes/libraries. For instance CMake is largely about consolidation. Making it easier for users to track the SVN and dev releases again is trying to bring more people on to the same version. Even osgViewer is fundamentally about trying to consolidate lots of different viewer (SceneView & osgProducer/Producer) implementations onto a single set of viewer classes - this one is of course a bit paradoxical as it required introducing a new library, so short term it's meant fracturing of the user base, but with the mid term aim of getting things unified. Evolving OSG 2.x to support GL3 should be possible, the question is how much will you compromise the use of GL3 in the process, and how will you complicate management of the project with multiple GL backends. There is another element to throw into the GL mix, and that is support for OpenGL ES in its various incarnations. > Good example is osgProducer - it was > removed only recently and it doesn't work already because it is out of > sync with Producer. This is not a complaint, just a fact - once > something is deprecated, it will slowly die. Nobody is going to put more > energy and effort in something like that. osgProducer is open source, and I'm still merging submissions when they come in, so if there are fixes required then please just send them in. Alternatively others could have write permission and handle this as well, personally this would work well for me as I'm just plain overloaded. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
