Cage opened this issue on Dec 20, 2006 · 1232 posts
Spanki posted Mon, 07 April 2008 at 5:05 AM
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).
...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:
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?
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.
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):
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.