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/> > > 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). > > 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. Some of the core changes I see problematic (e.g. virtual function in fields). 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. 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. 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. 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. 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
