Hello! I have two questions. I hope there is a solution…
We are making complicated algorythm that already contains around 11 000 nods. Quite often we see red screen after opening Grasshopper file. After we see it we copy-paste code to a new file. Is there any better solution? Is it possible to avoid red screen?
In one part of the algorythm we use Squid plugin to generate textures. We use a loop to generate textures one by one. I mean we use one part of algorythm a few times with different incoming parameters. As soon as algorythm gives its result it goes to a next combination of parameters. Sometimes after starting the loop Rhino shuts down with McNeel Error Reporting message. Inside of algorythm we don’t have any “heavy” components (the heaviest one is squid component and it takes 14ms), so each loop step is “easy” for the computer. But it seems that something inside of algorythm or Rhino by itself writes temporary files and after some time Rhino can’t deal with it anymore. After we close Rhino and open it again this loop works fast and we don’t have any problems. Is there any solution to clean temporary files maybe? Or can it be any other problem?
Thanx a lot! We really need help with these problems!
The graphics platform we use in Grasshopper 1.0 (to wit: GDI+ also sometimes called System.Drawing) will eventually have trouble drawing geometry very far away from the origin. The bigger your files get, the further out components will appear and this will, sometimes, unpredictably, inconsistently, crash the display. The red screen means that such a crash was caught, but Grasshopper wants you to save your file now and restart lest the next crash slips through the net and brings down all of Rhino, with loss of all unsaved files.
What you can do is simplify your file. Seriously, who is going to be able to maintain or find bugs in 11k components? There are four typical solutions to reducing the size of a network:
Make them smarter. This is obviously not always possible, but quite often people will copy paste a large chunk of components because they do not understand how to leverage the native iteration logic of Grasshopper. To be fair, this can be really difficult, even when it isn’t impossible.
Convert large blocks of simple components into expressions or scripts. This requires some textual programming skills, so it’s not for everyone, but if you have 50 components that do something reasonably straightforward, you can always try posting it here and hope someone else will create a single python or C# script that does the same.
Cluster your logical groups. Mostly large algorithms like yours are made up of distinct, consecutive steps. You can turn these blocks into clusters, so that your top level file reduces to a just a succession of cluster objects and all the complexity is copied piece-wise into subobjects.
In Rhino6, it is now easier to split large files into a bunch of smaller files, by using the Data Output and Data Input components. Part 1 of your large algorithm will simply write its computed data to a file on the disk, and part 2 which resides in a completely separate *.gh file, will read that file and continue working on it. Keep daisy-chaining your data the more you break your monolithic file into chunks.
David, thanx a lot for your answer. We tried to make our code as much simple as it was possible. We optimized it not to copy the same code. And anyway this project is really big with a lot of functionality inside. We will try to follow your suggestion about c# and clusters. When it is possible we will switch to Rhino 6 as well.
Do you have any suggestions about the second question?
I don’t know Squid, but if it’s using GDI as well to generate images it’s possible that it does not properly dispose of GDI handles. Early versions of Grasshopper didn’t either and as a result it would just crash after a while because Windows only allows an app to use so many handles before it gets shut down.
