-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sean Lynch wrote: > If cal3d does this for models that have no cloth and when keyframe > animation is not running, cal3d is seriously broken and needs to be > fixed. There should be no animation overhead when there are no > animations, and no cloth simulation overhead when there is no cloth.
Indeed, but the stuff is still being updated. Cal3D is not a high-performance lib, even though it can deal with e.g. 1000 characters in medium detail (~ 30 bones, 2k polygons) - I have tested it myself. > There has been plenty of prior work in transitioning from keyframe > animation to physical simulation. The transition needs to happen as soon > as the deviation from the keyframe animation starts, for example at the > moment the character trips or is hit. The linear and angular velocities > are easily calculated by keeping track of the bone positions in the > previous frame and dividing the delta by the time between the frames. Sure, however Cal3D has no support for this. It has to be implemented from scratch. > Given that most games that use ragdoll physics also use keyframe > animation, this is not true at all. Pardon? Do you keep two skeletons, one for physics and one for key frames, just because you can? I have never seen a design like that - if you want to have the dynamics working right with minimal hassle, it has to be integrated. > If we have cloth then the cloth > could continue to be simulated by cal3d even while we were using ragdoll > physics, for example. You could do this, but there is exactly zero benefit - "cloth" in Cal is only a very primitive spring-mass system, there is not even collision detection between the cloth and the body mesh (just have a look at the Cal3D demos). > And during ordinary keyframe animation we'd be > able to use all of cal3d that we'd normally use. Also keep in mind that > the synchronization between the different bone structures is > unidirectional at any given time. When we transition from keyframe > animation to physical simulation, we impose the bone positions on the > physical structure, and then we do it the other direction during the > physical simulation. Well, how is that "unidirectional"? Moreover, this is not sufficient - you need to initialize the forces and torques as well, otherwise the character will just collapse into a heap instead of e.g. tumbling (if the torques in the joints were 0) or behave erratically (if the torques/forces weren't 0). I am not speaking about a character getting shot by a projectile (that is easy to calculate), but about character e.g. falling forward from walking animation where you want to model inertia (e.g. a guy running against the user which shoots him - unless you shoot him with bazooka or shotgun from very close distance and simply blow him away, the body has to travel forward before falling). > Ok, I didn't realize it was possible for the simulation to fail to > converge when there were no redundant constraints. This could be a > problem even if things collide at high speed, then. Exactly. In fact, ODE in particular has lots of problems with high-speed collisions. I had a student which did a game of pool with ODE and it wasn't pretty if a high-speed collision occurred - the balls were moving in a very unrealistic manner, most of the time flying in all directions. > Actually I have some > doubts that you're correct. I know it's not possible to simply move one > part of an articulated structure and then start up the simulation again, > though even when I do that things don't break, I just don't get the > results I want. What I have not tried is moving the part that I want to > move to the position I want to move it to, setting velocities to zero, > stepping the simulation without drawing a frame, and repeating. You should set not velocities but forces and torques instead. If you set a velocity to zero and there is some torque/force in effect, as soon as you enable the simulation the structure accelerates accordingly. That's probably not what you want, except perhaps for gravity. > > This is how the scenegraph in Soya works as well. I think I may have > changed the physics stuff so that bodies have to be children of the > simulation world, however, but it would not be hard to go back to > allowing bodies to be children of other bodies. Actually, it should be the other way 'round - the mesh (geom) should be a child of the ODE body, because the body drives the mesh, not mesh the body. > > Look at the internals of Soya sometime. We do this all the time. Of course, that is standard thing for scene graphs to do. It was just for illustration for the eager developer wanting to use skeletons for something where it is ultimately not needed. > > Copying is used constantly in rendering ODE simulations, and it's not a > problem at all. For how many objects? It is not the most effective approach. Not to mention that the two structures have to be constantly kept in sync and that is not a nice job to have to do for a complex articulated structure such as human body. > I don't remember what method I was using in the last version I checked > into CVS, but the collision detection should work fine as long as there > is no trimesh being used for the chassis. Trimesh-trimesh collision does > not currently work, whereas trimesh-sphere collision (for the wheels) > should work perfectly. Well, the buggy was constantly sinking into the terrain, if I remember correctly. I didn't check how exactly was the thing modelled. Jan - -- Jan Ciger GPG public key: http://www.keyserver.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFDWqi4n11XseNj94gRAhCYAJ9hFrWsS0u9Wg2PoSnMiuDWpJIJLQCggker HZPz16/b8IhxBIKqc1fcStY= =T93F -----END PGP SIGNATURE-----
