HI Adrian, Writing the core scene graph is something that is likely to be required to handle multiple backends, so rather than just OpenGL 2.0, we'd need OpenGL 3.0 and OpenGL-ES and a mixture of OpenGL/OpenCL. Currently we only map to OpenGL + extensions, we can't handle wholesale changes to the API being used at the backend.
Another issue is that current scene graph API is built around fixed function pipeline, with a few tweaks to be able to handle shader, but it's still fundamentally a design for a fixed function pipeline. With a pure OpenGL 3.0 or OpenGL ES 2.0 implementation there is no fixed function pipeline at all, so the way we manage state w.r.t. uniforms/vertex attributes + shader composition will have to change. Now it may be possible to evolve the current API gradually to meet the above challenges, but... we have to entertain the possibility that at some point we have to make a large leap to be able to meet these challenges. It might be that we can evolve some parts of the API but not others. In an ideal world we'd be able make the leap to the new way of doing things without too much re-factoring of end users application code, but would such an ideal compromise that underlying scene graph in the process. Right now nothing is set in stone. The OSG.2.x has lots of life left in it yet. The idea behind an API breaking OSG-3.x series is just that, an idea, not a single line of code has been written on it, no white papers have been written proposing what a new scene graph structure would be like. All I can say for sure is that there are some big challenges ahead if we wish to make the most of new API's and new hardware technologies. Robert. On Thu, Feb 5, 2009 at 7:59 PM, Adrian Egli OpenSceneGraph (3D) <[email protected]> wrote: > Hi all, > > i don't understand why we should rewrite the whole openscenegraph core? Is > the good old openGL and openscenegraph that faraway from openGL CL/openGL > ES/.. How long does it take to port the whole greate functionality from osg2 > to osg3? And how would it be possible to port the application form osg2 to > osg3 or should we restart our development once we get osg3 because the > osg2's API so different > from osg3? I don't understand all of the problem. is the openGL close to > death and we have to restart the greate osg2 lib. rewrite the core means, > what will happen with osg2 applications, new features will no longer be > added to the API (in long term view) and than the osg based application have > to die, and the new application has to become new written. or what will the > graphic industry do in near and long term future. i am not as close as some > of the community are in the graphic community, i am closer to computer > vision :-( :-) > > I undestand that we may have to overthink some part of the core to support > new ideas in the graphic world. RealTimeRayTracer, ... ,... ,.. ,.. But > openscenegraph is one of the best graphic engine currently in the world of > computer graphics render engine. > > /sorry that i don't really understand the question and the problem we will > get with osg2 > > adrian > > > 2009/2/5 Cedric Pinson <[email protected]> >> >> Anyway i will help to host if it helps >> >> Cheers, >> Cedric >> >> Sukender wrote: >>> >>> Hi JS and Cédric, >>> >>> I'm a bit more in favor of what JS says. I agree that when the Forge is >>> down it's really annoying, but centralizing all OSG related projects seem >>> worth using a kind of forge (or something else). We really should avoid them >>> dying by helping people maintaining them. >>> >>> Sukender >>> PVLE - Lightweight cross-platform game engine - >>> http://pvle.sourceforge.net/ >>> >>> >>> Le Thu, 05 Feb 2009 17:49:57 +0100, Jean-Sébastien Guay >>> <[email protected]> a écrit: >>> >>> >>>> >>>> Hi Cedric, >>>> >>>> >>>>> >>>>> In theory the idea is cool but if people dont fill the current wiki why >>>>> they will take energy to fill a forge ? >>>>> >>>> >>>> I think it requires no more energy than hosting your project on your own >>>> site, or a site like SourceForge or Google Code. The difference is that >>>> it would be centralized, with an easy way to add maintainers, to >>>> generate interest in projects, to search, etc. >>>> >>>> A list of nodekits on the wiki, where links become broken and there is >>>> no way of knowing if a project is actually any good, doesn't help at >>>> all. >>>> >>>> >>>>> >>>>> And personnally if there is no support >>>>> for git/mercurial i prefer to host the project where i can use those >>>>> tools. >>>>> >>>> >>>> You could always host your own version control repository, and use the >>>> forge's version control as a mirror. Plus I think some of the software >>>> supports Mercurial at least (mozdev does, why not others?) >>>> >>>> >>>>> >>>>> I think the main problem is to reference project, not to host them >>>>> Maybe >>>>> we just need to improve the reference of project on osg trac or a >>>>> better >>>>> categories... >>>>> >>>> >>>> No, I think the main problem is generating interest and ensuring a >>>> project stays alive. A dumb project list does not help there. >>>> >>>> As it is now, a project is one person's pet and if that person stops >>>> maintaining it, it dies. Handing over project ownership does not happen >>>> when a project is one person's pet. Unless the project is on SourceForge >>>> or Google Code, but then we have the problem of having lots of projects >>>> on different systems using different tools to maintain them. >>>> >>>> I think we need a better balance between consolidation and distribution. >>>> Being too decentralized is not good either. >>>> >>>> Anyways, we'll see. >>>> >>>> J-S >>>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> >> -- >> +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[email protected] >> http://www.plopbyte.net >> >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > -- > ******************************************** > Adrian Egli > > _______________________________________________ > 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
