Right. Note that going fully parallel is not always the best way to go fast. Most algorithms are fundamentally single-threaded, and trying to parallelize them can overly complicate things or lead to incorrect behavior. Sometimes it even ends up running more slowly than the single-threaded version.
Multiprogramming is hard. Things that are intuitive and easy in a single thread suddenly become counterintuitive and mysterious in parallel threads. It’s very easy to accidentally write race conditions or deadlocks when you write for multiple threads–and very hard to debug these sorts of things when they do happen (and they will happen).
All that being said, we are currently working on a fully multithread-capable version of Panda. Ideally, we’d like to be able to run the graphics rendering fully in parallel with the Python application. If we are successful, then the application programmer can still write a simple, single-threaded Python application, and watch with satisfaction as it runs to 100% utilization on both his CPU’s.
But that lofty goal may be some ways off still. In the meantime, the current version of Panda as distributed on the website is not compiled to be thread-safe, so you should not attempt to make any calls to Panda in two different threads (for instance, you should not run collisions in one thread while you are moving nodes in another thread), or you will certainly crash eventually.
It is possible to download and build your own custom version of Panda that will be thread-safe. It’s just a matter of turning on the appropriate flag when you build. This will, of course, add a bit of additional runtime overhead to manage the mutexes, and it will make everything run a little slower, but it will also allow you to perform multiple interactions with Panda in separate and parallel threads.
One easy application for this, for instance, is to load models asynchronously, so that you can continue rendering while you are loading models in the background.
It is also theoretically possible to run collisions in a separate thread. Of course, how your application deals with collisions that happen asynchronously to your movement commands is another can of worms altogether. Probably you don’t really want to run collisions asynchronously, since that would introduce really weird artifacts.