Wasp Python components performance drop in Rhino 7

Hi,
I am currently testing the Wasp plugin with Rhino 7 and, while all the functions seems to work properly, I noticed a significant drop in performance compared with running the same script in Rhino 6. The drop is very high, in the order of 2-10 times slower than the RH6 counterpart.

Any idea of what might be causing this? The plugin relies on a lot of collision detection between meshes, which is done with the MeshMeshFast method, which I saw flagged as obsolete in the API. Can this be the issue for such performance drop? What would be the best policy for computing fast collisions between meshes in Rhino 7? MeshMesh? Or MeshClash?
@piac @stevebaer maybe you have an idea?

I attached the script.
0_02_MultiPart_Aggregation.gh (42.5 KB)
0_02_MultiPart_Aggregation.3dm (101.0 KB)

Hi Andrea @ar0551

I looked up the file, but there’s too much going on for me to understand where you see the problem, and how I can address it.

Is there any way you could come up with a single item that I can test?
A group of meshes that takes longer than in V6?

In any case, performance is not the primary goal, it’s reliability at this point. It’s easy to write a something regarding mesh intersections that is almost infinitely faster but has 0% reliability (does nothing), but it’s harder to write something that is 1% more reliable and maybe 10% slower.

I’d still be thrilled for some sample that runs more slowly in V7.

Thanks,

Giulio


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

Hi Giulio @piac

sorry for sending a file with a bit too much info in it :slight_smile:

I recreated the basic logic within the collision solver of Wasp in a python component, and the issue is even more noticeable. The same component computes in 5-6ms in RH6, while it takes around 600-700ms in RH7.

Does this have something to do with the MeshMeshFast method being flagged as obsolete? In the case of a collision solver which simply has to detect whether a collision happens or not (I do not need to have the intersection geometry returned), what would be the best option in RH7? Using the new MeshClash method?

Thanks for looking into this, here is the test file: meshCollisions.gh (11.8 KB)

UPDATE: I tried using MeshClash, and it seems to still be 10 times slower than the RH6 implementation using MeshMeshFast.

UPDATE2: Using MeshClash and iterating over meshes one by one brings the time down to 30-40ms, which is ca. 5 times slower (which is not ideal, but usable and should prevent most crashes…). However, it seems to scale exponentially with the complexity of the mesh, diverging from RH6 quickly as the complexity of the mesh increases…

Yes, if that’s enough why not.

So, I there’s an underlying issue that I think we might want to improve for your case: the new intersector does not need to intersect pairs of meshes only. It’s perfectly capable of running all the intersections at the same time. There’s no overload to keep track of where each polyline came from, though. If that is what you would need, we might be able to add it. I speculate that it would take down the intersection time by a large factor, especially for large amounts of meshes.

Secondly, I’m sorry to hear that you are having issues with speed in comparison with Rhino 6. I tried to reproduce, but here’s what I am seeing:

Rhino 7 is actually faster here. I tested this on 7.6.21082.5001, which is an experimental release but should about the same speed as SR4 and SR5.

Please let me know your Rhino version, and also the result of the _SystemInfo command might be of some help.

Giulio


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

Hi Giulio,

this is very odd. Here are the results of the same test on my machine

As you can see the RH7 is significantly slower. I am on RH 7.4.21078.1001.
systeminfo.txt (2.6 KB)

I will try running updates on RH7 and see if it improves.

UPDATE: I updated to RH 7.5.21082.11001, but still no improvement.

What’s the processor you have on your laptop? I am trying to get some thoughts and need to explore all routes

And it is not only on my computer. Few of my students last semester reported also Wasp running extremely slow, and leading to crashes on their machines.
I can try to collect some info on their setups as well, if that might help.

I can confirm the same behaviour on my system (though to a less degree), Rhino 5 vs Rhino 7:

A post was split to a new topic: Newer IronPythons iterate more slowly?

I am reporting back with two items, pretty good news!

I see now - the problem is fixed in the early SR6 I was using; this speed problem is only present in 7 SR4 and SR5. I would appreciate if you could test that it’s fixed in this early 7 SR6, or in the last 8 WIP.

In general, MeshMeshFast is an obsolete method but, if you guys feel that it is highly required, we might spend some time optimizing it also in V7 or V8, probably bringing it to being slightly faster than V6, but not much. I don’t think it will ever be very reliable because there’s no way to input a tolerance, and that’s why it was obsoleted.

However, my understand is that a method to intersect all the meshes at the same time and only provide an indication of which ones touch would be much more needed. This is possible, there is code internally to do this, and would likely take a fraction of the overall combinatorial execution.

In organize work around this, I’d need your help stating a wish and an expression of your needs.

Thanks,

Giulio


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

2 Likes

@piac great news indeed!

Yes, the new SR6 fix the issue, and now calculation times between RH6 and RH7 are comparable. I will relay the information to other Wasp users who had issues.

About the Mesh intersection method, for the specific use of Wasp it would be great to have a method which quickly detects if one mesh collides with a set of other meshes, and which stops checking as soon as one collision is found (as one collision if enough to make the placement of the new mesh not possible). Having a method like that would be fantastic for very quickly checking collisions.
Let me know if you need more information about this.

Thanks a lot for looking into this.

2 Likes

I noted the request for MeshesCollide at RH-63507. It’s in the Rhino 8 wishlist.

1 Like