Hi Robert, OpenGL 3 specs says that nothing has been removed (just features that become deprecated). That mean OSG 2 is OpenGL 3 compatible (Well of course without new features)... isn't it?
Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Fri, 06 Feb 2009 10:22:20 +0100, Robert Osfield <robert.osfi...@gmail.com> a écrit: > 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) > <3dh...@gmail.com> 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 <morni...@plopbyte.net> >>> >>> 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 >>>> <jean-sebastien.g...@cm-labs.com> 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 >>>> osg-users@lists.openscenegraph.org >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>> >>> -- >>> +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net >>> http://www.plopbyte.net >>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >> -- >> ******************************************** >> Adrian Egli >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
