Hi All, Following on from my earlier topic of discussion on OSG packaging granularity and naming, and picking up on Andreas experiments with a Firefox plugin, and Cedric's further dev of the Blender Python scripts for exporting to .osg, and the other community activity on various plugins for others tools, I feel it's worth discussing how we go about coordinating and making it more accessible to end users.
Right now we have various projects that use the developed out in the community that fit the role of plugins to other tools, like modelling applications to provide OSG exporters, and plugins to browsers. Most of the these projects will be maintained out in the community, may have their own project websites, may have a single contributors, or several, and may be dropped, then picked up by others further down the line, or just sit annexed out on the wiki. This situation isn't too much work for me as It means I don't need to spend time coordinating or maintaining these works, but... often it looks like such projects come and go in terms of support for latest versions of OSG, or latest versions of the 3rd party applications, so I'd guess for many OSG users/developers that aren't straight forward to pick up and use. One possible solution might be to bring maintenance and distribution of these 3rd party plugins directly into the core OpenSceneGraph distribution in the form of a collection of src/3rdPartyPlugins projects. Some of these might be compilable C++ code such as a Firefox plugin, while others might be just a collection of scripts that just need to be installed in a place that a modeller such as Blender can pick up on. Custom Cmake installer might work well for taking these built libs/scripts into the appropriate places, as well as detecting dependencies and only building/installing what you have supported on your platform. Another other solution would be see if we can coordinate the management and software/build and distribution so that a similar pattern is used by all the various 3rd party plugin projects - to make it easier to OSG users to navigate to, use and contribute to them. If we were to got the direct integration route, we'll have to be careful about how we manage the integration of the sources, testing and on-going development in such a way as not to increase my own workload. Strategies to mitigate this workload would be to prepare the bodies of work so that they fit seamlessly into the OSG build system/directories structure, so it's just a straight forward task of my pulling in the software, then once they are ready then integrate into core OSG, but not before this. One needn't have a perfected software before integration, but it would at least need to fit comfortably and non-intrusively into the OSG build. A way of doing this prep work would be for us to use the branches section of the OSG svn repository in similar way to how Jeremy and Cedric have been prepping osgWidget and osgAnimation. If you do have software that you feel is a candidate for being part of 3rdPartyPlugins collection then please outline what it is, what files go into it, how it's built, how it might fit into a CMake build system, what its portability and dependencies are. Another area I do wonder about is whether we'd be able to share some components of software between some of the 3rdPartyPlugins as well, I know that there is Python script for Blender for exporting .osg files right now, and that Maya supports Python, so I wonder if a .osg file build class could be written in Python that is shared between both plugins, and with each just using its own glue code that uses this builder class to do the OSG output. Thoughts? Recommendations? Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
