On Sat, 2007-12-08 at 14:07 +0000, Robert Osfield wrote: > Hi All, > > After a two month break I'm now doing a purge of the submissions > backlog. I doubt I'll get all the way through before Monday, but on > Monday I'll tag the first dev release since 2.2 stable was made. This > dev release will be 2.3.0 and be the first concrete step towards the > final 2.4. This leads me on to asking the question - what features > should we aim to integrate with 2.4? > > My own short list for contenders for integration are: > > osgOQ - Occlusion Querry support > osgCal - Cal3D integration
I noticed there was a lot of Cal3D discussion going on here so I'd figure I'd chime in and say a few things. I have write access to Cal3D SVN I obtained a year or so ago when Palle Raabjerg and myself rewrote the Cal3D Blender exporter, which we built by starting from the version in the Soya project; I've also fixed a few small bugs here and there in Cal3D proper. I'm pretty familiar with Cal3D in general, and with the various Cal3D OSG plugins that exist. As a matter of fact, I'm the one who made the Cal3D videos on the website, and I used OSG to do it. :) http://home.gna.org/cal3d/ For a bit of info (and some personal opinion): Firstly, there is the "generally-referred-to" osgCal (officially called osgCal2), which was originally made by Ruben Lopez and has had many additional edits since then. There is also a GPL version that is incredibly more sophisticated which was created by the people at Underware, but the license wouldn't not allow for wholesale inclusion into OSG. Vladimir Shabanov recently made some changes to osgCal2, and I believe he and Ruben coordinated so that his changes were committed upstream. However, as I mentioned back then and I believe Jan Ciger has alluded to earlier in this thread: the code will need a lot of love before it's ready for serious inclusion. For example, the last time I checked, the shaders were somehow parsed by sed before actually being written into a valid shader file, and there's simply no way I can see anyone in the Windows or Mac world willing to accept such a restriction. One thing that should be kept in mind when using Cal3D is that in it's current state, Cal3D isn't a skeletal system alone--it's a skeletal animation system+mesh format, and one cannot be divorced from the other. Furthermore, there is a lot of data reproduction in Cal3D that already exists in OSG, and no way to easily (or cleanly) make changes therein. In the opinion of someone who is familiar with Cal3D, I'd say that we wait a bit on inclusion of this until someone has the time to cleanup the current plugin. Hardware skinning is a pretty common performance boost these days, and whatever solution arises for OSG, I'd personally look at support for this feature as the make-or-break aspect. We also need exporters, and while I wrote a significant portion of the Cal3D Blender exporter currently in SVN, I did it at a time where my knowledge of both Cal3D, Blender, and graphics/3D development in general was very poor, and thus cannot attest for it's reliability or cleanliness. :) As far as ReplicantBody is concerned I'm unsure--I've never looked at it. To be completely honest, character animation is such a huge issue unto itself that it probably deserves a lot of discussion and review before any steps are taken--but that's just my opinoin. Every time I'm forced to put any thought into the issue, I just get sleepy. What we __really__ need is an osgSkeleton NodeKit, which can then be exercised/demonstrated in the Collada importer, but would be usable alone as well in true OSG style: osgSkeleton::Skeleton* skel = new osgSkeleton::Skeleton(); osgSkeleton::Bone* root = new osgSkeleton::Bone(); osgSkeleton::Bone* child = new osgSkeleton::Bone(); root->addChildBone(child); skel->setRootBone(root); I bet once a basic, simple system was released, people would go to town making the necessary changes to bring it up to speed with other kits. It wouldn't have to be perfect, but as long as it was adaptable and done in true OSG fashion, people could subcass things in osgSkeleton for their own uses or to inject their desired interpolation algorithms (which is a big area of interest for animations buffs)... P. S. When I finish a release-candidate version of osgHUD (or whatever you want to change the name to), I'll be peddling that for inclusion as well. :) I've made a number of changes in the last few days if anyone is keeping up with SVN, and almost done with a decent implementation of a "table" layout, very similar to how HTML tables are done... however, no one posted any complaints to my first thread, so I'm just going to keep proceeding as normal, though I did remove the silly functional code that no one could have possibly understood but myself... it's a shame how difficult it is to do use something as [conceptually] easy as std::for_each()--it's a nightmare, when you can almost always achieve the same thing cleaner and with less code using for(iter;iter;++)... > osgAL - OpenAL integration > > I'm not personally familiar with these libraries, but do know that > they are known to work with the latest OSG so should be relatively > straight forward to integrate. Thoughts for the authors, maintainers? > What extra work would be appropriate before integration? Would you > be happy with integration? > > My own inclination towards integration is to make it a bit easier for > OSG users to assemble their application without chasing down lots of > different nodekits all of which are maintained in different places > with different build system and different release schedules. The > downside for me is there is more work involved at my end at least > initially while we get the build systems working well across the range > of platforms that the OSG supports. Long term I'd hope that this will > diminish and it'll be less support work associated with helping end > users get things working at there end. It should also be possible to > make the overall OSG dev experience for end users slicker as we should > be able properly test and get areas like multiple > window/multi-threaded usage properly excercised. > > I would also like to see the core OSG have support for scripting out > of the bag, as well as integration with the main browsers. One has to > gauage what is doable in what time frame so should be considered in > terms of 2.4 or 2.6 etc versions. > > I'd like to see scripting supported out of the box to enable us to > develop applications purely from scripting languages, so developers in > this realm would just need the binaries to the OSG installed, and no > need for C++ dev environment. There are limits to how much > functionality you can expose in this direction, but my guess is it > should be possible to write reasonable useful apps, and especially > good for prototyping and cross platform portability. One has to ask > which scripting languages to go for - Lua and/or Python? Lua would be > the easiest to integrate in terms of being very self contained i.e. > which could stick the whole of the lua interpreter into the core OSG > distribution and one would hardly notice as its so tiny. > > Thoughts? > Robert. > > ps. I'm still very busy with other on going work so please don't > expect me to be able to dive into this stuff right away. Come 2008 I > should start become a bit more available and able to start looking at > progressing some of the above, so opening this stuff off for > discussion now will help us mesh gears better when the time comes. > _______________________________________________ > 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
