Jan Ciger wrote: > Sean Lynch wrote: > > >> If you're using procedural animations, I think cal3d is your best > bet in > >> Soya right now. The old "morph" object probably would have been even > >> better, but that was dropped in favor of cal3d. I don't see why cal3d > >> should have a substantial amount of overhead for something like a tree. > > That's quite simple - with Cal3D you are updating skinning, spring-mass > models for clothing, interpolating keyframes, blending several > animations and who-knows-what-else during every frame. You do not need > most of that stuff for just animating a tree. It is a very inefficient > way how to do it, especially if each branch needs several joints/bones. > 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. > >> I am willing to help with this, since it's something I've been > >> interested in myself, and I have a lot of knowledge about the ODE glue > >> implementation since I'm the one who originally adapted it from > pyode. I > >> would like to figure out a way to have as little redundancy as possible > >> in this process, since ragdoll physics is pretty common. > > This would be nice to have, however this needs very tight integration > with Cal. Ideally you should have just one single skeleton which will > contain both data for physics engine and the animation data. What is a > big challenge here is how to smoothly transition from purely kinematic > animation (e.g. walking using a keyframe) to rag doll - the character > tumbles. The transition has to be smooth to be realistic and you cannot > just set ODE up to the current skeleton posture, step the world and > expect it to simulate the tumbling properly - it will lack the proper > info about the forces and torques and instead of falling e.g. forward in > the direction of previous travel the character will just collapse into a > heap. That means that e.g. inertias would have to be calculated during > each frame, even if you are playing just a keyframe and not using > physics. Cal has no support for this. You have also no support for joint > limits in Cal - this is needed unless you want to see dislocated joints > etc. 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. > > Personally, if I had to do this, I would completely abandon Cal and make > a new skeleton structure for supporting this. The rendering code which > will have to be written is quite trivial compared to the mess of having > to keep two separate skeletons in sync. Anyway, apart from the rendering > you will not be able to use anything else from Cal. Given that most games that use ragdoll physics also use keyframe animation, this is not true at all. If we have cloth then the cloth could continue to be simulated by cal3d even while we were using ragdoll physics, for example. 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. > >> I also have > >> some ideas on how to do inverse kinematics using ODE by moving the bone > >> to the position you want, then stepping the world, perhaps with no > >> gravity or something, then repeating until the amount of movement to > >> resolve the joint constraints falls below a given threshold. > > This you shouldn't do - if you force the bone into some position by > assigning absolute position/orientation, ODE may become unstable and not > converge or you will get completely bogus results. Do not do this - if > you want to move objects in the physics engine *while* physics is > running, you have to use forces and torques. Otherwise the integrator > will fall apart because you are forcing it into a state which may not be > consistent with the rest of the environment. > 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. 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. > If you want to do IK, use e.g. IKAN library - it is free and will do the > job for the most part. I will have to check this out. Thanks for the pointer. > >> Well, presumably a simplified model would be used. Soya also does a > >> pretty good job of converting between coordinate systems for you, and I > >> think that it's possible to get the coordinate system of any bone from > >> cal3d, which means converting from an ODE body's parent's coordinate > >> system to the bone's parent's coordinate system should not be hard. > > The Cal3D bones are stored relatively to each other. That means that > e.g. if you want to calculate the position of the hand, you need to > multiply in order: > > the body root x torso x arm x forearm x hand (position and orientation > for each bone, of course). 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. > And this is simplified already because I have skipped all the vertebrae > and few other joints in the shoulder :) This has to be done for each > animation frame and for all body parts/bones. Look at the internals of Soya sometime. We do this all the time. > > If you set the ODE structures up in a sane way, you should be able to > just copy the values in a single loop, without any conversion required. > However, see above my thoughts on the efficiency of such copying approach. Copying is used constantly in rendering ODE simulations, and it's not a problem at all. > > >> There is a tutorial called buggy.py that's a car driving across a > >> landscape using ODE and motors and stuff. It doesn't use Ackerman > >> steering or anything fancy like that though. > > Yes, but the buggy is buggy :) There is no damping and after a while the > errors accumulate so much that the buggy tends to just jump out in a > random direction. Also the collision detection is rather poor. 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.
signature.asc
Description: OpenPGP digital signature
