As image shown above, there are seven closed breps connected together with various geometric sizes and opening within the volume. They are all in contact at least one of another brep.
Does anyone have an idea to find the connectivity data on brep?
I know I can do a geometric trick, such as using all the midpoint of edges to measure the closest distance between point and edge. If the distance is zero, then I dispatch them. But this method is computationally heavy, the performance isn’t that good if I’m having much complex circumstances.
Just wondering there must be a quicker way to obtain the connectivity data.
If you’re worried about performance, I’ll give it a shot. This definition converts the breps to meshes (practically identically, since they’re rectangular), and then tests relative proximity of meshes by testing the proximity of vertices of one mesh to the faces of another. This works well with quad meshes - if there’s connectivity, there’ll always be a vertex within a proximity threshold. I use the Impala plugin’s “ParMeshCP” component to quickly compute all the proximities within a threshold in parallel, and saves a lot of extra computation on points that are not within the threshold. You can download it here: https://www.food4rhino.com/app/impala
Let me know if you have any questions about how the definition works - a lot of the logic is just sorting and shuffling the connectivity indices around to get a good result. I dipped into a quick C# (Symmetrical) at one point just to simplify, but could work it out in pure GH if that’s better. The connectivity lines here are drawn from the ‘center’ of each brep just for illustration purposes.
Thanks for your quick response.
Your script is neat and efficient, it’s exactly what I want to perform.
There are two things made me confused.
First, the ParMeshCP component seems like doesn’t include one of the connectivity data, that is why there is a c# symmetrical to find the missing one.
Second, I’m not that familiar with C#. How do you find the missing one in symmetrical? Specifically here below.
foreach(int y in newSet){
if (!res.ContainsKey(y)) res[y] = new HashSet();
res[y].Add(i);
Glad I could help! The reason there is no symmetry is geometrical - we have a couple of cases where two meshes are ‘adjacent’: the end vertices of shape A are close to the face of shape B, but that doesn’t mean that B’s vertices are close enough to A to be picked up also - this happens a bunch where one has geometry that intersects in the middle of the face. Fortunately we know that it’ll pick it up in at least 1 way for sure (unless the shapes are intersecting in a way that doesn’t involve either of their ends?) hence the shuffling.
That loop is exactly the point where they’re reinserted: the foreach loops through the newSet – aka the set of indices that shape A thinks it is connected to – and add’s A’s index (in this case, i) to the set of vertices that each of those shapes think they are connected to (creating the set if one doesn’t yet exist), ensuring the symmetry.
Actually in looking over this I found a small bug: res[i] = newSet; should actually be res[i].UnionWith(newSet); (in the line right after the foreach loop) - we want to make sure that we’re keeping any symmetries that we ‘ensured’ for a particular shape before actually computing the set of that shape. Sorry about that!
