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

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.


  • Bob