Jan Ciger wrote: > 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. I was talking about ragdoll physics in this paragraph, which I've offered to help with. > > >> 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 :) Yes, this is true. However, the copying overhead is linear with the number of objects and the frame rate, as is so much of the other overhead in Soya. It's also a very minor overhead compared to matrix arithmetic, so eliminating it will not have a huge benefit without eliminating or accelerating a lot of the maths. > > > >> 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. This doesn't make so much sense since most of the time you want to be able to transition between keyframe animation and physics simulation with the same model, so if we transitioned away from it entirely we'd have to implement our own keyframe animation along with the warping of meshes that cal3d already does. > > 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 am a fan of procedural generation and animation of trees. I'm not all that interested in pregenerated animations, hence my bias. For precomputed animations, pre-deformed meshes may be better. > > >>> 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. When I talk about parent/child relationships, I'm always talking about Soya classes. There is a Soya class (node type) that corresponds to dBody and inherits from World, so it can have children. IIRC Soya's node type corresponding to geoms inherits from Volume, though I may have made it World for convenience. > > >> 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)? A smaller memory footprint may be extremely important if you want, say, a forest of unique trees. Play Second Life sometime. The trees there are all unique. > > >> 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. Actually, PyPy has (will have?) its own FFI similar to ctypes, so Python code will be able to call C code directly. It will probably still be cleaner to isolate code that talks to C libs in its own module, but this will be a lot easier to write than Pyrex wrappers and won't require the compile step. One thing I expect to happen is that since PyPy won't use Python's C API to talk to C libraries this way, the type information will then be available to the specializing compiler (the guy who wrote Psyco has essentially abandoned it to work on PyPy) which will give us an even better speed up than calling Pyrex funcs from Python, since Pyrex type information is not available to CPython.
signature.asc
Description: OpenPGP digital signature
