Solid Intersection not finding all intersections

For some reason the Solid Intersection component is not finding all intersections, whereas the brep | brep intersection component does - with the data coming in the same way. Any ideas?

solid intersection (83.4 KB)

Not sure what it would be, but there seems to be an issue with my breps, as solid union should merge all of them together into a single closed brep (from my understanding) but also does not work as expected.

The surfaces are complex (curved) and sometimes “co-planar” (even if they’re not actually planar - I don’t know the correct word?). Solid intersections often fail in those cases.

It seems to fail the exact same way in Rhino using the _Intersect and _SolidDiffererence commands. I think it’s best if we cut out the middle man (i.e. Grasshopper) and just post it as a Rhino bug on the Rhino subforum. If you do it as a user it’ll carry more weight than if I do it.

In the mean time cut the top (trim a bit [neg 0.01 does the job], that is) and everything works. A classic bad input/tol case. (197.4 KB)

I’m having a similar issue. How are you able to post a grasshopper file without a rhino file and the geometry still loads in Rhino?

Right click parameter component with rhino geo referenced. Click Internalize.

In fact what I did (but on the other hand Breps were internalized already) is not the right/safe thing to do: very frequently internalize fails (especially with regard Breps) and then GH crashes (and Rhino as well) leaving you with no other option than disabling the solver and removing all internalized data. I would strongly recommend the safe option: use a Rhino file with referenced data.

This is the first time I’ve ever heard of internalized data failing. The advice to use a Rhino file with referenced data (instead of internalized) is contrary to standard “best practice” when posting GH models to this forum. Sure, there may be extreme cases where internalizing geometry isn’t a good idea, especially if it drastically increases the size of an otherwise small GH file. Most of the time, internalizing geometry works very well and can often result in a much smaller file size than referring to a huge Rhino file.

I’m new to grasshopper, finally feel like i’m starting to get it the last week or so. I don’t know how to internalize the data into grasshopper, I’ve attached the Rhino file and grasshopper file. Notice how the intersection somehow leaves out about 33 of the 100 shapes. I apologize about the couple things in the tree that aren’t being used.

Any advice is greatly appreciated. Thanks for your time guys.

Boolean Intersection (11.7 KB)
Boolean Intersection issue.3dm (13.6 MB)


Warning - when you open this file, SInt takes 1.2 minutes plus to execute. The first thing I would do is disable SInt and SUnion (12 seconds) while exploring the file and experimenting with changes.

With the Rhino file open, you right-click each of the three geometry params (one at a time!) you used to import from the Rhino file and choose the “Internalize data” option. The result is a GH file that is only 51.2 Kbytes vs. the Rhino file’s 13.5 Mbytes! (260 times larger!!) (51.3 KB)

At first glance, the Extrude using the ‘Z’ vector instead of the surface normal for each point causes them to be distorted. And the SBox ‘H’ input should be grafted, though that results in one “side” being shorter than the other instead of one end? (due to the way the SubSrf output is partitioned.)

1 Like

Thanks! I’ll disable SInt and interalize the data next time.

I chose Extrude using the Z vector instead of surface normal because this is going to be injection molded, so this can be drafted properly.

I should have said the goal. I’m trying to fade this pattern from 9 to 0. I found that without partitioning it, it was fading from left to right instead of top to bottom.

I disabled SUnion as well (12 seconds).

Flip Matrix will fix that.

You can also insert a Data Dam before any component which takes a long time to solve. That allows you to ‘pause’ the data at the dam, and only let it flow into the slow components once you’re happy with it.

This is the result of my experiments so far, with various changes to your code - possibly not correct, since I still don’t really understand your objective here? Also, I am puzzled that SBox is producing “flat” boxes that ignore the surface curvature? Unresolved… (56.4 KB) (geometry is internalized, no need for Rhino file)

Thanks for the response. I’ll go through this right now.

To answer your question. My objective is to have the pattern start small at row 9 and get bigger each row up to 0.

Then i want to Boolean Union it with the main body I pulled the surface from.

Forum question: how do you put boxes around your commands like that?

<kbd>Component Name</kbd>

I belatedly added the image showing the geometry generated by the code I posted. The “X” elements are flat, not curved with the surface, and don’t touch each other, so SUnion won’t join them.

Also, I am puzzled that SBox is producing “flat” boxes that ignore the surface curvature?

Surface Box generates twisted boxes. Twisted boxes are made of straight segments. So they will follow curvature the same way a polyline would. If you want to follow the surface curvature then do the geometry array flat and morph it to the surface with “Surface Morph” or even better if you have Rhino6 + GH1 use the Flow component (or Sporph will work as well).

1 Like

Right! I don’t use that often enough so had to look it up, then got distracted with other matters.

Might want to add Rotate to the Brep for the SrfMorph ‘G’ input to better algn those “X” shapes? (59.7 KB)

Wow! you guys are pros. Thank you, I’ve spent a lot of time trying to troubleshoot this on my own.