I’m creating a small animation and for that I need to rotate things a lot of times - I have like 150 objects and they rotate around a center as well as around themselves, and the idea is to see the intermediate moves. This is eating up my memory very quickly. Programming ClearUndo in the loop doesn’t seem to help.
Any way around this limitation? Otherwise I’m going to need to invest in more memory… 
–Mitch
Hi Mitch,
Please post (or send) and I’ll see what I can find…
Assuming this is based on RhinoCommon:
Any geometry that gets created can be disposed using the Dispose() method. This will free up the used memory, but you cannot use the geometry afterwards - accessing it will raise a DocumentCollectedException.
In principle, this should not be necessary, as the garbage collection should dispose of any unused objects. It takes a while for the collector to kick in though, and in my experience, does not always help to free used memory.
@menno - Yeah, unfortunately I’m not creating any geometry at all, just rotating existing objects in the file. There are (will be) 150 sets of two parts - more or less detailed - and some of them might be assemblies of several other parts. The whole set has to rotate incrementally 300 times around a fixed center point and each object has to rotate around its own axis “smoothly” 360 degrees, which means more or less in 1 degree increments stopping for a short instant between rotations…
@dale I am still working on the script, as soon as I get it working satisfactorily I will send it. Right now I’m just working on a test file with boxes to represent the objects (which I haven’t received yet), they will be more complex…
Thanks, --Mitch
Definitely a memory leak of some sort going on… Ran a script with some rotations (160) and the memory soared, after it finished, I closed the file (opened a new blank one) and as you can see below, according to Task Manager, Rhino is still holding on to over 8.5 gigs of memory. Only the one blank file open. I think this is reproducible, I will upload the file to tech along with the script. --Mitch
Edit: @dale file and script uploading now to you…
Oh, and if it’s any help, it appears it’s not the number of rotations that is causing the problem, it’s the number of objects being rotated (maybe that’s obvious)… I can rotate a single object practically continuously around an axis for hundreds of increments of 1 degree and have the memory use remain stable, but when I start rotating lots of objects together (in this case over 300) even a few times, the memory consumption goes up rapidly.
Any clues on this? Running my animation script with my box proxies here for about 15 minutes runs the memory consumption up to over 10 gigs… As this thing may last almost an hour it may run my work machine with 32 gigs out of memory… Getting another 32 will cost me about $400…
–Mitch
@steve is out of town, and he is the “garbage collector” here. Just waiting to review this with him…
OK, thanks Dale… When the collector is on vacation, garbage piles up… 
I think in this case - as a fix is not likely to be available in time - if there is one - I will probably have to split the video into two or more parts and then do some fancy video editing to put it back together…
–Mitch
Hey Mitch,
I’ve looked at this for a while and haven’t been able to figure out the cause. I can repeat the bug and have it on my bugtrack list at
http://mcneel.myjetbrains.com/youtrack/issue/RH-26641
I doubt I’ll have any sort of fix available soon since I still haven’t figured out what the problem is.
Steve
The cause is almost certainly that there is a single undo record for a script, and transforms simply pile up in that one record. This is a well known issue that Bongo has had to work around since its inception.
Andy
That’s pretty much the conclusion that I came to and commented on in the bug report. What workaround does Bongo do? Conduits?
Bongo uses a couple of methods to work around it:
Conduits - during an animation preview, everything is dynamically drawn without moving the object in the document. In any case, without using this method, everything would be extremely slow - so if possible, this is the method I would advise Mitch to use.
When actually rendering an animation, the objects actually have to be moved in the document so the renderer can see them. In this case, what we do is to actually run the render loop outside of a command so that each frame gets its own undo record. The automatic garbage collection then takes over - but this is a real hack. We basically have to hold Rhino in a modal state outside of a command to make this happen.
Mitch - to prove that this is what’s happening, once you’ve run your script and you’ve got 8Gb in “memory leak”…and you’re back at the command line - type clear undo. It should all go away.
Well this is unfortunately beyond the current scope of my abilities to program… but thanks…
Unfortunately, this is not the case as I posted earlier in post #5 of this thread, Rhino does not “let go” of the memory with ClearUndo and the memory continues to be held by Rhino even if the file is closed and a new blank file is opened. So there is something else going on as well…
–Mitch
Any clues on where this this massive memory leak phenomenon is coming from? I’m still experiencing it on any file where I move objects successively, where even after I ClearUndo AND close the file! So I end up with an idling Rhino (blank file) that is consuming literally gigabytes of memory… Only way to reclaim it is to exit and restart Rhino.
Thanks, --Mitch
