Hi all It's really great to see how the community or the numbers of users grows each day, and it's also great to know that the openscenegraph is used many times in academic, commercial ,.. tools. And we all know that the work load for robert gets each day bigger and we have to discuss the near future of the project. Of course there are different nodekits, hundert of features and finally do we really want just a scenegraph? The problem is where starts a scene graph and where ends the scene graph. My opinion is that we should follow the current concept to include as many nodekits as possible in the osg scene graph, and the concept of the osgLIB isn't as bas as it sounds. Of course we should think about splitting the review and responsabiliy of the whole code into parts, and we should think to decide who can support robert, i don't like to start splitting the whole project into "physical"/ hard parts. once i like to get OpenSceneGraph then i like to get the core (scenegraph), close core (threading & osgViewer (was once producer, we all remember) ) , ... then basic features like osgShadow, osgText, osgGA , ... ,... , ... and so on. You understand me, what is a nodekit what not. I am sure out there are some guys saying, only osg.lib is a scene graph, so we need only osg.lib the others lib we should better call nodekit. i think we should NOT decide to re-create the current concept, we should better to re-write some code (translate to shaders, ... , ... ) and we should think how we can support robert, and we should think how we can avoid a worst case "community crash". I don't really like to mention that, but since i got an accident, i get how fast the world can change, and how fast we can get off of work. So what happends, when robert has the unhappy case and gets froced for a longer break, who would be able to do the SO IMPORTANT review of the sub-mitted code. We should start as soon as possible to discuss how we can insure that the OpenSceneGraph project would continue in all possible cases the life play.
In my opinion we have to think about a core group of people who have the understanding of maintaining the project and can support robert without losing the open mind/concept of robert and this would be the biggest challange in the near future. The OpenSceneGraph's coding standard, quality , ... is really good and the only raison is that robert has decidie to check in or not, and had thought often a long time about the concept. i would split the osg core, event not in osg 10.0, i would let grow the lib as much as it make sense, but i would work with more people involved in mainting the code. reviews, and so on. /adrian On 24/01/2009, Mario Valle <[email protected]> wrote: > For my job currently I'm using the statistics package R and writing > things using LaTeX. > Both have a very structured method to manage and document addons. > Look at http://stat.ethz.ch/CRAN/ (very good) and at: > http://www.ctan.org/tex-archive/ (less clear). > These could be an inspiration for the future NodeKits structure and > management, I think. > Just my 0.05 CHF > mario > > Robert Osfield wrote: >> Hi Art, >> >> I understand the issues you talk about. External NodeKit can be >> neglected by potential users because they aren't visible enough, and >> there are also issue of compatibility and maintenance of these >> external NodeKits. It's not just an issue of NodeKits, it applies to >> plugins or applications that live around the core OSG project. I >> don't think the solution need be a pure software management issue, >> it's strongly related to management of website resources. >> >> We've had various different initiatives over the years to try and >> address this issue - the wiki is one avenue, another was the formation >> of osgforge.org and hosting of several ancilery projects like VPB, >> Present3D, osgLua and osgPython. My hope was osgforge would become a >> incubator for projects that could make it into the core, or become >> part of the close nit family of NodeKits. Such initiatives haven't >> thrived as perhaps they could have, partly because the various >> contributors haven't pushed things forward, and partly that >> wiki/website management takes time and dedicated manpower. I'm open to >> suggestions on how better to streamline and manage this side of >> things. The bottom line is a key missing ingredient has been >> engineers who put the time into keep websites up to date. >> >> As for re-factoring handling of NodeKits in 3.0, I'm open to this. It >> might even make the most sense to build 3.0 incrementally, starting >> with a re-factored core scene graph and then bit by bit re-introduce >> the NodeKits as they get ported across. Quite a few of the older >> NodeKits would be best rewritten using shaders, or to be incorporated >> into other NodeKits. Having some scheme where 3rd party NodeKits can >> be pulled in by end users may well help facilitate a move over to a >> 3.0. >> >> One thing I have thought about in the past of have an "Open Graphics >> Suite" that is collection of related libraries/applications, with a >> scene graph one element of the suite, then you'd have extra libraries, >> exporters, applications all populate this suite. The suite would >> contain optional components that could be selected from to provide the >> tools required for different apps. Modern linux packaging >> repositories provide this model and the scale of 10's of thousands of >> compatible libraries and applications. >> >> >> Robert. >> >> On Fri, Jan 23, 2009 at 5:34 PM, Art Tevs <[email protected]> wrote: >> >>> Hi folks, >>> >>> The community becames bigger and bigger and there are more and more >>> projects/nodekits which offers additional features to osg. And therefor I >>> think OSG 3.0 is the best time to refactor the whole nodekit maintaining >>> structure. Hence here are couple of ideas, how to do so. >>> >>> >>> In my opinion, nodeKits/plugins which were not lucky to be included into >>> osg main core wouldn't survive, because the people would just forget >>> about them. Making everyday advertisment, that this and this nodekit does >>> provide the functionality you are looking for is also not the solution. >>> New users are not used to read wiki pages or search in google, they do >>> not even read ReadMes which are essential for proper work. They just >>> download and compile the osg and want to have either an example showing >>> how to do it or try to reinvent the wheel everytime again and again. >>> Nodekits which are then not included in the main core (or better say: >>> main download) are not noticed by users. >>> >>> >>> What I propose is to rearrange/refactor/cleanup osg main core to basic >>> functionality of a scene graph, so to remove everything which has nothing >>> to do with a scene graph on its own. Then provide something like official >>> category of nodekits, where all previuosuly filtered nodekits would be >>> moved. Robert will became main maintainer, who is responsible for the >>> whole code and for bringing the category maintainers together. A category >>> maintainer is responsible for his category and maintainers of each >>> individaul projects which are covered by his category. The individual >>> maintainer is responsible only for its own project. This would create >>> some kind of hierarchy of nodekits and its maintainers, which would make >>> the further development of OpenSceneGraph more flexible, I think. >>> >>> >>> All the maintainers of the nodekits should get their own svn permissions >>> to being able to commit to the svn, however only to their own projects. >>> Maintainers of a category would get responsible to bring all the projects >>> into one NodeKit-Pack/Category-Pack and make sure, that the pack is >>> compileable and compatible with current osg version. This will free up >>> Robert, who is spending maybe his whole time to the project, and will >>> also make the decision about new features more democratic :) >>> >>> >>> What I imagine is that when you download osg you get just the basic >>> functionality and nothing more. Then you decide to have gui >>> functionality, hence you download the GUI-NodeKit and you get the osgGA, >>> osgWidget, osgText and other nodekits which are still marked as official >>> OSG GUI nodekits. All that nodekits/nodekit categories provided on the >>> main webpage are officialy validated. Projects which are like to became >>> officialy validated, would have to be investigated by the main maintainer >>> (Robert) and by the submaintainer, responsible for the nodekit group >>> where the new project like to be included in. >>> >>> >>> Release of osg 3.0 will be a good point to do so, because the backward >>> compaitibility has no to be fully supported as it was done during the 2.x >>> development. And my personal opinion is, that this kind of project >>> development will make it more flexible and will let evaluate the >>> OpenSceneGraph faster, which more or less became a game engine rather >>> than a scene graph ;) >>> >>> >>> Best regards, >>> art >>> >>> ------------------ >>> Read this topic online here: >>> http://osgforum.tevs.eu/viewtopic.php?p=5006#5006 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > -- > Ing. Mario Valle > Data Analysis Group | > http://www.cscs.ch/~mvalle > Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 > v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- ******************************************** Adrian Egli _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
