Jan Ciger wrote:
>
> Tree blowing in the wind by skeletons - well, you can certainly do it,
> but it is an overkill, IMHO. And certainly you do not want to do it with
> Cal3D, because that is intended for characters explicitly and there
> would be LOT of overhead with that. Not to mention how complex such
> skeleton would be. For animating a tree it is completely sufficient to
> precalculate the animation, e.g. in Blender or Max and just use
> pre-deformed meshes. Of course, if you want to animate a tree
> procedurally then a skeleton is better approach, but Cal3D will not work
> well for that.
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.
>
> The joints in ODE form also a kind of skeleton, however one very
> different from the simple bones which Cal3D has. E.g. if you want to do
> rag doll physics on a Cal3D character, you will need two skeletons - one
> for animation in Cal3D and another made out of ODE joints (assuming that
> you are using ODE) and ODE bodies to describe the masses of the
> character. Then you would drive the Cal3D bones from the ODE hierarchy
> during each frame - you need to hierarchically update the position and
> orientation of each bone from ODE data.
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. 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.
> Definitely a non-trivial job to implement - lots of matrix/quaternion
> algebra there - for example a human body has over 70 joints, many with
> multiple degrees of freedom and some are even mutually dependent. It is
> possible to do it, but I would say that this is outside of the
> capabilities of most hobbyist coders unless you have the required
> knowledge already. You could simplify the skeleton at the expense of
> realism (that's what games do - you will rarely find more than 20-30
> joints there), but still the math is the same :)
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.
> >> Your quote about a hammer suggests you know a better way.  I'm asking
> >> what that is.
>
> As I said - use normal transforms, unless you want to do physics (why
> e.g. a clock would need physics is beyond me). These are called
> "volumes" in Soya, AFAIK.
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.
> If you want to spin a wheel just apply some constant rotation each
> frame. Even better, make the amount of the rotation proportional to the
> elapsed time between two frames and the velocity of the vehicle and you
> are set. Ideally, the spinning of the wheel will be driven by the
> physics engine itself and you do not have to care about it - you just
> apply force to "push" the car forward or use the motors in ODE to apply
> torque to the joint where the wheel is attached. However, this is all
> documented in the ODE documentation.
>
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. There's an ODE demo called
"Car World" or something in C++ that has pretty sophisticated cars.
Maybe at some point we should make a car class that lets you set shapes
for the wheels and chassis and set suspension parameters and drive
characteristics. That would be fun.




Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to