When using curve from object commands (especially _DupEdge) and window-selecting block instances containing polysurfaces with enough edges, so much memory can be used that, if Rhino.exe is not killed in time, the windows shown below will display. Would it be trouble to add escape canceling to these commands?
This also occurs in V5. I’m running Windows 7 Professional with 8 GB of RAM.
_DupEdge with window-select on the block in DupEdgeWindowSelect.3dm (1.8 MB)
will not cause Rhino to use up all the memory on my PC, but the quick memory consumption by Rhino.exe can be viewed in Task Manager.
Thus far, I have not been able to reproduce the out-of-memory condition on two different systems I have here:
1.) Windows 10 w/ 16 GB RAM
2.) Windows 10 w/ 8GB (VMWare on MacBook Pro)
If you explode the block, which contains a single Polysurface (e.g. Brep), the command completes successfully, right? And the edge selection is much faster too?
Performing sub-object operations will always take a tad bit long and require more memory, as Rhino (essentially) needs to get the block’s definition geometry and transform it to the correct location before the command can operate on it.
I’m not sure there is anything we can do about the temporary memory consumption, in this case, but we will look into it.
If Rhino (one instance) is the only major application running, the model I had uploaded does not run my PC out of memory. I provided it because I thought it was large enough to study this memory issue.
I often work with assemblies imported from STEP files that contain blocks with 1000+ face polysurfaces. Due to the memory issue, I avoid running particular commands with window-select directly on block instances, but sometimes it happens, and I try to kill Rhino.exe in time to avoid having to restart my PC.
Since the memory usage ramps up so quickly, I wonder if for every edge the full brep data is being duplicated and retained in memory.
Yes, running _DupEdge directly on the polysurface is much faster.
Note that other curve from object commands, e.g., _Project and _DupFaceBorder, also use considerably more memory on the block instance than directly on the polysurface. _ExtractSrf does as well even though it produces no output.
