-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sean Lynch wrote:
> > 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. Well, doing the skinning is not such a big deal. My gut feeling on this is that if I had to keep two skeleton hierarchies in sync it would cost more in terms of programming than to implement skinning and/or keyframe animation. But that's just my opinion, nothing more. > > 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. Well, that explains it. I just wouldn't like to animate e.g. a full forest in this manner :D > 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. Well, but you pay for it by high CPU usage just for animation of the trees. It is a tradeoff, but I would rather spend CPU cycles on the gameplay than on moving tree branches. I didn't see that game, though. > > 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. This really looks promising - calling external libs is a major headache in Python at the moment. Especially if it is a C++ and not a C library. I hope that they address this issue as well, right now you can call only C libs, because C++ has no standard ABI. 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 iD8DBQFDW+Kun11XseNj94gRAhdHAJwIg0guL8uF6D6Hh6TYFpAf+QF1PQCeJz1e +O4YyIzXvPfISj/W8dvatZ8= =DU+K -----END PGP SIGNATURE-----
