Amen!... ;) Joking aside, I agree but have a few comments/questions: > If we don't keep up to date and pushing the technology I fear that > game centric API's will drown out the needs of real high end graphics > developers
1. True! IMHO, OSG 3 should address *some* (not *all*) aspects of game API to grab a potion of the "market shares". Just developping OSG 3 with the question "Is that okay if I develop a game?" in mind should be enough though. 2. I'm definitely convinced that OSG 3 *must* stick to the newest technologies and OSG 2 to stick to OpenGL 2. I just wanted to emphasize on this :) 3. "OSG 3 soon = many more users" I was thinking that if we manage to get soon a "quite useable" OSG 3 (even if still in alpha state), then we would grab *many* OpenGL 3 users (or future users). If I project myself in such a user, I would say "Okay, I need to build something on top of OpenGL 3. So what are the existing toolkits? OSG 3 alpha? Hmmm... Worth trying, especially knowing the quality of OSG 1 and 2". And I would try using and developping OSG 3 instead of libXYZ. 4. Transition Transition from OSG 2 to OSG 3 will of course be harder than 1->2, as you say. Do you think this is worth trying to create some "bridges" between the two? I mean, we may: - Develop some portions of OSG 2 to "look like" what's in OSG 3 - Create some plugins/nodekits/etc. to have "OSG 3"-like behaviors in OSG 2 - etc. Your thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 11:01:58 +0100, Robert Osfield <[email protected]> a écrit: > HI Paul, > > My thoughts for OSG-3.x would be that it would be major rewrite of the > core scene graph and many of the additional components, and as such > would take a great deal of down time before anything near to level > functionality with OSG.2.x would be achieved. OSG-3.x is rather blue > sky thinking right now, so open for discussion about exactly what we > should attempt and how. I tend to think of OSG-3.x as a placeholder > for what a scene graph will need to be like to be relevant for the > next decade of graphics software. > > One thing is for sure is that the OSG-2.x series will have to run in a > parallel with this OSG-3.x development, and I see quite a few > additional features that we could add to the OSG-2.x series that offer > real value to OSG-2.x users, audio, physics, emphasis models, better > effects management, better volume rendering, etc. etc. As a basis for > graphics app development OSG-2.x is really strong. It's here now, it > works, it's one of the best scene graphs ever written, with plenty of > active users. It's be project suicide to not keep pushing forward > with the OSG-2.x series, and this will inevitably mean, a 2.10, 2.12. > I expect the focus to move from additional core scene graph features > to add ons like the osgAnimation/osgWidget/osgVolume additions. This > is what has already happened over the last year - there are few and > fewer new additions to the core because it's now pretty complete. > > What OSG-2.x can't do without major surgery is tackle wholesale > changes in the underlying graphics API. OSG-2.x is an OpenGL 2.x scene > graph through and through. The tight binding makes it great vehicle > for OpenGL 2.x app development, but this is also it's Achilles heel > when it comes to considering fundamentally different API's and > approaches. OpenGL 3.x, OpenGL ES, OpenCL are all disruptive > technologies, as are the new breed of 3D enabled embedded devices. We > could just stick with OpenGL 2.x style development, and try to hack > these other technologies into the mix, but we won't be able to expose > them in a elegant and efficient way that will keep us relevant for the > needs of graphics programmers two to ten years out from now. > > How we tackle this new technologies is not obvious, taking the bold > step of rewriting the scene graph is high risk strategy for the short > term to mid term, but not rewriting likely render the OpenSceneGraph > an annex of future graphics development. The OpenSceneGraph even > without a rewrite would probably still be usable in ten years time, > much like Performer was still quite widely used in it's grandfather > days, not because the technology was best around, but simply it takes > a lot of work to port to a new scene graph. With this in mind OSG-2.x > could well be useful in this time frame for a number of current users. > > We do have a bit of responsibility to the graphics industry to remain > relevant. The OSG community has collected many of the worlds top > scene graph users - together we've kept vis-sim, GIS and VR > technologies up to date and relevant with a unique set of experience > that knows about hight end features such as paging, threading and > multi-channel graphic, all this experience is largely missing from > graphics technologies developed by game centric companies/communities. > If we don't keep up to date and pushing the technology I fear that > game centric API's will drown out the needs of real high end graphics > developers, and we'd end up having to make do with sub OS's and API's > that don't address our needs - graphics for us will start taking steps > backwards. > > So I believe as communities go, we have what it takes to come up with > a new core scene graph technology that keeps pushing things forward, > we are well placed to do the job properly - but just saying this is > the easy part.... Maintaining and developing OSG-2.x is crucial to > present and new users over the next year or two. Taking advantage of > this existing community on a new OSG-3.x that will require major > rewrite of it and applications that use OSG-2.x presently is not > straight forward - how would we manage this transition? If we don't > get users transitioning then you end with a permanent fork in the > road, new users go the OSG-3.x route, existing user stick on the > OSG-2.x forever. > > We have our own history and that of other projects to learn from w.r.t > transistion. We moved from OSG-1.x to OSG-2.x that typically involved > a refactor of application code to use the viewer library, this > transition although not really that massive in terms of code changes, > has meant that even now we still have OSG-1.x users that haven't made > the transition. My expectation is the moving to an new OSG-3.x would > be a far greater API change, so the transition period would be far > longer. Elements like viewers would probably be able to map across > between OSG-2.x and OSG-3.x quite easily, but the scene graph and > NodeKits are likely to be different. > > Due to the transition costs for application development I would have > thought that new projects and new users will be the early adopters of > an OSG-3.x, this means a smaller pot of users and contributors > initially. I have occasionally pondered on whether the initial cut of > this new scene graph be a completely separate project, a NewSceneGraph > rather a branded OpenSceneGraph, and only once it's viable do we adopt > NewSceneGraph as a future OpenSceneGraph-x.x. > > On approach that might be viable would be to start developing > components like new maths library and other infrastructure elements > that we share between NewSceneGraph/OSG-3.x and OSG-2.x. Also > encouraging experiments in what a new scene graph might be like by > ripping apart OSG-2.x. The current OpenGL ES is an example of the > later. Once you have a couple of these components and experiments > that look they might have legs then we coalesce around them and a do > massive coding sprint to get a viable scene graph written. > > For now I'd suggest we keep developing and maintaining the OSG-2.x > series, treat it as the bed rock that gives us the security that we > can go off and try stuff off the beaten path, encourage blue sky > thinking and let this period explore what it would take to build a > future proofed OSG-3.x series. Once we've completed a few fact > finding missions w.r.t OpenGL 3.x/OpenCL/OpenGL ES etc that we might > have enough knowledge to have a bash at start OSG-3.0. At this point > I think we'd need a couple of concrete projects that really need this > new functionality, so it's scratching a real itch, rather doing stuff > because we think it might be necessary. > > Another important part will be working out not just what we want to > get to w.r.t future scene graphs, but also how to we manage the > transition? This is both a software issues as well as > community/documentation issue. > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
