-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Cedric,
Cedric Pinson wrote: >> You are right, but it's not the job of osgAnimation to make this >> assumption, osgAnimation >> interpolate bewteen keyframes. The optimization of key is the >> responsiblity of the exporter >> instead. In the osg exporter i bake everything without optimization yet, >> that's why it produces >> a big amount of data. To work quickly i just exported all baked animation. >> If you want you can just put one key for a channel or two with 40 >> seconds between them. >> So it's not a blocker. But in the futur you could want to separate each >> channel like PosX PosY PosZ >> because sometimes it vary only on one value and you can save space like >> espacialy if you have to bake >> animation. OK. My concern is not so much optimization (osgAnimation compressing the keyframes), but the fact that the library can deal with sparse keyframes for some bone and will correctly interpolate between them. If it can do that, despite of the current naive exporter, then fine, but I didn't see the timestamp/offset anywhere in the exported animation. How does it work? >> So those 3 elements can be splitted in different file, and in animtk it >> was like that before, the .osg is just a container of those three elements. OK, that is what I suspected too. >> There is no framerate, you specify your keyframes in seconds so more >> your put keyframes >> in a short range of time and better the resolution is. Sorry, but that is *NOT* acceptable. That is related to the issue with the keyframes above. You need to allow to either specify a duration of the animation or a frame rate. You cannot rely on the density of the keyframes to do this - that would require that every animation has keys even for frames where nothing is moving, just to maintain the framerate. That is extremely inefficient. Also, conversions from one framerate to another would be extremely difficult, requiring resampling and re-interpolation of possibly thousands of keys. The way to go is to say: duration 30 time 0 bone 1 x y z qx qy qz qw time 15 bone 1 x y z qx qy qz qw time 17 bone 1 x y z qx qy qz qw With just three keys I have fully specified the animation, without any implicit assumption about the duration or framerate. Moreover, there is no need to maintain a long stream of interpolated keyframes anywhere - the animation engine still needs to interpolate between them in real time, so why not exploit this for storing the animations too. With your approach I would need 30 keys (assuming one key/second) - 10x more data. Your naive approach will simply not scale once you have to deal with many animations coming from different sources with different framerates (mocap, hand-animated, procedurally generated, different project, online repositories, etc.). You cannot assume that everything will pass through a converter that will normalize the framerate and pre-calculate the interpolated keys for you - that is just impractical and costly. Also, I have noticed that you have included scale keys. If you want only rigid bones (the most common case, one rarely models something like the "Gummi bears"), then you can drop both scale and translation. The quaternions/rotation matrices/rotation vectors are enough, together with the binding pose of the skeleton. You just apply the transformations recursively from the root of the hierarchy each time. That allows a very compact representation. > >> the format stored is VertexGroup. >> For a geometry you have a set of VertexGroup, a vertex group is a list >> of 'id of the vertex' and its 'weight'. >> The name of vertex group identify the target typically the bone. Using >> this format is generic. For example >> if you want to extend the mesh, like adding new vertexes, you can add a >> group for them and give it the name >> to the new bone or other elements that could influence those vertexes. >> Then rebuild >> the association on the fly. I choiced this format for genericity it's >> easier to manipulate, but i know sometime it's less readable in >> the osg file. I am not concerned about readability of the osg files - those files are intended to be machine readable, not necessarily human readable. However, the amount of memory and the efficiency of manipulation of the data is a problem - do realize that a practical scenario can have 2000-3000 characters visible and animated at any given moment. I have done this with osgCal before and it worked, even with software skinning. > > 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. > >> It's the same amount of data. it just differents way, you suggest >> 2000 x 15 >> and it's currently >> 15 x 2000 >> but i am agree your solution produces less lines. Not really - it makes a difference to have to parse all that and also to keep that in memory. E.g. if you want to add a new bone that will affect your vertex group, with my approach I just add a new weight to the relevant vertices. With yours I need to duplicate the whole list of vertex IDs and add new weights. The format I am proposing is equally generic as what you have, but more efficient in practice, IMO. The idea of vertex groups is really important for the modeler/exporter, but not at all while you are actually rendering the animation (there you care just about the weights and bone matrices), so I do not see why to keep it there. Your format will be also pretty hard to translate to a vertex shader - there you need for each vertex all the bones and weights that are affecting it so that you can transform it. However, what you have is a list of vertices for each bone instead, requiring a costly run-time conversion. > >> You are right, it's not yet here, it's the next thing i plan to do. OK >> Of course it's essential too, it's in the pipe too OK > - 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. > >> Yes not yet inside osgAnimation. The current software implementation can be >> optimized too. But i dont have time to do that right now. I have to >> finish some functionnalities >> before. If someone wants to help :) Well, as I said - with your current architecture this will be hard to do. Look at how Vladimir did it for osgCal (Cal3D does software skinning only). I know that the GPL version of osgCal had hw skinning as well. >> Thank you for the list of remarks, don't hesitate to i would like your >> opinion on the sceduler/mixer >> i plan to do. I would like to make something like in flash, a timeline >> where you can put at any frame >> a callback. And when we could compose sequence of animation as timeline >> too recursively. It can be confusing >> but i have not found a good way to manager animation in time, even with >> osgcal it was hard to plan animation in >> time, and do introspection when you need. >> Example when you click on mouse, you compose a squence of different >> animation on a timeline and then you play this timeline. >> (sitdown, drink a beer, ...). i mean to manage sequence it look very >> interesting. and easy to make introspection like removing the last >> animation of squence if an event is catch ... > >> What do you think ? I think you should realize what is the goal - making an animation composer/editor or an engine to actually *play* the animations? What you have designed is very complex and not needed for replacing osgCal alone. A simple mixer takes a list of active animations and blends them using their weights. This is done by calculating the corresponding poses for all active animations, weighting the resulting bone positions using the animation weights and summing them. If you want to make it more sophisticated, you can add code ensuring that the bones actually stay rigid (i.e. do not stretch or shrink - that is usually unwanted while mixing). The animation scheduling what you are asking about is a different issue and typically not something you need to really bother too much with. What is important for the higher level code is to be able to know whether and which animations are active, have a callback/signal/something to know when an animation has stopped and good ease-in, ease-out capability, with blending between the finishing animation and the one starting next. Then it is the responsibility of the higher level code to sequence the animations. Pushing this into the low level code is not going to be practical unless you want to "pre-script" the whole activity, which is rare. A typical case could be a character walking, sometimes jumping and turning to avoid obstacles. The obstacle avoidance is driven by the user (e.g. using cursor keys/mouse to steer it like in a shooter) or by some kind of AI and will not be deterministic - I cannot make a timeline/schedule when to schedule a jump or turn. Typically, the user/AI needs to turn *now* because it has detected an obstacle/incoming bullet/whatever, not sometime in the future when you have scheduled it. ReplicantBody is implemented as described above - Cal3D deals with the low level stuff and Replicant strings the animations together into actions, including things such as proper walking without sliding and similar. I think that this division needs to be maintained - you will not be able to devise a "one size fits all" scheduler that will be efficient, sufficiently flexible and not a crazily complex monster. The end-of-animation notification/callback is important for the AI or animation driver to know when to start a next action - that could be an animation or something else. This is something Cal3D doesn't have and one needs to resort to inefficient polling. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJEsdFn11XseNj94gRAoenAJ9nQCfD4jBEoU2+LRgEtPB2XQqyPgCgsN/+ VqfggL06xVJ5F0rr0eS9Dco= =20Eq -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
