-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sean Lynch wrote:
> 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. You are reading too much into what I wrote. I meant "from scratch" as "it is not there and has to be done". No big deal for you or for me, but if a guy is asking how to rotate a wheel, then it perhaps *may be* a big deal for him to do this alone. Not everybody is an expert. > 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. Sooner or later you will hit a performance bottleneck on this, if you will have to copy these data during each frame. But I digress, if you will always restrict yourselves to few characters animated like this, it would work. Just do not attempt something like the Lord of the Rings intro scene where Sauron is sweeping the human forces away using a huge sword :) > 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. Yes, if you want to do physics, I would do away with Cal3D completely. Trying to retrofit the needed functionality on it would be like building a car to fit one wheel from scrapyard. Cal3D is not best library for doing this. I have nothing against Cal3D, I have used it extensively myself, but it is not the right tool for everything. Unfortunately, at the moment it is the only library doing skeletal animation which is freely available. The issues with trees are another matter - in that case I didn't like the idea of using skeletons in the first place - what for? Unless you are going to animate the trees procedurally (which you most likely aren't), there isn't much point in doing so. Pre-deformed meshes or some sort of morphing would work better. > 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. > 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. Hmm, I wanted to write something else here, but then I went to re-read the ODE docs. In fact, you may be right - if you set the velocities at the begining of the rag-doll phase and never touch them afterwards, this may work. I got confused by this paragraph from the ODE FAQ: - --------------------------- 12.6 Is it advisable to set body velocities directly, instead of applying a force or torque? You should only set body velocities directly if you are setting the system to some initial configuration. If you are setting body velocities every time step (for example from motion capture data) then you are probably abusing your physical model, i.e. forcing the system to do what you want rather than letting it happen naturally. The preferred method of setting body velocities during the simulation is to use joint motors. They can set body velocities to a desired value in one time step, provided that the force/torque limit is high enough. - --------------------------- So it may be fine to initialize the model with just velocities, in fact. >>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. I guess that we are both saying the same thing - this is exactly what I have meant. By ODE body I have meant the dBody type in ODE, not some Soya class. > I agree with you about not using them for vehicles or clocks, but I > disagree for trees. Do you animate the trees procedurally? If not, what benefit has a skeleton-based tree over a set of pre-deformed meshes or morphing (apart from perhaps smaller memory footprint)? > > 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. Sure, completely agreed. The discussion about the dynamics was a more an academical thing - to make a new module on top of ODE to provide e.g. rag-dolls to Soya would be non-trivial amount of 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. Hmm, PyPy looks certainly interesting, I didn't know about this project. However, you will still have to interface with external non-pythonic libs, be it Cal3D, ODE or just OpenGL. So these wrappers would be needed. Pyrex is still quite OK - I am working mostly with SWIG wrappers and these can be a lot more ugly than the hand-crafted code in Pyrex. 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 iD8DBQFDWtxUn11XseNj94gRAnqkAKDNnettxhi7KEg85nuNtUomAJS9dACg1z8z 8xfAriSpqtFlr1bTfH4srDM= =/gR8 -----END PGP SIGNATURE-----
