Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
Some open-source projects do this via a foundation, but they also usually have corporate, academic, or government angels who are major contributors. So Mozilla has Google, Apache has IBM and Sun, and so- on. OpenGL, though not open source, has the Khronos Group, which seems to be everyone-but-Microsoft. Hmmm...would Khronos perhaps provide some funding? Or is there history there I don't know? Randolph On Dec 9, 2008, at 12:00 PM, Robert Osfield wrote: Hi Robert, On Tue, Dec 9, 2008 at 5:31 PM, Sukender [EMAIL PROTECTED] wrote: That may require another thread, but I also have a question that may sound crazy at first: why not hiring people so that OSG's deployment, testing, packaging, and more are centralized, systematic and well tested? And why not calling for donations to have enough money for that? Maybe this would bring OSG to be more industrialized (in the good way of the term ;) )?... Another off topic It would nice if we could raise the money for a team, but I don't think one could do it out of donations. We are talking about need to raise $USD 50k to 100k a year to bring on dedicated staff, I can't image us pulling in this type of donation each year. For fixed such salary costs you need a regular income to pay it, which points to a subscriptions model. Support contracts would fit the requirement of regular income. I do have a few clients on professional support, but the number is high enough to employ other engineers, as it only a fraction of my yearly income - the bulk of my income is for bespoke development projects, but these don't directly fund general project admin but they effectively enable me volunteering me time on the unpaid aspect to project work. Such funding doesn't stretch to employing others. One could look to converting more commercial OSG users to pay for support, but we'd have to have a ten fold increase in the number of support contracts to pay for one engineer fulltime. Scaling funding is hard. What is more practical is leveraging a bit of time from a number of different osg users. This is effectively what we do right now, although not always as effectively and consistently as is desirable in terms of getting binaries and dependencies out regularly. Any further discussion about funding reallys needs to pulled into a separate thread. Robert. ___ 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] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
Hi, I think that the CMake build-system is a very good one. Maybe a simple solution would be: - integrate a 3rd-party-plugins-directory - those plugins are turned off by default in the CMake-build, like the wrappers at the moment At wxWidgets they do that, too. The scintilla-wxWidgets component, for instance, is not built by default, but is distributed with wx, so one can build it easily. A 3rd party-programmer who wants to write a plugin should have a step-by-step guide on how to integrate the plugin with osg and cmake. Then he or she sends it to Robert, he reviews that, and adds it to 3rd party directory or not. What I would need, for instance, to do this with the small firefox-plugin, is an example-based guide on how to integrate this into osg. I am not a professional programmer, I have my regular job I earn money with, so I don´t have the time to read the whole cmake-manual. What I would also like to have is the 3rd-party-libs in the osg-core distribution. Like wxWidgets has ... This would, for instance, have made it easy for me to test if linking statically against the c-runtime would work when all 3rd party bins did that. But I don´t have time to assemble all the 3rd party libs (which is especially hard on windows, would be much easier on linux) to go and try this. So if this was easy enough, I sure would like to integrate my plugin into the 3rd-party folder. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
Hi Andreas, If you are up for it would could trial building your plugin as a src/3rdPartyPlugin/firefox project. If you don't have the cmake skills right now then either just try copying an existing plugin - such as the gecko one, or perhaps another member of the community can help volunteer to help create the Cmake files. If things looks like they'd fit in comfortable with the present build then we then move on the trialing integration with the svn/trunk. Robert. On Wed, Dec 10, 2008 at 4:28 PM, Andreas Goebel [EMAIL PROTECTED] wrote: Hi, I think that the CMake build-system is a very good one. Maybe a simple solution would be: - integrate a 3rd-party-plugins-directory - those plugins are turned off by default in the CMake-build, like the wrappers at the moment At wxWidgets they do that, too. The scintilla-wxWidgets component, for instance, is not built by default, but is distributed with wx, so one can build it easily. A 3rd party-programmer who wants to write a plugin should have a step-by-step guide on how to integrate the plugin with osg and cmake. Then he or she sends it to Robert, he reviews that, and adds it to 3rd party directory or not. What I would need, for instance, to do this with the small firefox-plugin, is an example-based guide on how to integrate this into osg. I am not a professional programmer, I have my regular job I earn money with, so I don´t have the time to read the whole cmake-manual. What I would also like to have is the 3rd-party-libs in the osg-core distribution. Like wxWidgets has ... This would, for instance, have made it easy for me to test if linking statically against the c-runtime would work when all 3rd party bins did that. But I don´t have time to assemble all the 3rd party libs (which is especially hard on windows, would be much easier on linux) to go and try this. So if this was easy enough, I sure would like to integrate my plugin into the 3rd-party folder. Regards, Andreas ___ 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] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
2008/12/9 Robert Osfield [EMAIL PROTECTED]: Hi All, Snip. Thoughts? Recommendations? Robert. ___ osg-users mailing list Well I'm not too keen on having loads of third part stuff in the default core. Building osg is already painfully slow, the only machines I have access to are over 3 years old... If you can download them separately and unpack them in there when you want them it's not to bad, but I don't think that fits in with the way SVN works does it? -- The truth is out there. Usually in header files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
HI Simon, On Tue, Dec 9, 2008 at 3:30 PM, Simon Hammett [EMAIL PROTECTED] wrote: Well I'm not too keen on having loads of third part stuff in the default core. Building osg is already painfully slow, the only machines I have access to are over 3 years old... The CMake build system only compiles that components you have dependencies for, and you select building of components as well. If we do add extra 3rd party plugins it shouldn't make any different to your build times, unless you require these plugins. Speeding up the OSG build is separate topic, so I won't dive in to suggestions on this thread. You're welcome to start a new thread on this topic to so what others might recommend to helping cut your compile times. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
2008/12/9 Robert Osfield [EMAIL PROTECTED]: HI Simon, On Tue, Dec 9, 2008 at 3:30 PM, Simon Hammett [EMAIL PROTECTED] wrote: Well I'm not too keen on having loads of third part stuff in the default core. Building osg is already painfully slow, the only machines I have access to are over 3 years old... The CMake build system only compiles that components you have dependencies for, and you select building of components as well. If we do add extra 3rd party plugins it shouldn't make any different to your build times, unless you require these plugins. Speeding up the OSG build is separate topic, so I won't dive in to suggestions on this thread. You're welcome to start a new thread on this topic to so what others might recommend to helping cut your compile times. Robert. True enough, but I am only building the core of osg and the default plugins. None of the other components build as I don't configure them and I'm unlikely to ever use them. I'm not going to be using any of osgParticle/osgTerrain/osgWidget in the foreseeable future either (worse luck) If there are another bunch of core libs, eg. osgWidget I have to remember to disable them in cmake or they build as well. It's not too bad at the moment, but if we wind up with lots of 3rd party libs the cmake interface is a pain. But it also seems silly to have a core library which doesn't build by default, or you wonder why it's there. Unfortunately we 'doze uses have to build the debug and release builds so it all adds up. Perhaps the cmake could be split in 2, so there's one for the core (and a couple of examples) and another for the extras? That would work with visual studio projects but I don't know if that would work with linux build systems... That would be handy as people new to osg could get up and running faster and you've still got all the goodies to play with later. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
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
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
HI Simon, This isn't the thread to be discussing existing build issues, could you please start a new thread for this. Robert. On Tue, Dec 9, 2008 at 5:17 PM, Simon Hammett [EMAIL PROTECTED] wrote: 2008/12/9 Robert Osfield [EMAIL PROTECTED]: HI Simon, On Tue, Dec 9, 2008 at 3:30 PM, Simon Hammett [EMAIL PROTECTED] wrote: Well I'm not too keen on having loads of third part stuff in the default core. Building osg is already painfully slow, the only machines I have access to are over 3 years old... The CMake build system only compiles that components you have dependencies for, and you select building of components as well. If we do add extra 3rd party plugins it shouldn't make any different to your build times, unless you require these plugins. Speeding up the OSG build is separate topic, so I won't dive in to suggestions on this thread. You're welcome to start a new thread on this topic to so what others might recommend to helping cut your compile times. Robert. True enough, but I am only building the core of osg and the default plugins. None of the other components build as I don't configure them and I'm unlikely to ever use them. I'm not going to be using any of osgParticle/osgTerrain/osgWidget in the foreseeable future either (worse luck) If there are another bunch of core libs, eg. osgWidget I have to remember to disable them in cmake or they build as well. It's not too bad at the moment, but if we wind up with lots of 3rd party libs the cmake interface is a pain. But it also seems silly to have a core library which doesn't build by default, or you wonder why it's there. Unfortunately we 'doze uses have to build the debug and release builds so it all adds up. Perhaps the cmake could be split in 2, so there's one for the core (and a couple of examples) and another for the extras? That would work with visual studio projects but I don't know if that would work with linux build systems... That would be handy as people new to osg could get up and running faster and you've still got all the goodies to play with later. ___ 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] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
Hi Robert, 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. [...] I just want to say: Yepe! That's my favorite option. I'd like to pinpoint that it could be useful (for some 3rdParty) to use SVN externals in OSG when 3rdParty code is also located in an SVN repository. That could be for 3rdParty that are very stable, or for OSG's branches. But I also think the coordination of 3rdParty's should be a preparation work, as you said. That may require another thread, but I also have a question that may sound crazy at first: why not hiring people so that OSG's deployment, testing, packaging, and more are centralized, systematic and well tested? And why not calling for donations to have enough money for that? Maybe this would bring OSG to be more industrialized (in the good way of the term ;) )?... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
HI Luigi,
On Tue, Dec 9, 2008 at 7:23 PM, Luigi Calori [EMAIL PROTECTED] wrote:
Are you thinking of a sort of 'battery included' OSG, with dependency and
addons?
I see dependencies as an external issue, any 3rdPartyPlugins directory
would just provide source and Cmake files to find/specify the required
dependencies - in much the same way the present plugins do.
Providing links to/instructions for obtaining dependencies is
something we need to populate the wiki with, and if possible provide
binaries/links to binaries for most common of the dependencies.
I have looked at distributed CVS like Bazaar or Mercurial and it seems to me
they are more flexible in allowing different management patterns.
My hope for osgforge was that it would take us some way towards
providing an incubator with standard web interfaces (tracs) and svn
version control. So far it has taken off though. Other version
control system might help facilitate things, but only if we can keep
things consistent across the wider family of OSG add on projects.
Currently I' m working on our VirtualRome osg4web Firefox and IE Plugin.
We can for sure benefit from having more structured firefox example/support
Perhaps it might be possible for us to provide a WebPlugin base class
interface that backends are provide for IE/Firefox/webkit. We'd need
to look at the commonality between an existing IE plugin and similar
Firefox plugin to see how practical this would be. Could you publish
you work in form that it could be reviewed in this light?
.
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?
Dependencies discussion would be best done in another thread.
Another project I wold like to be adopted is OSGSwig pythin wrapper
Again another worthy topic that deserves another thread... :-)
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
I guess you could write a .osg ascii output from a Python builder
class to a string/memory rather than to file and then re-direct this
be loaded by the browser plugin. I don't know if you are aware but
the .osg plugin has a mode psuedo loader built into that that parses
the .osg file directly from the filename passed into the plugin. You
just add .osgs to the string and then call readNodeFile(Geode{...
}.osgs). This might help with you usage model.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: HI Simon, This isn't the thread to be discussing existing build issues, could you please start a new thread for this. Robert. Sry, didn't mean to get side tracked; I'm just concerned about seeing a load more libraries added to the default build. If they all have separate Cmake stuff, then it's not a problem. It would be nice to see other mature libraries go into the osg source tree though, esp. if I can just add say 'osg/thirdParty' to my includes list and then reference their headers in the same style as osg. Regards, Simon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPssVT9LetA9XoXwRAlqkAJ42dxBHlBU+iaqECSo1Y5q11G2njwCfXJi/ 9d2y5e42SK84I5uw/dWGva8= =gBw8 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it time that we have a OpenSceneGraph/src/3rdPartyPlugins directory?
Hi Robert, On Tue, Dec 9, 2008 at 5:31 PM, Sukender [EMAIL PROTECTED] wrote: That may require another thread, but I also have a question that may sound crazy at first: why not hiring people so that OSG's deployment, testing, packaging, and more are centralized, systematic and well tested? And why not calling for donations to have enough money for that? Maybe this would bring OSG to be more industrialized (in the good way of the term ;) )?... Another off topic It would nice if we could raise the money for a team, but I don't think one could do it out of donations. We are talking about need to raise $USD 50k to 100k a year to bring on dedicated staff, I can't image us pulling in this type of donation each year. For fixed such salary costs you need a regular income to pay it, which points to a subscriptions model. Support contracts would fit the requirement of regular income. I do have a few clients on professional support, but the number is high enough to employ other engineers, as it only a fraction of my yearly income - the bulk of my income is for bespoke development projects, but these don't directly fund general project admin but they effectively enable me volunteering me time on the unpaid aspect to project work. Such funding doesn't stretch to employing others. One could look to converting more commercial OSG users to pay for support, but we'd have to have a ten fold increase in the number of support contracts to pay for one engineer fulltime. Scaling funding is hard. What is more practical is leveraging a bit of time from a number of different osg users. This is effectively what we do right now, although not always as effectively and consistently as is desirable in terms of getting binaries and dependencies out regularly. Any further discussion about funding reallys needs to pulled into a separate thread. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
