-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > 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. 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. > 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. If you want to do IK, use e.g. IKAN library - it is free and will do the job for the most part. > 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). 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. 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. > For a clock, I would definitely say just having the hand in a volume > that's a child of the clock would be the best way. Just put the part of > the hand you want at the center of the clock face at the center of the > volume and have the hand's volume share an axis with the face, so you > can just call the rotation method. Exactly. I am more used to OSG terminology which is more standard (i.e. "volume" is "transform node" or just "transform", etc.) but otherwise it is the same things. > 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. - -- 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 iD8DBQFDWaR2n11XseNj94gRAjjoAKDIWHd4zWS0Wiy1PDTi8DC0aL357gCfS4Vz JQnv73m3Hjwtnink7cR1Pmo= =CYYF -----END PGP SIGNATURE-----
