I have a difficult one today I don’t even know if I can explain it clearly, let’s try:
I’d like to select for each Brep the Breps that are closer within a certain threshold distance.
and I’d like to calculate the distance using the closest of one of the points that populate the Breps.
Basically I’d like to do something like that:
…
create an empty tree that has a branch for each brep
populate each Brep with n points
for each point calculate the distance of each other point of the other breps
if at least one point of any Brep is closer than a certain given distance to one of the points of Brep 1 add the index of that Brep to Branch 1
repeat for every Brep
…
All this effort is necessary to try reducing time of a bigger algorithm where I’m trying to find intersection of hundreds of complex Breps. I thought that filter out the farther Breps maybe it will be faster. I’ve already tried with clash and I’ve already managed to find closest Breps by comparing the distances of their baricenter, but clash is slow and baricentre is not robust enough for narrow breps.
I don’t know if the info I gave are sufficient and I cannot even provide an example algorithm because I’m stuck at step 1…
I would say trying to implement something more robust and performant than Clash from scratch here is a bit of wasted effort. It is made exactly for this use case. Just trust McNeel on this one
Depending on your geometry, try to mesh the breps before using Clash component. It might speed things up!
Don’t graft data before. Instead compute everything in single iteration and rebuild the data tree as you want it using the First Index and Second Index outputs.
I did already few tests, and I was able to spedup the algorithm of 10 times by following my custom logic compared to clash, that’s why I’m trying to find a different solution, however with my logic I can only calculate the distance of breps by using their baricentre, if I would find a way to calculate the distance of more than one point on the surface of the Brep it would be much more robust and I think it would be maybe not that much more slow compared to my current situation.
Here’s what I got, as you can see with clash the speed is much slowerd I don’t understand why but that’s what it is. So I’d like to implement the top algorithm to make it work with multiple points rather than only the baricentre.
If you are going to do Solid Intersection after, anyway the initial computational cost of the collision finding will be negligible in comparison to it
The barycenter approach cuts a lot of corners and is bound to underestimate the amount of contacts. Especially if you have lot of elongated elements.
That’s why the Solid Intersection computes faster with your the barycenter method. You are likely finding smaller incomplete clusters, potentially missing a lot of geometry that is still overlapping.
You have to use Clash if you want “correct” results instead of guesses. To make it faster (reduce the amount of Geometry in each Solid Intersection operation) you can reduce the Distance tolerance to zero, since there is no purpose for it based on what I see you are doing.
I though so as well, but if you look at the image carefully it is not negligible, I don’t know why, but if I use clash before the solid intersection that node computes in 2 seconds compared to the other version of the algorithm which takes only 200 millisec.
The number of solids that are send as input in the solid union is the same, in the example I set up, but if the lists of solids are computed with clash it takes 10 times more!
About underestimating the clashing with baricenter I totally agree, that’s why I was trying to implement the other method with more points on the surface that I asked help with.
Anyway, now I’m curious to learn if it’s possible to do such type of data structure manipulation wether it’s useful or not in this contex, maybe I’ll use this knowledge in the future!
