OpenGL 2.x apps will run unmodified on OpenGL 3.0. However, the 3.1 spec will be released shortly, and I bet you'll see all 3.0-deprecated functionality removed in 3.1. An "OSG 3" will have to avoid use of all deprecated functionality.
Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender Sent: Friday, February 06, 2009 1:14 PM To: OpenSceneGraph Users Subject: Re: [osg-users] 3.0 or 2.10? 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 _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
