Brep Bug exposed with boolean Intersection

Grasshopper
1

It’s disconcerting to use the Intersection or Difference tool and get something that’s definitely not an Intersection or Difference.

The sample file has two sets of Breps. One works, one doesn’t. The bad Brep was simply made with a different number of loft curves.

I’ve included data internalized clusters used to make the object.
Strangely, the internalized definition fails differently than the internalized brep. But it still fails, as you can see the difference tool leaves the original object as is in the top definition.

brepBug.gh (56.9 KB)

2

Hi,

if you bake your shape you get a rendering error:

prb-1

Usually this is because of creating bad conditions for intersections. If you have twisted surfaces and you intersect them, this can then lead to tiny self-intersecting boundaries or just bad intersection curves in general.This causes more and more problems. Always make sure Iso-Curves are planar from one direction seen. At least as planar as possible, this will prevent twisted surfaces and so intersection problems:
prb-2
prb-3

3

Interesting. Thanks for the detailed response. I’m not getting any rendering errors when I bake either the normal or problem brep. Rhino also seems to consider it a valid closed object

image
image1003×459 35 KB

Is there a special place to look for these rendering errors?

4

Just if you enable shaded rendering. Are some of these surfaces created outside of Rhino? Then it could also be that the normals are somehow messed up by having a weird NURBS parameterization. The rendering issue is that whats inside and whats outside is messed up as you can see in picture 1. Usually brep normals should point outwards. If this is messed, I could also imagine that the boolean operation fails because its messes up whats “inside” and whats “outside”. But this is also the cause of bad trimming boundaries, if you trim twisted or unclean and heavy surfaces. But again, if you clean up your shape, then this should disappear.

6

Just if you enable shaded rendering.

Ahh, I see what you are talking about now. Yes, it looks like “Ghosted” mode when “Shade” mode is chosen. Thanks for pointing that out.

Are some of these surfaces created outside of Rhino?

Is Grasshopper considered inside or outside of Rhino? It’s 100% parametrically generated in Grasshopper. Then Baked into Rhino workspace, if you wish.

Then it could also be that the normals are somehow messed up

This is a great check to be aware of. Thanks. The normals appear to be inward. I’m surprised that Rhino doesn’t mention or flag anything when reporting that a solid is a “valid closed polysurface” if the normals are pointing inward.

But this is also the cause of bad trimming boundaries, if you trim twisted or unclean and heavy surfaces.

This is made with pretty clean surfaces. There is one planar trim and a cap surface generated with those same trim curves. That should be a pretty clean fit. True, the constructions curves used to loft the surfaces are not planar. That’s usually not an issue. Especially since the end NURBS points used to create all of the curves are very cleanly organized and planar with respect to each other, they only progress in a straight line or along an arc for predictable lofting. Also, adjoining surface edges are built from the same curve.

Thinking about it more deeply, however, I can imagine that the loft component may be causing the issue. I’m guessing that the loft component connects end points by an interpolation algorithm that must have discrepancies when compared to the simple arc that the end points were generated from. Even thought all of the NURBS points for the profile curves are generated from perfect arcs and straight lines, if U is the loft direction and V is the profile curve direction, there’s no guarantee that Loft will reconstruct the U direction surface edges the way we hope.

All of my curved surfaces here were build with the Loft component. So now I’m even more surprised that Grasshopper is reporting this Brep as “Closed”

Grasshopper should be catching the gaps between the composite surfaces! It always has in the past for me. I’ve grown to trust when an object is classified as a “Closed” Breb.

I have decided to ditch the Loft component for this geometry with the above insight. Surprisingly, the Sweep 2 Rails component created a much messier, rippled surface. Maybe the edges are more reliable but ripples aren’t worth it. I ended up having success with the Network Surface component. I have more confidence in all surface edges. The resulting surface is smooth, and the my original issue is resolved.

However, it remains weird that

  1. Grasshopper fails to detect that this may be an open Brep with gaps at the seams or something else weird like inside or inconsistent surface normals.

Anyway, thanks for your response.

7

Yeah, of course this is subjective. I consider s-shaped, twisted iso-curves as rather unnecessary unclean. You can even spot that twist on the shadow in shaded mode (see. pic2). (If you deconstruct the Brep, you’ll get correct shading.)
You can also see a missing continuity in direction of the corner blend. I know it’s hard to maintain continuity in Grasshopper, simply because you cannot (re-)match a surface or apply similar operations due to lack of tools. My point is just, if you pay a bit more attention to this, you likely get also rid of the problem.

A twisted surface may also cause the trimming curve to be very dense, which as a consequence is causing this bug. It could also be, if you create the Nurbs from scratch, that you messed UV directions up. I think you can create a surface in Rhino with left-handed frames. This might lead to this problem… Anyway, these are just a couple of observation I made and some guessing. It’s rather a rare bug, so its unlikely you get it that often…

1 Like