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 problem.gh (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.
Brep_SolidIntersection_V1.gh (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 Problme.gh (11.7 KB)
Boolean Intersection issue.3dm (13.6 MB)
Peter
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!!)
Boolean_Intersection_internalized.gh (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ā¦
Boolean_Intersection_2018Feb20a.gh (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?
Boolean_Intersection_2018Feb20b.gh (59.7 KB)
Wow! you guys are pros. Thank you, Iāve spent a lot of time trying to troubleshoot this on my own.