We have a serious lagging issue in the script that contain many clusters.
The issue setup:
Rhino is set to shaded, rendered or any other view than wireframe
A grasshopper file containing many clusters is opened (even with solver locked)
The issue:
The mere selection of curves in Rhino is extremely slow. It causes serious lagging with several seconds of waiting.
What we’ve tried.
We have been through and set all objects inside clusters to preview off.
We see an increase in lag the more clusters we place. Exploding the clusters removes the lag.
We come from Rhino 7 where this was no problem - we have tested in Rhino WIP where this is also no problem. However, in Rhino 8 this is a massive issue for all users of our tool.
We upgraded to Rhino 8 a while, but this is forcing us to downgrade the entire company (not mine, a client’s) back to Rhino 7.
The current only solution:
Exploding all clusters… which is very much against our philosophy of keeping repeating code maintainable.
Downgrading to Rhino 7 - We are already relying on many of the new native features in GH in Rhino 8.
Upgrading to Rhino WIP… Not ideal
Wish:
Is this possible to get fixed in a Service Release
Attached files
A file containing a series of polylines similar to that of a project file. Clean Polyline File.3dm (4.7 MB)
Two gh file, one containing clusters and another similar file with no clusters. Clusters.gh (453.2 KB) NoClusters.gh (749.3 KB)
How to replicate:
Open the rhino file, set to shaded view, open grasshopper, lock solver, open clusters.gh. select objects in Rhino
I don’t think cluster is the issue, I think the loading of Python & C# into Rhino is. Cluster amplifies it to a significant level. Look at the screen recording below where the first instance of Python and C# components take quite a lot of time while the subsequent ones are almost instant. It wasn’t an issue with Rhino 7 though.
Unlike OP we don’t have the luxury to roll back to Rhino 7 so could you please put this higher on the list?
Even if you could somehow make the loading of Python and C# part of Rhino startup for now that’d feel much better for our end users because otherwise having a frozen GH script for 1-2 minutes after clicking open is not fun.
Hi @Japhy, I checked in SR22 - bug was there. Then I checked in SR23 and the bug was fixed. There is nothing in the release notes that can explain this, but I don’t complain. Worth having a look at why it suddently works maybe
@Japhy - we celebrated too early. The error is back.
It worked perfectly in SR23, and now the people who have upgraded to SR24 and SR25 have issues. The exact SR24 is SR8.24.25281.15001.
This is literally holding the entire company back from using our tools properly, so it’s very high prioritiy from our end to get this fixed.
it’s still the same despite we’re on the latest release. However I found out that if you double click on a blank canvas after opening the script it will speed things up. Don’t know why, but it work for us.
While we’re on the topic of lagging, same thing happens on Rhino 8 when you exit from a cluster. It is much more slower than R7. We have auto-save off so saving is not a problem.
Sorry I haven’t had my coffee yet when I type it. Double click on an empty space on the canvas like the image below. Also can you check out the cluster issue as well please? Thanks.
@kike, I can see that you have been assigned the issue. But unfortunately the fix is set to Rhino 9.x.
Currently we have around 200 users, and lots of complaints about speed due to this issue! You fixed it in SR23, and the error then came back in subsequent SR’s, so is there any chance we could get this fix into one of the next Rhino 8 Service Releases?
