Potential memory leak in Rhino 7 for Mesh.Split method


I have an issue with python code I wrote and cannot figure out what to do to fix it. I am trying to split a large number of intersecting meshes between each other. All the meshes are initially made conformal and contain triangular faces only, so the Split command should work fine. The problem I found is that when I use Mesh.Split method (rhinocommon), Rhino 7 consumes large amount of memory and does not release it at all. Every time I run the script on about 70 meshes containing in total ~160K faces, Rhino 7 consumes ~1Gb of memory. This does not happen in Rhino 6, but Mesh.Split method does not produce adequate results either (I believe there were changes done to mesh intersection/split algorithms for Rhino 7). Below is a part of my python script.

def SplitMeshes():
    go = Rhino.Input.Custom.GetObject()
    iniMeshes = list()
    newMeshes = list()
    for objRef in go.Objects():
        rObj = objRef.Object()
        if rObj.IsNormal and rObj.ObjectType == Rhino.DocObjects.ObjectType.Mesh:
    for i,ma in enumerate(iniMeshes):
        print 'Working on mesh: ', i+1
        splitMeshes = ma.Split(iniMeshes)
        if len(splitMeshes) > 1:
    for ma in iniMeshes:
    del iniMeshes[:]

Or maybe I don’t clear/dispose some containers or objects properly?

@piac - is this something you can help with?

Hi @pyati

thank you for the report. I tried to guess what was missing in order to make your sample work, and made up a sample file.

andrey-test.3dm (164.9 KB)
andrey-test.py (764 Bytes)

Tracked at RH-64145.

I was thinking about somewhat different geometry. I attached here more complete test code and a test file. The code consumes about 400Mb when splitting meshes in this example.

If this issue gets fixed in Rhino 7, please let me know.

Andrey-SplitMeshes.py (3.9 KB)
Andrey-ManyMeshes.3dm (3.9 MB)

Please let me know if this upcoming SR7 starts to work better. It contains a fix for RH-64145.

Some internal tools to track memory leaks indicate no leaks at all with the sample. There might be a slight memory increase due to Undo’s. You can use the ClearUndo command and also run an in-place garbage collection in case you feel the need.

clean-gc.py (140 Bytes)

It seems that the issue is pretty much resolved in the SR7 release. There is still some memory increase but it looks normal as the number of objects increases after splitting. Thank you for helping with this!

1 Like