Robert Osfield ha scritto:
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.
Completely agree, integration with other sw like
browser,scripting,modelling is important and
one of the weakest point of OSG compared with other projects ( ie OGRE )
is the lack of coordinantion in add-ons
and the sparceness of source.
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.
Are you thinking of a sort of 'battery included' OSG, with dependency
and addons?
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.
The two could not be mutual exclusive: a project could first be
mantained externally but adapted to the common layout and then,
eventually integrated.
I think providing tools and structure to help people to work on the same
code would help, expcially during internediate state of development.
As far as the repositories share a common layout and there is a simple
script to grab the needed components and build, the user could not even
perceive there are different
repos behind.
I have looked at distributed CVS like Bazaar or Mercurial and it seems
to me they are more flexible in allowing different management patterns.
Regarding CMake build, each project could have his own CMakefile, but
could share with other all the macros nedeeded (custom Find etc..)
For example the FindOSG and the macros used to detect build options,
could be shared among all the projects using OSG.
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.
Currently I' m working on our VirtualRome osg4web Firefox and IE Plugin.
We can for sure benefit from having more structured firefox
example/support .
I' m trying to clean up our CMake based build and, I' ll try to see if
it can build also Andrea plugin
I' m currently using my version of FindOSG.
I'm also using CMake for build basic dependencies
(tiff,jpeg,png,zip,curl) under windows as I still use VS7.
I understand that under Linux the dependencies are found in the system
but under windows this is not an option.
could this be of some interest?
Another project I wold like to be "adopted" is OSGSwig pythin wrapper
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.
Very interesting, for VirtualRome project I had to use templates in php
for building osg files on the fly on a web-server.
Having something stable in python would had helped a lot
Thanks
Luigi
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
