-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Robert (and all),
Robert Osfield wrote: > Your experience on CAL/OSG integration would be useful a guide for the > osgAnimation development. My hope is that osgAnimation would be able > to replace osgCal usage, but without any experience with osgCal I > can't say how easy as step this is right now, or how easy this can be > made, so... it would be useful to get feedback from those who've been > using osgCal/ReplicantBody as to what is missing/needs improving on > osgAnimation to make it possible to move apps over to osgAnimation. > I have managed to compile the branch with osgAnimation and it works OK on my Linux system. Here are few things I have observed, Cedric feel free to correct me if I am wrong here: - - The animation format seems to be not very practical/efficient. The animation is stored as a special node in the .osg file, with each bone having every key specified, even if it is not moving. It is simple, but leads to huge files. Cal3D and most animation toolkits are able to interpolate the keyframes between points in time - i.e. I specify a time when certain key pose should be set, not a set of samples at fixed intervals. If the bone is not moving, only one sample is set at the beginning. Also, from a practical point of view it is better to separate animations, skeleton and mesh files. The same skeleton and animations are often reused for several different meshes (e.g. with different textures or even shapes). This could be probably handled by loading several osg files, but it needs to be kept in mind. This is why Cal3D has these data separate. - - Is there support for different frame rates of the animation? This is a very important feature, together with the capability to resample/interpolate the animations on the fly. E.g. a motion capture system can give you an animation file at a frame rate being anything between 20-120 Hz. You cannot rely on having all animations at the same frame rate, because assets are often reused and pre-converting everything every time is simply not practical. - - How many bones can be influencing one vertex of the mesh? The data seems to be stored as skeleton bone having a list of vertices affected by it + weight. I wonder how practical this is from the exporter/design tool point of view - you typically "paint" weights over the mesh and assign bones to vertices, not vertices to the skeleton bones. This is a detail, though, but it leads to long lists of vertices that are duplicated several times, for each bone affecting the vertex. A more usual way is to have a vertex id followed by a list: bone id weight bone id weight ... That allows to have the long list only once. A pathological worst case would be a mesh where every vertex is affected by all bones. With the current format one would have e.g. 2000 vertices x 15 bones = 30000 vertex entries. With the format I have mentioned, one would have only 2000 entries. - - Support for animation priorities - an absolutely essential thing, but doesn't seem to be there yet (I may be wrong). If there are multiple animations playing and influencing the same parts of the rig, they need to be weighted. For example a waiter carrying a tray with drinks - you have a walk cycle animating the whole skeleton and a raised arm holding the drink tray steady. The arm animation would have higher priority, overriding the walk cycle for the part of the skeleton. Cal3D does this using an animation mixer. One cannot rely on having two animations affecting only distinct portions of the rig - this is not feasible unless one animates everything by hand and it doesn't look natural anyway - e.g. even the waiter's hand above will be bobbing up and down a little in the rhythm of the walk cycle, otherwise he would look like having a terrible cramp in that hand and holding it completely stiff. - - Support for animation blending - there needs to be a possibility to transition smoothly from e.g. walking to jump and again to walking. This is done using animation blending - interpolating between the end pose of one key frame to the start pose of the next one. Without this jumps will occur and it will look bad. - - Hardware accelerated skinning - at the moment the skinning seems to be done all in software, not using vertex shaders. There is code in osgCal that does this already. I believe that there was also the osgCharacter nodekit doing skinning in hardware. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJEiFPn11XseNj94gRAp7zAJ9GfVItg9/yMumJqKSG+vv6I/pLywCgq3X0 /K4ldjB6H5SMwfNCLyJJWEo= =pJFv -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
