Quote - I have a freeware RAM monitor running (on Vista), which is called RamBooster.  It registers about 4MB of loss with each run of the script, which is doesn't do for the cloth.  It's exactly the same RAM loss I experienced with the earlier version of the multi-actor shrinkwrap.  Presumably I just need to track down where I'm looping references.  Do you pass any references in the hit data?  If it isn't all fresh copies, that might be the source of my problem, since I del the Mesh instance which created the hit list, but keep the hit list for the subsequent distance screening loop.

Hmm.. there shouldn't actually be anything you can do in the python code to cause a memory leak.  deleting objects is not necessary, unless you're done with it and the script still has other things to do.  Otherwise, you can just let variables fall out of scope (including script termination).

• Explicately deleting objects doesn't necessarily free any memory... it just decreases the reference count on some item.
• If/when the reference count happens to hit zero, then the item is freed.
• If any other variable is still in scope and holding a reference to it, it won't get freed.
• Once your script terminates, it no longer holds any references to any items.

...so again, assuming there's no bug in C code somewhere (either my extension, or the Python interpreter itself, or some other extension), it shouldn't be possible for you to be causing a memory leak.  On the other hand,  you could del something more than once, but that might potentially cause some item to get freed before it was supposed to be, likely causing a crash, not a leak.

Other possibilities:

1. creating a morph cause Poser to use more memory to store that morph... are you deleting those new morphs from the mesh before checking your Ram guage?

2. once an extension (.pyd) file is loaded by Poser Python, it stays in memory until you quit Poser (and maybe not even then)... so that (those) takes some memory as well.

3. I've tried to keep pretty good track of reference counts in the C code, but it's possible I missed something.

So when you're testing memory, you should (at least):

• run Poser
• load whatever models you plan to work with
• run whatever script you're testing at least once.
• delete any newly created morphs from the model(s)
• (now) get a base memory reading
• run the script again
• delete any newly created morphs after the script has terminated
• check memory again

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.