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 <stud_in...@yahoo.de> 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 > 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
