Quote - Another question for the Quizzical Cage Queue.  The HitPoint type includes a TriPoly type listing.  Is this a reference, or a copy?  If it's a reference, that may be the cause of my RAM issue.  I loop through a series of Mesh instances which exist only during the comparison loop and are overwritten as the loop progresses, but I save the HitPoint lists for use in a subsequent comparison loop.  If the HitPoints being saved contain references to the TriPolys of these Mesh instances, they could end up being orphaned references, such as are supposed to cause trouble for the Python garbage collector.  The Mesh objects to which they refer have been deleted, but the references persist and can't be cleaned up when it's time, because the object to which they refer no longer exists.

At least that's my understanding of how that particular memory snarl can crop up.  If these are references, I may be better off copying the data from the HitPoints rather than storing them....

Again, no rush on an answer.  I'm posting the questions as I have them so I don't forget to ask when you're able to answer....

I don't have time to look into this right now, but at first-glance, my thought/understanding is that what you describe above can't really happen.  The HitPoint holds a reference count on the TriPoly, so the TriPoly can't be free'd until the HitPoint releases it's reference, as well as any script references get released.  In other words, if you free up the HitPoint, and the refernce count hits zero, my HitPoint destructor code will be called... that code will decrement the reference count on the TriPoly, but if your script still has a reference to it, that won't actually get free'd until the script is done with it, but the memory for the (rest of the) HitPoint sstructure will be free'd.  It should all work itself out.

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.