Jan Ciger wrote: > > >> 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. You say "from scratch" as if it's a huge bother. Considering how easy it was for me to implement interpolation in the ODE glue code, this could be rephrased to "it has to be implemented" without the emotional baggage that "from scratch" carries. > > >> 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. We already do this for every single ODE body, so it's hardly a big deal. Instead of attaching the ODE body to a node in the scenegraph, it gets attached to a cal3d bone. The only redundancy that we don't really have now is the skeleton attachment points versus the locations of joints, and that could be abstracted away pretty easily by calculating the joint attachment points from the cal3d skeleton and only keeping the other joint parameters separately. > > >> 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). Well, then it sounds like you're arguing against using cal3d entirely, not just against using it for things like trees. The usefulness of the cloth system is orthogonal to the usefulness of cal3d for trees or ragdoll physics versus simple character animation. > >> 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). I think you must mean momentum here, not force, since momentum is what's conserved. However, the API does not deal with momentum, it deals with velocity which, since we already know the mass and inertia tensor for each body, is just a proxy for momentum. > > >> 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. Again, I think this force versus momentum confusion. Force is not conserved. In fact, ODE resets the force accumulators for each body in each frame. Velocities are exactly what I want, as they are proxies for momentum. > >> 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. This has nothing to do with what I'm talking about. Originally, the ODE glue code would handle conversion from the physics coordinate system to whatever parent you had for the ODE body. This was useful for being able to, say, move a vehicle around by just moving its chassis, because the wheels would stay in the same relative position and would update their corresponding ODE bodies when their invalidate method was called. Geoms can be children of anything, but being a child or grandchild of a body has special significance because the default collision code will automatically create contact joints for the closest body in the ancestor graph of a colliding geom. > >> 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. I agree with you about not using them for vehicles or clocks, but I disagree for trees. > >> 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. Obviously it's not the most effective approach. However, the current implementation of Soya does not make it easy to replace the underlying CoordSyst implementation for arbitrary nodes. A future reimplementation of Soya will hopefully take this into account. Also keep in mind the purpose of Soya is to be a high level game engine with reasonable performance, not ultimate performance. > >> 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. If it was sinking into the terrain I might have accidentally left the trimesh for the chassis activated. Trimesh-trimesh collision should be disabled because it doesn't work.
I am hoping that someday PyPy gets fast enough that we can implement Soya entirely in Python. Barring that, reimplementing from scratch the portions of Soya that are direct translations from C to Pyrex would make the internals much easier to understand and probably much more pythonic, making things a bit more flexible for the kinds of things you're suggesting.
signature.asc
Description: OpenPGP digital signature
