I’ve just upgraded to Rhino 7 and was expecting it to have some performance improvements. However, I’m finding that Grasshopper is significantly slower. Not by a little buy by a lot. This is the same script, running on the same laptop - Rhino 7 on the left, Rhino 6 on the right.
What could possibly be causing this? Maybe the issue isn’t with R7 after all. But the above scripts are run on the same instance of Rhino and GH so they share the same settings?!
The issue seems to be with the topography surface. Baking it in and then referencing it back in makes it work much faster. Could it be something with the trimmed nature of the surface?
@piac So looking into this more, the difference in processing time is due to trimmed vs untrimmed surfaces. My example in R6 was untrimmed but R7 was trimmed. Hence why it was significantly slower.
I then looked further upstream to understand why there was a difference. I’m taking a mesh and converting it into a surface by projecting a grid of points onto it. And this is where the discrepancy is occurring. The mesh ray was failing along the perimeter edge for R7 but working in R6. The mesh had been trimmed and I’ve noticed that again, running the same script in R6 and R7 returns different results.
The initial mesh split produced different results and this could be the reason why the mesh ray downstream fails to find an intersection. Has the mesh algorithm changed at all? @DavidRutten
I’ve improved the inner Mesh.Split function in V7 to be able to maintain and create ngons, to create more beautiful splits. Here is more info.
But, I agree it seems that there’s something more with this file. For some reason, it seems to me that the whole definition recomputes when anything is done even on one side. I’m trying to investigate what is happening, but I think we’ll have to wait for @DavidRutten’s input on that side.
I’ll check also the rest of the files in the afternoon.