Hi Paul, On Fri, Feb 6, 2009 at 8:37 PM, Paul Martz <pma...@skew-matrix.com> wrote: > Will there be (or should there be) an "OSG-3" branch in svn to allow > development to commence?
I think this is premature. I'd rather see us highlight areas that need research and then have a set of mini projects that go out scoping these areas. Once we've scoped out a bit more, perhaps written a few "white papers" outlining what approach would be an ideal modern scene graph then we could start discussing what exact should be in this next gen scene graph and how we might work towards this, either evolving the current code base or setting up a new sister project for an OSG-3 branch. If we do go the OSG-3 branch route then we need to look at how to maintain the two projects, for instance helping evolve the OSG-2 branch in such a way as in closes the gap to OSG-3 to make the leap easier so that appliication developers currently working with OSG-2 won't be stuck. Another approach all together would be to say just start a new next gen scene graph project and not care what so ever about backwards compatibility with the existing code base, and look for new users and contributors to coalesce around it. Such an approach would see a lot of re-inventing the wheel, stuff like loaders and viewers that constitute a great deal of effort and knowledge would be lost. Personally I think a lot of the existing OSG code base can be carried across to a next gen scene graph. There is also the community that is one of our key assets is crucial - if you split the community between existing and next gen scene graph efforts both would suffer. The easier porting from OSG-2.x to OSG-3.x is the quicker you'd be able to migrate the community across to the new API, a challenge will be marrying the needs of a next gen scene graph and ease of porting. For starters I'd like to have a fair idea of what an ideal next gen scene graph would look like so we can all subscribe to our final destination, so we can all a tune to the same north barring. Once we get this common baring then when we start heading out along the uncharted path with each daily engineering decisions we make from here on out guided by this barring so that each day we get near to this goal. Lots of arm waving... of course... but now it's time to start thinking about what we feel should go into this next gen scene graph - what problems (i.e. what types of software/hardware) should it address, then how might one address this disparate set of problems, what existing examples can we learn from. Perhaps we need to instigate a poll of the wider graphics community of what they want from scene graphs in the next ten years, what software they see being needed to be developed, what hardware/OS's they expect to be of importance. Once polled one could look for themes that can be distilled into key deliverables that we can sign up to. There is also scratching the itch - we just have to find things that just are so compelling that we can't help ourselves - we just have to tackle it, because it's fun to do and because in the end we can see it being useful. The OSG just started with a little itch... then kinda got out of hand over the next decade.. :-) I guess this last paragraph is suggesting to me that perhaps over analysing this stuff is not what will get it done, it's going to be a handful of engineers that just get to it and create the beginnings of something beautiful. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
