Need a workaround when brep | brep intersect returns an incomplete set of curves

Rhino Developer
, , , ,
1

I’m using Rhino (and Grasshopper) to generate some geometry. However some operations in that process are apparently running into a known problem area related to the intersection of two surfaces. Brian in tech support has given me a workaround that involves ever so slightly resizing one of the surfaces temporarily so that the intersection and subsequent split will succeed. While the workaround he’s suggested is sufficient to allow to me get the results I need in the test case that I’ve submitted, that case is just one possible scenario. My intention in using GH is to create tools that allow me to “sling geometry” around to allow various shapes to emerge from the ether. In response to his help in finding a generalized workaround, he suggested that I post in this discussion describing the limitation in the surface intersection operation in the hopes that somebody might know how to program around the bug.

One of the GH-based tools I’m playing with is one that allows me to position various synthesized surfaces so that they interact spatially. When an interesting interaction between the two surfaces is found the tool can create a single surface having the texture of the original input surfaces. (Visualize two waves interacting on the surface of a body of water.)

The algorithm I intended to use to produce a single surface from the two inputs was to use the intersection operation to generate the series of curves where the surfaces meet. I would then apply these cutting curves to a split operation on each input surface. I would programmatically cull the set of brep’s from the split operations, removing all those that aren’t on the face of the target surface. Finally, I would join all the remaining prep’s into a synthesized surface that reflects the interactions of the originals.

The bug that I’m encountering relates to the set of curves generated by the brep intersection operation being incomplete. These flawed curves can’t be used by the next step in my GH script to properly split the input surfaces so that their “backs” can be culled.

To demonstrate the problem, I’ve enclosed a 3dm file that contains 2 circular, wavy surfaces (see the first 2 screenshots) positioned with a common center point so that they interlace to form a diamond-like outer texture. (See the third screenshot.) The base geometry of these input surfaces are such that the interlaced set of surfaces have internal closed “pockets” on the back. (See the fourth screenshot.) In order to create a single surface that reflects the outward-facing geometry, the tool must remove these pockets from the inside wall of the combined geometry.

As shown in the fourth screenshot, only a small portion of the network of curves from the intersect operation are the “checkerboard” pattern I expected. The rest are simply fragments of the expected curves. Brian says that this is because the intersect operation is unsure about where the two surfaces intersect. So it simply punts and adds nothing to the curve network. His workaround involves ever so slightly rescaling one of the surfaces temporarily, performing the intersection and the split, then rescaling back to the original size.

Brian demurred when asked if this rescaling can be used as a generalized workaround. Remembering that my intention is to develop a tool that I and my collaborators can use to discover interesting textures, the need to hand tweak every possible interlacing combination fatally defeats the usefulness of the tool.

I’m writing to ask whether anybody in this discussion can suggest a generalized solution to this Rhino limitation. I’ve enclosed both the 3dm file, with the 2 surfaces baked into the 3dm. I’d appreciate any input you might have on what I’m doing wrong or a workaround should this in fact be a bug.

Thanks for any help,

  • Bob

16.08.27 Surface1.3dm (995.0 KB)

70aa3cda4c7a1baa2e14025422205c5a44681c40.jpg1207×1212 241 KB

2

Hi Bob,

I’m getting errors reading your file, which seems to only contain two curves and a point. If this isn’t correct, you might want to try to re-upload.

Thanks,

– Dale

3

Thanks for the heads up Dale. I think I got bit by auto-save. I’ve re-uploaded the 3dm.

  • Bob
4

Though this discussion never really took off, the challenge I’ve described here was fully explored and resolved in a conversation in the Grasshopper forums. There were two outcomes that we arrived at that I’ll convey briefly here…

Intersect Shouldn’t Punt

The unexpected behavior I’ve been having with Rhino, and by extension Grasshopper, is that the current implementation of the Rhino Intersect command is generating an incomplete network of curves when given 2 surfaces having regions that are (almost) coincident. When Intersect determines that there’s no single curve to represent the intersection in those areas, there is in fact an area of intersection, Intersect currently doesn’t generate any curve to represent that portion of the intersection. This decision to “punt” in these situations renders the generated results to not be useful for subsequent steps, such as splitting one or both of the input surfaces.

Through the tech support team, I’ve conveyed the observation to developers that Intersect should generate any non-kinky curve(s) through a region of intersection that connects with all other intersection curves adjacent to the region. Any valid curve is far more useful than no curve through these regions.

Mill Rather Than Construct

After some discussion and exploration, it was suggested that I create a solid having the desired surface texture by “milling” the bounding box of the interlaced surfaces, rather than fighting with R/GH in feeble attempts to construct a closed volume from a set of surfaces. Milling is a much more straightforward method to generate the desired shapes that doesn’t involve those areas of Rhino where it’s currently “getting confused” (read: Intersect). As an added bonus, the full milling process can be implemented using standard Grasshopper components. My sample GH document for doing so can be found here.

  • Bob

MilledTexturePic2.jpg1067×863 180 KB

1 Like
5

Hi Bob,

Sorry for dropping the ball on these.

These types of intersections (non-manifold with areas that are nearly planar or overlapping) are difficult to solve. I’ve added an bug item for this issue that you can track here:

https://mcneel.myjetbrains.com/youtrack/issue/RH-35818

– Dale

6

