Freezing/ Performance issue when splitting surfaces

Hi there, I would love some help.
I have an issue where I am using elevation data and creating surfaces through grasshopper/ elk. when I split the surfaces the program takes a VERY long time and often will freeze or crash.
I have looked at system requirements and seem to have all of the requirements:
running Rhino 5 on Windows 10
i7 processor- 4 cores
800 GB of storage

I have an SSD installed and tried running rhino from there, but it is not helping.
I have made sure all drives are up to date.
Any help would be greatly appreciated. I will send you chocolate!

Hello, to answer your question with anything more then guesses some more information would be needed
Are you splitting the surfaces in grasshopper?
Are you splitting them one by one or all at the same time?
If you take a smaller .osm file are the results still the same?
Can you upload your definition?


Hi @lando.schumpich thanks for your reply. I am not splitting in grasshopper, I am creating surfaces in grasshopper and then splitting them in rhino. I split them one at a time, and I will upload a file so you can see it. Thanks! file

ok @lando.schumpich I just tested one split and watched the task manager. the first split worked ok and then the memory use stayed up near 60 without dropping. When I tried the second split the memory usage climbed to up near 95%, then the CPU usage climbed and then the disk usage climbed. When the memory was up to 99% the computer froze. Probably if I left it there over night it would work but I would rather fix the problem.

That file is ten times the size of anything I’ve created in Rhino and it looks as though there are only a few objects so some are presumably very complex. That might be a direction to explore.
Could you generate the elevation in grasshopper as an array of smaller adjacent polysurfaces and split each independently?
Could you lower the resolution to reduce the poly count?
If you have complex objects in the hidden layers (spare parts?) could you remove them from the model and see if that makes a difference?
Could you generate a smaller (say 1/10 the size) elevation in a test model and see if that can be split, then increase the size until you find the limits?

Great suggestions. I think creating smaller parts and then splitting them may be the way to go. I was thinking it was something wrong with my system so maybe that is not the case and that is good to know.
Thank you @jeremy5

@John_Brock I wonder if you could help me with this. I am just trying to figure out if it is my computer or the program, because if I can avoid generating smaller surfaces in Grasshopper and then having to join them I would like to do that. If I need to problem solve my system I can!

Hi, sorry, I’m not your guy.
I don’t “Grasshopper”.

ha! Thanks @John_Brock . But actually it’s not an issue when I am in grasshopper at all! After I create surfaces and close grasshopper I am simply using rhino to split surfaces, and that’s when I am having the issues. My computer is freezing and I have looked at all of the specs that people suggest and I seem to have the right equipment. I was watching the task manager and the memory use went up to 99% while nothing else is running but it says Rhino is only using 1,435 MB of memory. I have 24 GB so that just doesn’t make sense!
Any ideas of where I should look for this problem?

Hello - these are massively dense surfaces - but, here the split works so far - one at a time so far and deleting the split off pieces as I go - essentially a trim operation.

Have you tried this one split at a time? Also, do it in a wireframe viewport so the thing does not have to recalculate the render mesh for all the parts.
Both Trim and Split work here.


ok I am going to try to get more and more specific here as a I research this problem.
The memory use is fluctuating during the split process always under about 60%- but then it seems like when the object is split and it says ‘creating meshes’ that is when the memory use climbs up and it freezes. Since it doesn’t crash I am unable to get a crash log. I tried creating a dump file and was successful but I don’t think it’s helpful because the file is from before the program freezes. I wonder if @pascal you can help? I have seen your comments on similar threads. I am really trying to figure this out! Thanks in advance!

ok I will try that! @pascal thanks!
Just to clarify you think my hardware is ok:
i7 processor- 4 cores
800 GB of storage

THANK YOU SO MUCH @pascal. That helped so much. I owe you some chocolate.

Now we’re talking! It took years but my plan finally worked.


1 Like

Hi @pascal I wonder if there is a command similar to ReduceMesh for surfaces like this? thanks!

Hello - there is, FitSrf, but it is tolerance based so on very detailed. convoluted surfaces like the one in your example, it is unlikely to do much to help unless you can live with some loss of detail. Worth a shot though.


Hi There,

I built a desktop with AMD Ryzen 7 2700x + 32GByte RAM with GTX 1060 6GB , under windows 10 and Rhino 5 SR14.

I found that it’s just using only single thread / single core when doing the splitting / trimming.
However with the same action (trimming / splitting) under same file and condition on another laptop (Surface Pro 4, i7-6650u / 16GB RAM) , it seems Rhino 5 SR14 is able to average the task to dual core / quad thread with this surface pro build.

The overall trimming /splitting speed on SP4 i7-6650u is even faster than AMD Ryzen 7 2700x one.

May I ask why Rhino 5 SR14 can’t average the task to multiple core on AMD ryzen 2700x ?