On Tue, 2007-12-11 at 09:18 +0000, Robert Osfield wrote: > On Dec 10, 2007 8:27 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote: > > 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. > > How big is Cal3D? I ask in terms how much effort would it be required > to reimplement the unique parts not found in the core OSG?
It's hard to say--there's a lot of code in Cal3D supporting the mesh format, XML loading, matrices, vectors, quaternions, etc. If I had to estimate, I'd guess OSG already contains 20-25% of what Cal3D has to implement itself to be graphics library/system agnostic, and another 20-25% or so is code relating to it's mesh format. So, you'd probably have to re-implement half of it... :( > > 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. > > I thought there was already hardware skinning support in place. So > which versions which hardware skinning? Not in Cal3D itself. The software doesn't make any attempt to bind itself to any graphics API, so things like hardware skinning are left up to the user (though they do include examples using the old shader/assembly code or whatever it's called). Vladimir patched support for GLSL skinning into osgCal2, but it's currently Linux only... > > 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. > > Indeed - a good topic to break out into a separate thread... > > > 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;++)... > > If you can get osgHUD ready for integration then I'm very open to > reviewing it with a view to inclusion in 2.4/2.6. We do need to save > people from the trials and tribulations of going with something like > CEGUI. 2.6 is my goal... > W.r.t awkwardness of some program concepts, C++ is the culprit here. > My own feeling is that scripting languages shine for high level GUI > work. One could use a scripting language for both the control and the > layout setup. How to make this integration possible is another big > topic... > > Robert. > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
