-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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?
Cal3D implements basically these things: 1) Data loading (including exporters for popular modelling packages) - mesh, skeleton, animation files. Skeleton can be arbitrary - e.g. an octopus or even a car, it is not restricted to humanoid skeletons (important feature, IMO!). 2) Keyframe interpolation - you get two poses of the skeleton and you need to calculate the in-betweens smoothly. Basically quaternion slerping, but it can get hairy. 3) Animation blending/mixing. You want a guy to walk and e.g. wave his hand or fire a weapon at the same time - this is animation mixing. Switching between animations should be smooth, not abrupt - blending between poses of different animations over a given time. 4) A little bit of support for spring-mass systems, this was intended for cloth simulation. It doesn't work too well. 5) Software skinning - after calculating the final pose of the skeleton, the mesh is deformed to conform with it. This can be bypassed, if the renderer implements hardware skinning instead. 6) Support for attachments - e.g. a guy picking up a sword from the ground and the sword is then animated together with his hand. As such, the library is not really big. I would hesitate to go and re-implement it without reason, because lot of things you cannot do too differently than what Cal3D does already. If there are specific issues with the library, I would prefer to try to fix it first before throwing it away, together with the large amount of existing data for it and the set of working exporters. On the other hand, a person who knows what he is doing with regards to character animation could re-implement most of the Cal3D functionality easily. However, please, keep in mind that the animation stuff goes way beyond rendering a guy using a hardwired shader for skinning playing a single animation (that is what e.g. osgCharacter does). That is a toy that is not really usable. At least, the keyframe interpolation and animation blending/mixing are essential and need to be in place. Only then can a system such as ReplicantBody or even higher level be used to actually build a usable animation control system on top of it - with navigation, path finding, ground following, motion planning, etc. I do not see much issue with data duplication - the only thing that could be duplicated is the mesh geometry that OSG could potentially load from elsewhere. Skeletons and animations have no support in OSG at the moment. There is also no rendering code in Cal3D itself - all happens on abstract data structures, the library is completely independent on any renderer. It only provides data suitable for feeding into e.g. vertex arrays in OpenGL. However, there is no problem with adding an external loader for these data to Cal3D - everything can be built procedurally, bypassing the native data formats (XML-based, btw). Potential integration could be e.g. with Collada file format that seems to have some support for skeletal animation built-in. >> 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? The osgCal2 plugin has hardware skinning already, however the code needs a bit stabilization and cleanup, IMO. Also, it could use wider testing, specifically for the threading issues. >> 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... True. However, Cal3D and osgCal2 are fairly mature libraries, being in development for many years (Cal3D at least). They provide at the very least the minimal support one needs to get skeletal animation running. Unless somebody sits down today and delivers a new library tomorrow, there is nothing else free (as in freedom) available on the table with comparable features. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHXrKWn11XseNj94gRAkfNAJ9kzc8ZoGkOBAe1Skz+zpa4NdUT9gCg1bjW jK4YPectOSPrtDDZM+uejJE= =9Rnh -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
