Forum: Poser Python Scripting


Subject: Moving morphs between different figures

Cage opened this issue on Dec 20, 2006 · 1232 posts


adp001 posted Fri, 14 March 2008 at 1:02 AM

If I remember right I said some time ago: Use Numeric.
But you have to use it consistently. Avoiding that data has to be moved between pure Python Objects and Numeric.

Numeric allows you to have your data the way you need it for fast computing (flattend arrays). And, the larger this set of data is, the smaller is the difference in speed to compute this data with Python compared to C. Numeric (or mutch better NumPy) isn't easy to use/understand. But very, very efficient.

Especially for large arrays you'll save a lot of memory with Numeric compared to standard Python objects. And, not at least because Numeric tries to use a continously memory block for the whole array, access ist mutch faster.

By the way: Why do you collected all vertices at once? I mean: If you compute - say - data from the head, why are the vertices for the feets are also loaded? Or is this a stupid question?

The problem is that you have a relatively large and complicated program written "top down" (or linear), not the "Python way" (object oriented). But re-writing at this point may cost a lot of time. So using a DLL seems to be the best way at the moment.

On the other hand, you are hardly limited by Poser Python (version 1.3, 1.5, 2.2, 2.4, perhaps 2.5 later, different features and restrictions, hard to debug). This is the reason why I prefer to collect data with Poser Python and move this data out (via TCP) to something with more bells and wistles.
Actually I'm testing using RPC to get data computed by 2 synchronized linux boxes. Poser Python does just transfer data. Not storing (beside of a transfer buffer). This is very fast, because the transfer is done concurrently in blocks of 2Kbyte (while there are pulled from Poser). Long before the last datapack is sent out, the first finished datapack comes back. And I'm able to turn "the dials" in beetween :)

I was looking into Pyrex, with my initial idea of creating a .pyd.  Perhaps we've now come back full circle to the .pyd idea, with this thought of adding geometry built-in types?

Keep in mind that for Pyrex it is the same as for other kinds of creating a DLL for Python: The used Python Header file has to match exactly the used Python version. But Pyrex works with Mac out of the box (as far as I know).