For some time, I've been putting together a specification for a 3D mesh manipulation application, mainly for my own amusement. It's not a full modeller, just an add-on along the lines of John Wind's Compose. It's intended to address some of the needs of Poser users in particular, so one requirement is to be able to run on both Windows and Mac. If I ever get around to programming this thing, it will be a freebie; so there's no development budget, and I can't afford to buy a Mac to see if it works there. Some sort of scripting language seems to be indicated, and Python is an obvious choice. But, tell me, experts; is an interpreted script going to be able to handle loads of 3D calculations? I wouldn't expect it to be lightning fast in any case, but does it stand a chance of working with any sort of usefulness?

Quick answer: Python by itself is way too slow for heavy calcs. If the application can stand on its own, it's better to write it completely in C or some compiled language. If it truly needs to interface with Poser (controlling Poser parameters directly, or using the Poser display) then the Poser-connect parts will be in Python and the time-critical parts in C. There are a couple of well-established ways to make this connection; the best is called Swig. I've used this to handle large OBJ files. Python does "natively" include some rather odd and specific addons that work fast, but these are not well suited for 3d. Also, there are a couple of available packages for fast 3D action in a strictly Python app. Look up PyGTK for a start. I haven't used this, so can't say how well it works.

Thanks Ockham. This isn't meant to interface with Poser at all, it's just that it's designed to work with OBJ format meshes, and would also be able to read morphs and figureResFile lines from Poser files. I'll look into PyGTK. I'd like to avoid compiled helpers if I can, since I'd have no way of compiling or testing the Mac version. If I have to go the compiled route, I may as well make a Windows specific application, but that would be a shame.

A crude rule of thumb, in order-of-magnitude terms, is that if you need to handle much more than 100 things, Python will be too slow. Process 500 vertices or 500 lines in a file, for instance.