2007/12/10, Jeremy Moles <[EMAIL PROTECTED]>: > 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.
Shader files that are preprocessed by sed are also kept in SVN, so there is no need for windows/mac users to run sed. Preprocessing can be done using OpenGL driver but it compilcates shader debugging (it's easier to see final shader code than try to think what defines are processed and what are not). > 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. BTW osgCal doesn't uses cal3d's mesh files (.cmf). There is a tool osgCalPreparer (not sure is it a good name) that prepares cal3d.cfg.meshes.cache file which contatins all the necessary data ready for fast loading (vertex, normal, texcoord, weight, matrix index, tangent and handedness buffers). If meshes cache file doesn't exists this data is created implicitly. Cal3d's meshes are not ready for hardware skinning. There is a separate CalHardwareModel class which fills vertex arrays with the necessary data (and it is lengthly operation for hi-poly models). Also cal3d incorrectly calculates tangent-binormal-normal basis for meshes with mirrored UV. So osgCal calculates TBN too. Also osgCal performs mesh deformation calculation itself, not using CalRenderer. So the only things osgCal currently uses from cal3d is material description loading plus skeleton and animation system. (And it uses CalHardwareModel but it is needed only at export stage). > 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. Not sure that there is a need for some major clean up for osgCal. Many things was reworked in past few months and osgCal is not far from stable release. > 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)... osgSkeleton is a good idea. The cal3d dependency can be removed with it. But there can be much work to make osgSkeleton. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
