-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Eric,
Erik den Dekker wrote: > Jan, I followed your comments to Cedric and above with interest. You made > several important remarks to ensure that osgAnimation will properly support > character animation / skeletal animation. > > However, I wonder if you are not putting too much emphasis on just this > aspect while there may be more ways to do and use animation. It is my > understanding that animation means that a certain aspect of a scene is under > control so it can be changed over time. This aspect is usually orientation, > position or scale, but may also be color, a float weight, a bool, a string, > etc... maybe some custom type. IMHO osg should take a generic approach > towards animation, albeit probably not too generic :). I think that basic position/orientation/scale style animation is supported by OSG already. No need to reinvent the wheel there. > Perhaps 3D studio max > (or similar - I just happen to have some experience with this app) can be > taken as an example how to approach animation. It uses animation controllers > and key frame animation to implement animation and in my experience this is > quite flexible. I wonder how far osgAnimation should go in replicating > similar functionality. That's fine, however I would be extremely wary of an all-encompassing animation framework that tries to do everything and does nothing well. I think that it is better to take the "Unix-like" approach - a set of small tools that do one thing, but do it really well. That means, that if you need only translation/rotation/scaling you use a simple keyframing support that is in OSG already, if you need skeleton you use osgAnimation or osgCal, if you need morphing, you use a (yet not existing) morphing library. The only thing these things have in common is a that they vary over time. That is already well supported in OSG - both the real time and simulation time. There is nothing else really common in the code and shoehorning all this into one is not a good thing from the maintainability and usability point of view. The Max example is a red herring - unless you plan to develop an animation package, it has little relation to OSG. In Max it makes sense to have all under a "single roof", because the animator usually uses several of the tools at once and Max authors cannot predict whether he or she is going to make characters or animate flying boxes. However, the underlying code is very different under the hood for each tool. That said, there is nothing that prevents Cedric (or someone else) to implement e.g. support for morph targets in the skeletal animation lib or making osgAnimation a collection of tools to support different types of animation instead of just a skeleton-based one. However, I think that this is as far as it should go - if you need something special, you are better off developing a special tool for it, than trying to "bend" the existing codebase to do things it was not intended for. > This said, I must admit that I have only quickly glanced over osgAnimation > in its current state, and I believe it already supports much of what I > mentioned. I am not sure what you mean - right now all it does is a simple software skinning of models animated via skeletons. There isn't really a notion of a controller or anything. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJGBCon11XseNj94gRAreEAJ9jVs08NPYxrnaWv04hsmLweiz9OwCfabz3 vNWQmiXZghXnfaqIUOzL4eU= =UeSJ -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
