Re: [osg-users] 3.0 or 2.10?
Hi Paul and JS, I was just wondering... not saying that we should try some ugly things like supporting deprecated features! :) The forward-compatible context seem an interesting thing though... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Fri, 06 Feb 2009 21:27:30 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, 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? Relying on deprecated features is bad practice, since by definition deprecated features may be removed at any time. So I think the goal is to move forward in order to eventually use no deprecated features in the core OSG and main nodekits. Luckily, there is now (in OpenGL 3) a way to create a forward-compatible context where the deprecated features are disabled. This makes testing that you are not relying on deprecated features easy (and OSG 2.x would of course totally fail on this). J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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
Re: [osg-users] 3.0 or 2.10?
Hi Sukender, 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? Relying on deprecated features is bad practice, since by definition deprecated features may be removed at any time. So I think the goal is to move forward in order to eventually use no deprecated features in the core OSG and main nodekits. Luckily, there is now (in OpenGL 3) a way to create a forward-compatible context where the deprecated features are disabled. This makes testing that you are not relying on deprecated features easy (and OSG 2.x would of course totally fail on this). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
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
Re: [osg-users] 3.0 or 2.10?
Will there be (or should there be) an OSG-3 branch in svn to allow development to commence? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
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
Re: [osg-users] 3.0 or 2.10?
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
Re: [osg-users] 3.0 or 2.10?
Hi all,as an example of a concrete project for shaping OSG 3.0 I suggest developing a ray tracing backend for meshes and point clouds (not only volume rendering), probably using OpenCL. Is there anyone else interested in this? Marco ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
HI Marco, On Thu, Feb 5, 2009 at 11:11 AM, Marco Fiocco marco.fio...@gmail.com wrote: as an example of a concrete project for shaping OSG 3.0 I suggest developing a ray tracing backend for meshes and point clouds (not only volume rendering), probably using OpenCL. Is there anyone else interested in this? This would be an interesting project for sure, it would exercise OpenCL usage, and wouldn't need to test out OpenGL 3.x/ES migration. One might even be able to spawn OpenCL support for OSG-2.x from such an initiative as well. One thing that might help would be to make sure the exploration phase consisted of several small tasks that were doable in a couple of weeks of development. The outcome would be small demo and the key part - knowledge about this new domain. Such projects could easily by managed as separate projects, or perhaps as a collection of experimental projects that act as a scratch pad. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Robert, One thing that might help would be to make sure the exploration phase consisted of several small tasks that were doable in a couple of weeks of development. The outcome would be small demo and the key part - knowledge about this new domain. Such projects could easily by managed as separate projects, or perhaps as a collection of experimental projects that act as a scratch pad. I know Jose Luis is busy right now with the website stability issues. But this begs for OSGForge to become fully open, i.e. have users be able to register new projects and have automatic access to an SVN, a wiki and a bug tracker for their project, all from a single central site which is OSG branded (as opposed to having OSG-related projects scattered on SourceForge, Google Code, authors' personal sites, and who knows how many other places). I seem to remember seeing that SourceForge's server software was open source and could be used to create similar sites. If this is true, or if something similar exists, perhaps this would be a better choice than Tracs for an OSGForge type of site? We could keep Tracs for the main OSG site though (but maybe upgrade it to the latest version so that users can register accounts instead of all using the osg account for wiki edits). I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an outsider get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
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 robert.osfi...@gmail.com 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
Re: [osg-users] 3.0 or 2.10?
Hi Nick, GForge was created by some of the original SF team and is really good - free to open source projects. http://gforge.org/gf/ Yeah, that's what I meant, not exactly the same software but it looks like it's exactly what we'd need to make an open OSGForge. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi JS, I confirm that: - SourceForge is open source - Can be installed on a custom server - Can contain Trac ( :) ) That would be a _*VERY*_ nice idea, even for OSG 2.x. I'm definitely in favor of that idea. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 15:14:02 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, One thing that might help would be to make sure the exploration phase consisted of several small tasks that were doable in a couple of weeks of development. The outcome would be small demo and the key part - knowledge about this new domain. Such projects could easily by managed as separate projects, or perhaps as a collection of experimental projects that act as a scratch pad. I know Jose Luis is busy right now with the website stability issues. But this begs for OSGForge to become fully open, i.e. have users be able to register new projects and have automatic access to an SVN, a wiki and a bug tracker for their project, all from a single central site which is OSG branded (as opposed to having OSG-related projects scattered on SourceForge, Google Code, authors' personal sites, and who knows how many other places). I seem to remember seeing that SourceForge's server software was open source and could be used to create similar sites. If this is true, or if something similar exists, perhaps this would be a better choice than Tracs for an OSGForge type of site? We could keep Tracs for the main OSG site though (but maybe upgrade it to the latest version so that users can register accounts instead of all using the osg account for wiki edits). I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an outsider get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi, http://gforge.org/gf/ Yeah, that's what I meant, not exactly the same software but it looks like it's exactly what we'd need to make an open OSGForge. Hmmm, I just noticed that GForge only supports CVS? Is that true? Perhaps there's an SVN plugin or something? Anyways, I'll investigate more when/if I get the go ahead from Jose Luis... No use putting time into this if it's not going to lead anywhere. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Robert, hi all, Do you think it could be worth trying a kind of sandbox server built on SourceForge? This would help us to check what could be the future issues with such a system. I don't have a true server (just my main machine with a bandwith that fits for personnal usage, and that is not online all the time), but I can do it... Moreover, we could run a CDash on it, so that we would not be limited to 50 warnings :) Comments? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 15:30:56 +0100, Sukender suky0...@free.fr a écrit: Hi JS, I confirm that: - SourceForge is open source - Can be installed on a custom server - Can contain Trac ( :) ) That would be a _*VERY*_ nice idea, even for OSG 2.x. I'm definitely in favor of that idea. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 15:14:02 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, One thing that might help would be to make sure the exploration phase consisted of several small tasks that were doable in a couple of weeks of development. The outcome would be small demo and the key part - knowledge about this new domain. Such projects could easily by managed as separate projects, or perhaps as a collection of experimental projects that act as a scratch pad. I know Jose Luis is busy right now with the website stability issues. But this begs for OSGForge to become fully open, i.e. have users be able to register new projects and have automatic access to an SVN, a wiki and a bug tracker for their project, all from a single central site which is OSG branded (as opposed to having OSG-related projects scattered on SourceForge, Google Code, authors' personal sites, and who knows how many other places). I seem to remember seeing that SourceForge's server software was open source and could be used to create similar sites. If this is true, or if something similar exists, perhaps this would be a better choice than Tracs for an OSGForge type of site? We could keep Tracs for the main OSG site though (but maybe upgrade it to the latest version so that users can register accounts instead of all using the osg account for wiki edits). I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an outsider get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. J-S ___ 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
Re: [osg-users] 3.0 or 2.10?
Hi JS, Jose is actually setting up a virtual server for us, this should allow us to add external users to have admin rights for helping maintain the server. Once the server is set up, and the dust has settled after 2.8.0 we can look at exact what services we want to provide from the sever. Robert. On Thu, Feb 5, 2009 at 2:14 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, One thing that might help would be to make sure the exploration phase consisted of several small tasks that were doable in a couple of weeks of development. The outcome would be small demo and the key part - knowledge about this new domain. Such projects could easily by managed as separate projects, or perhaps as a collection of experimental projects that act as a scratch pad. I know Jose Luis is busy right now with the website stability issues. But this begs for OSGForge to become fully open, i.e. have users be able to register new projects and have automatic access to an SVN, a wiki and a bug tracker for their project, all from a single central site which is OSG branded (as opposed to having OSG-related projects scattered on SourceForge, Google Code, authors' personal sites, and who knows how many other places). I seem to remember seeing that SourceForge's server software was open source and could be used to create similar sites. If this is true, or if something similar exists, perhaps this would be a better choice than Tracs for an OSGForge type of site? We could keep Tracs for the main OSG site though (but maybe upgrade it to the latest version so that users can register accounts instead of all using the osg account for wiki edits). I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an outsider get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.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
Re: [osg-users] 3.0 or 2.10?
Hi Sukender, As I just mentioned in a reply to JS, the new virtual server should give us a bit more flexibility w.r.t. setting up new services. I'll not dive in any more on this topic right now as the release has to be be primary focus. Robert. On Thu, Feb 5, 2009 at 2:38 PM, Sukender suky0...@free.fr wrote: Hi Robert, hi all, Do you think it could be worth trying a kind of sandbox server built on SourceForge? This would help us to check what could be the future issues with such a system. I don't have a true server (just my main machine with a bandwith that fits for personnal usage, and that is not online all the time), but I can do it... Moreover, we could run a CDash on it, so that we would not be limited to 50 warnings :) Comments? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 15:30:56 +0100, Sukender suky0...@free.fr a écrit: Hi JS, I confirm that: - SourceForge is open source - Can be installed on a custom server - Can contain Trac ( :) ) That would be a _*VERY*_ nice idea, even for OSG 2.x. I'm definitely in favor of that idea. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 15:14:02 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, One thing that might help would be to make sure the exploration phase consisted of several small tasks that were doable in a couple of weeks of development. The outcome would be small demo and the key part - knowledge about this new domain. Such projects could easily by managed as separate projects, or perhaps as a collection of experimental projects that act as a scratch pad. I know Jose Luis is busy right now with the website stability issues. But this begs for OSGForge to become fully open, i.e. have users be able to register new projects and have automatic access to an SVN, a wiki and a bug tracker for their project, all from a single central site which is OSG branded (as opposed to having OSG-related projects scattered on SourceForge, Google Code, authors' personal sites, and who knows how many other places). I seem to remember seeing that SourceForge's server software was open source and could be used to create similar sites. If this is true, or if something similar exists, perhaps this would be a better choice than Tracs for an OSGForge type of site? We could keep Tracs for the main OSG site though (but maybe upgrade it to the latest version so that users can register accounts instead of all using the osg account for wiki edits). I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an outsider get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. J-S ___ 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
Re: [osg-users] 3.0 or 2.10?
GForge was created by some of the original SF team and is really good - free to open source projects. http://gforge.org/gf/ Nick Jean-Sbastien Guay wrote: Hi Robert, One thing that might help would be to make sure the exploration phase consisted of several small tasks that were doable in a couple of weeks of development. The outcome would be small demo and the key part - knowledge about this new domain. Such projects could easily by managed as separate projects, or perhaps as a collection of experimental projects that act as a scratch pad. I know Jose Luis is busy right now with the website stability issues. But this begs for OSGForge to become fully open, i.e. have users be able to register new projects and have automatic access to an SVN, a wiki and a bug tracker for their project, all from a single central site which is OSG branded (as opposed to having OSG-related projects scattered on SourceForge, Google Code, authors' personal sites, and who knows how many other places). I seem to remember seeing that SourceForge's server software was open source and could be used to create similar sites. If this is true, or if something similar exists, perhaps this would be a better choice than Tracs for an OSGForge type of site? We could keep Tracs for the main OSG site though (but maybe upgrade it to the latest version so that users can register accounts instead of all using the osg account for wiki edits). I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an "outsider" get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi folks, I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an outsider get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. Guys, if there is a problem with a server, I could also offer one for particular projects, maybe also for main osg. The same one on which osgForum is currently running. It is true, that the main osg server has very bad connection times, at least here at my ISPs ;) I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. This was also my main point, which I tried to point out in another thread. The problem is, that there exists now a lot of nice nodekits, but nodekits, which are not happy to be included into main core, could not survive in the future, becasue they just don't get notified by users (yes, I am afraid of osgPPU too ;) ) Hence some kind of other nodekit system is required, so that the users still get enough information, what happens outside of the main core. Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5962#5962 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Okay. BTW, I don't find where to download SourceForge... I said it is open source... or *WAS* is? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 15:41:29 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, As I just mentioned in a reply to JS, the new virtual server should give us a bit more flexibility w.r.t. setting up new services. I'll not dive in any more on this topic right now as the release has to be be primary focus. Robert. On Thu, Feb 5, 2009 at 2:38 PM, Sukender suky0...@free.fr wrote: Hi Robert, hi all, Do you think it could be worth trying a kind of sandbox server built on SourceForge? This would help us to check what could be the future issues with such a system. I don't have a true server (just my main machine with a bandwith that fits for personnal usage, and that is not online all the time), but I can do it... Moreover, we could run a CDash on it, so that we would not be limited to 50 warnings :) Comments? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 15:30:56 +0100, Sukender suky0...@free.fr a écrit: Hi JS, I confirm that: - SourceForge is open source - Can be installed on a custom server - Can contain Trac ( :) ) That would be a _*VERY*_ nice idea, even for OSG 2.x. I'm definitely in favor of that idea. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 15:14:02 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, One thing that might help would be to make sure the exploration phase consisted of several small tasks that were doable in a couple of weeks of development. The outcome would be small demo and the key part - knowledge about this new domain. Such projects could easily by managed as separate projects, or perhaps as a collection of experimental projects that act as a scratch pad. I know Jose Luis is busy right now with the website stability issues. But this begs for OSGForge to become fully open, i.e. have users be able to register new projects and have automatic access to an SVN, a wiki and a bug tracker for their project, all from a single central site which is OSG branded (as opposed to having OSG-related projects scattered on SourceForge, Google Code, authors' personal sites, and who knows how many other places). I seem to remember seeing that SourceForge's server software was open source and could be used to create similar sites. If this is true, or if something similar exists, perhaps this would be a better choice than Tracs for an OSGForge type of site? We could keep Tracs for the main OSG site though (but maybe upgrade it to the latest version so that users can register accounts instead of all using the osg account for wiki edits). I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an outsider get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. J-S ___ 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
Re: [osg-users] 3.0 or 2.10?
Hi Sukender, Okay. BTW, I don't find where to download SourceForge... I said it is open source... or *WAS* is? In the GForge documentation it says that the public CVS repository for SourceForge had not been updated for more than a year, so they made a fork of it (which is GForge). It's possible that since that documentation was made, the public SourceForge CVS has just been removed and the software has been made proprietary... Though I would think that would be bad for a site that promotes open source development... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. I don't think this is the case. Robert has only referred to 3.0 when talking about introducing an OpenGL 3.0-only pipeline, i.e. not relying on the fixed pipeline at all. This will probably not happen in the next stable release after 2.8, thus there will surely be a 2.10, 2.12, etc. before we see 3.0. That's what I thought. Reaching the extent of the single-digit number space for the minor revision doesn't force a major revision increment. I wanted to make sure the community was on the same page regarding this. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Robert, Jose is actually setting up a virtual server for us, this should allow us to add external users to have admin rights for helping maintain the server. Once the server is set up, and the dust has settled after 2.8.0 we can look at exact what services we want to provide from the sever. That's good news. I also get your point about the 2.8 release being our focus, but on our side we don't have much to do now that we have automatic nightly builds and there are few submissions to test, so I don't think there's any harm in discussing it. I've offered my help in any case, so I'd like to plan ahead a bit to be ready when the time comes. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi, Okay. BTW, I don't find where to download SourceForge... I said it is open source... or *WAS* is? In the GForge documentation it says that the public CVS repository for SourceForge had not been updated for more than a year, so they made a fork of it (which is GForge). It's possible that since that documentation was made, the public SourceForge CVS has just been removed and the software has been made proprietary... Though I would think that would be bad for a site that promotes open source development... Yep: The GForge project is a continuation of the SourceForge project, which was close-sourced by VA Linux in 2001. Weird... They host open source software but their own software is closed source. I'll look for something else that's similar. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi, I own a server with 100Mb where i host some vserver, i could help to host a back up or any other services for osg related stuff. About the osg forge, i am not sure i would want it, i explain why: - more of them has no service for decentralized version control like mercurial / git - It constraint you to use specified tools, using source forge is a pain, it's always slow. when it's down, nothing is available. - It takes more energy to maintain it, than editing the current wiki page to reference projects. In theory the idea is cool but if people dont fill the current wiki why they will take energy to fill a forge ? And personnally if there is no support for git/mercurial i prefer to host the project where i can use those tools. 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... It's just an opinion Cheers, Cedric Art Tevs wrote: Hi folks, I've offered my (part-time) help in maintaining the OSG site to Jose Luis in the past, but he said since the server belonged to his school they would be reluctant to let an outsider get access to one of their servers. Perhaps when the server is moved to a virtual server, this issue would be less important since the server would be isolated from their own network, and I could lend a hand. Guys, if there is a problem with a server, I could also offer one for particular projects, maybe also for main osg. The same one on which osgForum is currently running. It is true, that the main osg server has very bad connection times, at least here at my ISPs ;) I think getting a distributed infrastructure and letting users register (both for accounts to edit the wiki and for OSGForge projects) is of vital importance for OSG's surrounding ecosystem, especially since we are talking more and more about nodekits being important for OSG 2.x and new API support/tests being important for OSG 3.x. This was also my main point, which I tried to point out in another thread. The problem is, that there exists now a lot of nice nodekits, but nodekits, which are not happy to be included into main core, could not survive in the future, becasue they just don't get notified by users (yes, I am afraid of osgPPU too ;) ) Hence some kind of other nodekit system is required, so that the users still get enough information, what happens outside of the main core. Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5962#5962 ___ 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
Re: [osg-users] 3.0 or 2.10?
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 -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
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
Re: [osg-users] 3.0 or 2.10?
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
Re: [osg-users] 3.0 or 2.10?
Thank you very much Cédric. However, I respect your point of view, and think that discussing a bit when having different ideas avoids many mistakes. We may finally find an intermediate or altered solution that fits most needs. I'm not really in favor of building a fully custom server, as it will need a lot of maintenance. But we may find an all-in-one solution that does 95% of our objectives. Maybe we could start looking at pages like: http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities http://www.dmoz.org/Computers/Software/Project_Management/Open_Source/ and such... About GForge: it supports SVN, but there are different versions with different limitations, depending on how much you want to pay! The free edition seems quite good (at first sight), as the open source edition (but the features are different). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 19:17:25 +0100, Cedric Pinson morni...@plopbyte.net a écrit: 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
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
Re: [osg-users] 3.0 or 2.10?
Hi Sukender, About GForge: it supports SVN, Yes, I saw that the document I was reading was quite out of date. It also supports a wiki, and 4.7 (which is in RC right now) has support for MySQL (I would prefer the server to run only one database engine, and I'm more familiar with MySQL than PostGreSQL...) but there are different versions with different limitations, depending on how much you want to pay! The free edition seems quite good (at first sight), as the open source edition (but the features are different). It seems to me the Open Source edition is sufficient, but I'll look in more detail later. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Adrian, Simply beacuse OSG 2 == OpenGL 2, and OSG 3 == OpenGL 3 (and such). That's certainly an awful shortcut, but globally, that was Robert said. OSG 2 will still live, and you may have your applications use OSG 2.26 (if such a version exists), even when OSG 3 is out. But you would not be able to take advantages of the newest technologies. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 20:59:15 +0100, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com a écrit: 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Great thing! I'm also more used with MySQL. Could be interesting... And yes, the open source seem sufficient to mee too. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 21:10:31 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, About GForge: it supports SVN, Yes, I saw that the document I was reading was quite out of date. It also supports a wiki, and 4.7 (which is in RC right now) has support for MySQL (I would prefer the server to run only one database engine, and I'm more familiar with MySQL than PostGreSQL...) but there are different versions with different limitations, depending on how much you want to pay! The free edition seems quite good (at first sight), as the open source edition (but the features are different). It seems to me the Open Source edition is sufficient, but I'll look in more detail later. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Adrian, 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/.. OpenGL ES and OpenGL 3.0 will drop the fixed pipeline. So OSG's core functionality (state attributes for each fixed pipeline state) will have to be replaced with a shader-based architecture. I guess most of the API could be the same (nodes, groups, geodes, parents, children, etc.) but the rendering back-end will have to be almost totally different. Anyways, it's still a ways off. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Ok, i see. The OpenGL 3 API will completly change. And for this, we will have to rewrite the OpenSceneGraph core. But the scene graph it selfs could (may) be the same or very similar. that would be greate. i thought the we will to rewrite the whole code, this would be much much much work, and even for debugging ... /thanks for the short answer 2009/2/5 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Adrian, 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/.. OpenGL ES and OpenGL 3.0 will drop the fixed pipeline. So OSG's core functionality (state attributes for each fixed pipeline state) will have to be replaced with a shader-based architecture. I guess most of the API could be the same (nodes, groups, geodes, parents, children, etc.) but the rendering back-end will have to be almost totally different. Anyways, it's still a ways off. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ 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
Re: [osg-users] 3.0 or 2.10?
Hi Adrian, Ok, i see. The OpenGL 3 API will completly change. And for this, we will have to rewrite the OpenSceneGraph core. Well, the API will change but the old API will be deprecated, not totally removed. The problem is that we don't know when the fixed pipeline will be removed, once it's deprecated. See http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/OpenGL/OpenGL3Notes which are some notes I took at the OpenGL BOF at Siggraph 2008, where the final specs for OpenGL 3.0 were announced. But the scene graph it selfs could (may) be the same or very similar. that would be greate. As I said, I think most of the API should be possible to keep... But anyways, we'll see. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
If you had a GKS- or PHIGS-based application, you might still be able to find some computers that support it, and your application might still run. Similarly, you have the option of freezing development on your OSG application and continuing to ship on OSG 2.8 for as long as there is OpenGL 2.x support on your target platforms. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: Thursday, February 05, 2009 12:59 PM To: OpenSceneGraph Users Subject: Re: [osg-users] 3.0 or 2.10? 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] 3.0 or 2.10?
Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. Unless the next stable release will break lots of backwards compatibility, I'd opt for calling it 2.10, then 2.12, etc. No need to change the major revision number unless we break backwards compatibility, and although there has been some discussion of that, nothing definite yet at this point as far as I know. Robert, comments? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
I am agree with this notation. Paul Martz wrote: Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. Unless the next stable release will break lots of backwards compatibility, I'd opt for calling it 2.10, then 2.12, etc. No need to change the major revision number unless we break backwards compatibility, and although there has been some discussion of that, nothing definite yet at this point as far as I know. Robert, comments? Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ 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
Re: [osg-users] 3.0 or 2.10?
Hi Paul, This needs to be confirmed, but I think Robert's mind is to go to 3.0 to allow the whole community to introduce things that break backwards compatibility, as you say. You even posted a thing on the thread Ideas for OSG v3.0, where Art Tevs told about reorganizing nodekits/plugins ( http://osgforum.tevs.eu/viewtopic.php?p=5006#5006 ). Of course if nothing special breaks the compatibility, or if there is not a huge pile of new features, I think going to 2.10 should be okay. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 00:11:04 +0100, Paul Martz pma...@skew-matrix.com a écrit: Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. Unless the next stable release will break lots of backwards compatibility, I'd opt for calling it 2.10, then 2.12, etc. No need to change the major revision number unless we break backwards compatibility, and although there has been some discussion of that, nothing definite yet at this point as far as I know. Robert, comments? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
HI, I agree on that the next version will still be 2.x. Only if we really go for a completly different API (with almost no backward compatibility), then we should go to 3.x The previous thread just collected some ideas about how to manage future releases of osg 3.x The idea was to go away from current nodekit thing and to separate the real main core part. Then with the help of something like NodeKitSuite one could add additional node kits. The main core would only have the real main core of a scene graph. All other suites will just provide functionality like ViewerSuite (whcih will include osgViewer), then InteractionSuite (here one could include osgWidget, osgGA, ...), then EffectSuite (here osgParticle, ...) and so on. Cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5901#5901 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Paul, Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. I don't think this is the case. Robert has only referred to 3.0 when talking about introducing an OpenGL 3.0-only pipeline, i.e. not relying on the fixed pipeline at all. This will probably not happen in the next stable release after 2.8, thus there will surely be a 2.10, 2.12, etc. before we see 3.0. At least that's how I understood it. The fact that Robert and Art have started discussions on the road to OSG 3.0 does not automatically imply that 3.0 will be the next stable version of OSG. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
