algorithmic modeling for Rhino
So this is slightly off topic, but I think someone here might have a understanding of what is happening. I have also posted this on Rhino.Python, but I am still looking for the right answer. Technically this is a Rhino.Python problem and not a Grasshopper issue, but it could apply to both!
I was trying to take a simple example of moving a ball around and see how it could be animated through Rhino.Python. The code works great in wire frame with now memory issues at all. However, when I switch the view to Shaded or Rendered, things go south pretty quickly. The RAM usage of Rhino which was steady around 350mb (ish) now grows every frame after a minute or so, it is in the GB's and never drops even after the script has stopped.
What gives? Clearly this must be possible because Bongo does something similar when it does animations. Check out my code below and I would love to hear your thoughts.
Tags:
Bongo displays animations by just modding the display transform for objects. It doesn't actually transform objects until you render.
Could it just be undo recording in your case? Every time you move an object a copy of it is made, the original goes into undo-memory and the copy is moved. What if you limit your undo?
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Hmmmmm.
So if I add the command rs.Command("_ClearUndo") at the end of the loop, that seems to solve the problem, however that is very sloppy in my opinion.
I have tried working with:
doc.UndoRecordingEnabled = False
print doc.UndoRecordingIsActive
But it always says recording is still active even when I set it to be false for the document.
We are on to something here, I would rather solve this with rhinoscipt / rhinocommon and not have to run a "command" to do it.
Thanks!
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by