Thanks, Dale. No doubt you’ve read my posting from earlier today that relates to the severity of “The Booleans Problem.” As shown in the design referred to above, my work involves many 3D boolean operations. While I can appreciate the difficulty some conditions that arise, the situations where the bug shows up AREN’T special cases. They’re situations that arise every day in the real world. Input conditions like matching seams and regions of intersection are part and parcel of people’s design intent. A union is a union, and has been since Descartes. Not to whine, but I’m surprised that this set of bugs has not been assigned a higher priority.

  • Bob
7

Hi Bob,

The Boolean operations fail due to the condition I describe above, which is a surface-surface intersection issue.

– Dale

8

Bob, just out of curiosity, do you know of software that will successfully Boolean these objects?

-Pascal

9

I’ve found 3 apps able to produce the results that I need…

Autodesk’s MeshMixer – though, as the name implies, the results it produced are a mesh that precludes further evolution of my design as a solid.

Simplify3D – which the extremely popular and powerful 3D slicer. But, again, S3D reduces my model down from a solid to a mesh.

Rhino/Grasshopper – yes, Rhino. As I said above, I was able to rework my Grasshopper algorithm to “carve the surface from a solid box.” However, the resulting Carve algorithm is not generally applicable.

As I’ve said, it’s difficult to impossible to take advantage of all the Rhino work-arounds that you’d like me to learn because I develop primarily in Grasshopper. Everything possible in GH could be done directly in Rhino, but the justification for investing in the development of a GH algorithm is that I end up with a generalized solution that has broad applicability.

  • Bob
10

Hi Bob - so, that being a ‘no’, I wonder if maybe there is a different approach that might serve you just as well - for example, making a pattern in the flat, possibly from a heightfield, and flowing it to a simple® revolved surface. I don’t know if that is it, but maybe something along those lines.

-Pascal

1 Like
11

What??? That was a yes. Three yes’s, in fact.

Truly, Pascal, I appreciate any and all input you might have on this sample characterization. But I’m trying to surface a much larger problem that I and almost every other Rhino and Grasshopper user have been struggling with for years. And I’m not just whining, but rather trying to have a constructive conversation about how we might overcome these longstanding challenges.

Is that a conversation that McNeel can engage with us in?

  • Bob
12

Hi Bob,

I believe @pascal was wondering if you know of software that will successfully Boolean these objects as NURBS objects?

I have tried performing Booleans, with your model, with a couple of other popular applications that are capable of handling NURBS geometry. None of them could complete the operation successfully.

We engage with our customers on a daily basis. Is there something more you are expecting us to do in this case? In other cases?

I’ve reported your issue (reference my prior post above) - thank you for providing the sample. Hopefully this issue can be resolved in a future release.

– Dale

13

Thanks for jumping in Dale.

I really appreciate your capturing the suggestion on how to improve the results of the Intersect command so that the network of curves is complete – even when the intersection results in an area and not just a curve. That’s what you’ve forwarded to the developers, right? A consistently usable set of results from Intersect will increase the opportunity for Booleans more generally to succeed without manual tweaking.

It was my sense that Pascal’s question in this discussion was related to the discussion about The Boolean Problem that’s still ongoing here. If you’ve been following that discussion, then you know that the suggestion has been made that users might benefit if Rhino were more rigorous about preserving encapsulation. For example, a solid should be a consistent and reliable enough user-visible construct that operations on solids work without tweaks like having to rotate seams, and without worries about whether an intersection of solids results in an area of intersection or simply a curve. The same should be true for surfaces, curves, and all other Rhino constructs.

I’m fairly new to Rhino – just less than 3 months. But I’ve searched through the forums and found 100’s of postings from other users who have struggling with these ‘encapsulation leaks’ for years. I’m also hearing today from very experienced users, some of whom are saying that they don’t feel that they’ll ever really know exactly how do something new in Rhino, because their designs often need to be manually tweaked in order to work around these problems – in booleans, in fillets, in trims. As a user who’s been working primarily in Grasshopper, I’m much less able to tweak my algorithm to work around a bug and still end up with a solution with broad applicability. We GH user’s struggle even more as a result.

Maybe I’m still just too far outside the box, but I don’t think that the the root of these problems has much to do with my limited experience with Rhino, as Brian and Pascal have suggested to me and others with similar complaints. I’ve been working with 3D systems since 2006. When it comes right down to it, sometimes Rhino works as advertised, and sometimes it doesn’t.

It’s my sense that Rhino can evolve to reduce the number of times that it doesn’t produce valid results. I think it can produce more detailed and informative error messages when it does fails – whether because of user or software error. I think that users’ productivity can be significantly increased, and that Grasshopper developers can be better able to write algorithms using booleans, fillets and trims that produce valid results more often than is currently possible.

I’d appreciate your being open, and open-minded, to have can-do conversations about how to fix these problems that we’re struggling with – on a practical, nuts-and-bolts level like you’ve done in this discussion, and on architectural issues like the ones raised here.

I share everbody’s enthusiasm for Rhino and Grasshopper. Yet the frustration level needs to come down over time and the productivity level brought up. I’d appreciate your help.

Thanks,

  • Bob
14

First of all, Dale -IS- the developer (or at least one of them).
Secondly, you are reading too much into RH-35818. When the input surfaces are correct, Rhino should produce correct intersection curves. You have supplied a sample in which that is not the case and as such the developers will look into the code to see if that can be resolved - for that specific case. Perhaps that will also solve issues in other specific cases.

That’s pretty much everybody’s sense, yes. And Rhino does evolve like that pretty much every single day. You, the user, can help that gradual process by providing feedback with specific cases where valid results are not produced.

Management of expectations should help to reduce frustration. Do not expect giant leaps and revolutions. Think babysteps. One a day…

1 Like