On Thu, Jan 14, 2010 at 4:45 AM, Gerrit Voß <vo...@vossg.org> wrote:
>
> Hi,
>
> On Wed, 2010-01-13 at 17:59 -0600, Carsten Neumann wrote:
> > Hello David,
> >
> > David Kabala wrote:
> > > Well my timing could have been better for this. I regret sitting on
> > > this code as long as I have, but other projects and life got in the
> > > way. Anyways, I would like to announce to fellow OpenSG users a set of
> > > libraries that myself and several other programmers have been working
> on
> > > for a few years now. It is for OpenSG 1.8 and is a set of libraries
> > > that can be used with OpenSG.
> > >
> > > These include:
> > > Animation
> > > Video playback(to a texture)
> > > Physics wrapper for ODE
> > > Sound wrapper
> > > Lua bindings
> > > A fully OpenSG integrated UI library
> > > Advanced particle system library
> > > Game features, like a minimap UI component
> > > Metabolic visualizations, probably not interesting for most, but we
> > > needed it.
> > >
> > >
> > > Here is the website:
> > > http://www.vrac.iastate.edu/~dkabala/OpenSGToolbox/<http://www.vrac.iastate.edu/%7Edkabala/OpenSGToolbox/>
> > > <http://www.vrac.iastate.edu/%7Edkabala/OpenSGToolbox/>
> >
> > thanks for making this available. The site was quite slow earlier so I
> > did not look at this in detail, but it sounds very interesting.
>
> could not agree more (with the interesting, I did not notice the slow).
>
Thanks. :)
>
> > > These libraries are for OpenSG 1.8. However, we are in the process of
> > > porting them to OpenSG 2, and would like to open up a discussion with
> > > the OpenSG dev team for possible inclusion in future releases of
> OpenSG.
> >
> > sure, since the code itself is LGPL from what I've seen, it should not
> > be a problem. The simplest form of inclusion would probably to turn the
> > parts into Contrib libraries (mainly because they add new 3rd party
> > dependencies), although a few things might better become regular
> > components. How modularized are the above parts, can they exist as more
> > or less independent libraries or do they have dependencies on each other?
>
> I started looking at it, in particular the 2.x work which seems to be
> available in the sourceforge git repository. From glancing over it
> (so far) we should definitely start the discussion as soon as possible.
>
Yes, the toolbox-migration branch on the git repo:
git://opensgtoolbox.git.sourceforge.net/gitroot/opensgtoolbox/opensgtoolbox
This is just being used for development purposes for porting and is very
much under development.
>
> Some of the core changes I see problematic (e.g. virtual function in
> fields).
>
This, was just modified to allow for easier porting, as there were virtual
functions similar to these in fields in 1.8. These were placed in for
easier porting of the Animation library, and the XML reader/writer in
FileIO.
> Other things I do have to understand better, e.g. promoting something
> like the event concept to core inclusion (in the main tree, not inside
> contrib) is something we have tried to avoid as we did not want to
> enforce a particular application model. But I don't know enough about
> your approach to judge all the implications. E.g. what would have to
> change for all containers so that this model works consistently and
> not only for the parts from the toolbox or how would things work
> without using your mainloop, e.g. with the simple or complex managers
> and their app models that are already there.
>
I realize that what I am doing with the event system is not documented on a
high-level. So, I will try to write up some on what it is the code is
doing.
I feel that moving the event production to core would be helpful, and could
be done in a way that wouldn't force a specific application model. However,
it sounds like you would like to move the WindowEventProducers out of the
core, and into something like a contrib lib. In my rush to start the
porting process I just put them in the core, but understand that they should
probably be moved to a contrib library.
In summary, I think it would be useful to put the base code of the Event and
EventProduction in the core, and moving out the specific native
WindowEventProducers to a Contrib library.
>
> What I also would like to see is that we somehow will be able to
> consolidate the animation packages (where it is possible and
> makes sense). Both you and Carsten seem to have put a lot of work
> into this so it would be great if you could link up with him.
>
Agreed, I realize that Carsten's work with hardware skinning should probably
supplant, the SkeletonAnimation part of OpenSGToolbox.
>
> We also have to in general, independent of this concrete set of libs,
> think a little bit about naming for things in contrib as I guess some of
> the names will clash.
>
> Ok, jumping into the technical discussion, if possible (and hopefully
> without to much work on your side) I would like to propose a slightly
> different inclusion process from what you started in the sf git repo.
> Ideally we could use this as the general blue print, and derive some
> documentation of the process from it.
>
> The general process I would like to use, given that the current
> cmake system makes it possible to include externally kept libs
> into the OpenSG build quite easily (e.g. something like
> http://github.com/vossg/OSGAddOnsGV) is to stage things first
> this way.
>
Ok, It sounds like you would like me to move the lib porting into the
http://github.com/vossg/OSGAddOnsGV repo. I could put a remote branch of
this somewhere, or could/should I get write access to this one?
> One of the advantages is separating out the core changes.
>
> Changes to OpenSG itself could be ideally handled over github
> and pulled independent of the rest.
>
> Also, once we have it running in this staging setup it is a lot
> easier to work with it and understand the implications. Moving
> from the staging area into the main OpenSG tree is usually
> not that difficult, for things that go into contrib it is
> straight forward. It also should be able to handle external
> dependencies, if not I want to fix this anyway.
>
> As a starter if you give me probably the weekend I could
> look into what is already inside the sf git and try to
> come up with a initial external setup suggestion.
>
Should I wait for further information on this, or could I continue to work
on some of the porting on the remote branch I am using now? If it would not
be too difficult to move over to your inclusion process, then I would like
to continue the porting on my remote branch.
Thanks for all of the input, I hope I haven't given you a headache with all
of the code and changes I have made on the remote branch. :)
David Kabala
>
> kind regards
> gerrit
>
> --
>
> Gerrit Voß
> 盖瑞客
> ---------------------------------------------------
> Centre for Advanced Media Technology (CAMTech)
> 南洋理工大学, Nanyang Technological University, (NTU)
> 新加坡, Singapore
> --------------------------------------------------
> CAMTech is a joint centre of Fraunhofer-IGD & NTU
> --------------------------------------------------
>
> If we communicate everything we ever think, speech
> just becomes static. And all of us become bores.
>
> J. Clarkson
>
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
