Grasshopper in Rhino 7 extremetly slow

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.

Is there a new setting that could be affecting this?

Hi Paul @parametricmonkey1

what is the Rhino document tolerance? Is it possible that it is different?

Thanks,

Giulio


Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Hi Giulio

Both the Rhino and Grasshopper settings are then same:

Any other ideas about what might be causing this?

@parametricmonkey1

do you have a sample I can use to reproduce?

Thanks,

Giulio


Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Thanks Giulio.

File attached

GH slow.gh (884.8 KB)

So this is really weird.

Testing that file I just uploaded (GH slow) in R6 and I get this

But recreating the file (GH slow 2) from the source and running it in R6

GH slow_2.gh (71.4 KB)

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

R6 gives perimeter triangulation, R7 doesn’t.

Has a hack, I can offset the split box but I would prefer not to. Any ideas why this would be happening?

File is to large to upload so I’ve uploaded it here

Hi Paul @parametricmonkey1

I can help with one part.

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.

MeshSplit2.gh (12.0 KB)

I tested GH_Slow and GH_Slow2 and both come with similar timings in V6 and V7.

A post was split to a new topic: MeshSplit problem