Am I just not ready for Rhino/Grasshopper?

Replies to This Discussion

Permalink Reply by Martin Siegrist on October 3, 2016 at 3:18pm

So what exactly was your boolean problem?

Permalink Reply by neobobkrause on October 3, 2016 at 4:29pm

Maybe it's the nature of my work, but I seem to be hitting this set of bugs that McNeel refers to as The Boolean Problem almost daily. One characterization that was given a thorough discussion in this forum last month was this one. I was able to accomplish my goals after some very helpful input, but it required that I entirely rewrite my GH algorithm. Unfortunately, this workaround doesn't provide a general solution for all cases.

Thanks for any input.

- Bob

Permalink Reply by Andrew Heumann on October 3, 2016 at 10:10pm

IDK... once you learn what *not* to do, it's usually pretty simple to work in such a way that you never encounter "the boolean problem." Sure, there are probably solid modeling engines out there that handle the edge cases of boolean operations in a more robust manner - but I doubt any of them are as fluid or easy as Rhino, and I definitely doubt that they would have an interface like Grasshopper. I've always had success with boolean operations as long as I avoid coincident vertices/edges/faces and stay mindful of modeling tolerances. I also pay close attention to making sure my geometry is "good" in the first place - e.g. being careful with the control point distribution of my curves and surfaces before trying to do operations that create further surfaces/polysurfaces. This may *seem* like a lot to keep in your head but it quickly becomes second nature.

I'm definitely not saying Rhino/GH is perfect - but I don't know of another product as powerful and as versatile (bearing in mind my industry is architecture primarily, folks in product / industrial / other industries may have other options available to them that I do not).

Permalink Reply by Paul N Jeffries on October 4, 2016 at 6:11am

One thing that's important to understand when using Rhino for this kind of thing is that Rhino does not have a particularly meaningful conception of a 'solid object' - solids are defined simply as a collection of (infinitely thin) NURBS surfaces joined together with no gaps between.  That's part of the reason for the problems with booleans in Rhino, but it also means that you don't really need boolean operations since you can do everything by exploding the polysurface and using the Intersect/Trim/Split commands on the individual surfaces to build up the boundary surfaces you want, then rejoin into a solid afterwards.

This can be a time-consuming process and is difficult to do parametrically, but running through it manually a few times will help you to understand where exactly the problems crop up and how you can build geometry in the first place to give the boolean operations the best chance to work.

Permalink Reply by neobobkrause on October 4, 2016 at 2:49pm

Thank you to all who've added input to this discussion so far. This is the discussion I’d hoped to generate. Having read through everybody’s replies, I’d like to address some of the aggregate perspectives that have been shared so far.

Intersect Shouldn't Punt When Encountering Areas of Intersection

Several posts talk about how Booleans are really just shortcut implementations of the Intersect/Trim/Split/Join (ITSJ) design pattern. Agreed. I realized this when trying to understand and resolve my first Boolean related problem. So when I broken down my characterization to the 4 component steps, I found is that it was the Intersect operation that was generating an erroneous (read: incomplete) set of intersection curves. I posted my findings along with a possible solution in an email to McNeel tech support and in this Rhino discussion an edited version of which I’ve quoted again below. But the only response I received from McNeel was that I shouldn't expect any changes in the product that improves Booleans.

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 able to represent the intersection in those areas, but rather an area of intersection, Intersect erroneously doesn't generate any curve to represent that portion of the intersection — which is mathematically incorrect. This decision to "punt" in these situations renders the generated results to not be useful for subsequent steps of the ITSJ design pattern. Rather than not including these areas of intersection in the network of curves, Intersect should generate any non-kinky, non-looping 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 — and mathematically correct — than no curve through these regions.

Informative and Detailed Error Reporting Will Save Users’ Time

A number of users feel as I do that the error information available when an operation fails is insufficient.

The Rhino Learning Curve Is Fractally Steep

While some responses have suggested that I’m just too new to Rhino, a number of long-time Rhino users have said that they are continually “learning” the product's idiosyncrasies, and expect that they will never really know what the product will do every time. What they’ve learned from their years of experience is how to hack their designs to work around Rhino’s quirks.

I conclude from these stories that, sure, I’m green, but that I, all of us, are destine to be forever “green” because the current development methodology results in a product that can never really be understood.

Wow.

In his reply above @Paul N Jeffies said…

One thing that's important to understand when using Rhino for this kind of thing is that Rhino does not have a particularly meaningful conception of a 'solid object' - solids are defined simply as a collection of (infinitely thin) NURBS surfaces joined together with no gaps between. That's part of the reason for the problems with booleans in Rhino, but it also means that you don't really need boolean operations since you can do everything by exploding the polysurface and using the Intersect/Trim/Split commands on the individual surfaces to build up the boundary surfaces you want, then rejoin into a solid afterwards.

As a software architect with ~40 years of tech experience, I would again suggest that the root cause of the product's unknowability is the lack of rigor so far exhibited in defining the layers of abstraction. If proper rigor were applied, then, from a user’s perspective, a solid really would be a solid. The proper way to reduce a solid to a set of adjacent surfaces would be to use a function like ExplodeSolid, and to get a set of curves from a surface we would have to use ExplodeSurface, and so on. So rigor doesn’t prohibit users from pulling back the curtain, but rather empowers the core development team to enforce encapsulation at the current layer of abstraction — whether point, curve, surface, solid, or whatever.

The Solution Begins With Changing The Conversation

With all this said, I don’t believe that Rhino is fatally flawed or impossible to fix. I also don't believe that the resulting loss of productivity is the users' fault. I do believe though that the first step is for all, McNeel and users, to name the condition, raise this as a high priority, work collaboratively to define a corrected abstraction stack, and add appropriate rigor to the implementation of the next major release.

About a month ago I spent about 1/2 hour searching through the Rhino discussions for topics related to The Boolean Problem. I found literally 100's of posting, with many noops like I am now saying they were giving up and going to another tool because Rhino’s learning curve was too steep. Yes, filleting and trimming are two other big Rhino problems that I believe have similar roots. Yet I wonder whether these deep-seated challenges could, in fact, be overcome — by first changing the conversation.

I’d again ask what other, more experienced users think.

- Bob

Permalink Reply by Birk Binnard on October 4, 2016 at 11:15pm

As an individual self-taught GH/Rhino user I am a bit reluctant to post in this thread, but I have spent the last month trying to resolve this very issue. My situation is pretty simple: I'm trying to 3D print a bowl shape that is made by combining/merging a wiggly Loft surface that is first twisted in one direction and then in the opposite direction. I have no problem when there is just one Loft surface that is twisted in one direction, but when I try use GH to combine/merge the opposite twist surface I get a nice looking result, but it is impossible (at least so far by me) to get it Rhino to make a single closed object for exporting. (For 3D printing I have to export from Rhino in STL format.)

After reading the Boolean problem article posted above I agree with Tom Jankowski that the actually problem is a mathematical one. Apparently Rhino simply does not have the code necessary to turn such a complex multiple surface object into a single entity. So instead it exports something that is comprised of multiple parts, and due to roundoff and truncation errors the exported geometry simply cannot meet the stringent requirements for an error-free STL file.

I'm not clear on what the problems with the exported file really are, but they must be tricky ones because I have tried 3 different STL repair programs, and none of them can make the file printable. It is also not clear to me that any other 3D modeling/CAD program would do any better since, as Tom pointed out, the concept of merging/subtracting/intersecting complex 3D shapes is a daunting one. 

I know nothing about architecture, but for 3D printing I know that the only thing that matters is the geometry's outside shape. An architect in Holland used a program called Archicad to make a "skinned" version of one of my problem STL files; it apparently used just the outside surfaces to make a slightly smaller error-free STL file of my geometry.  I could have printed this file but I wanted to make some minor geometry changes before I did my print.

So maybe this skinning process needs to be further developed, although I expect this would be difficult to do since it is no doubt proprietary software.

FYI this thread shows the part and my discussions about it: https://craftunique.com/forums/view-thread/2208

Permalink Reply by Matt Gaydon on October 5, 2016 at 4:45am

Birk,

Just a note, if you export multiple parts your STL will be made of multiple parts and give you errors that need to be fixed it does not magically Boolean everything together for you into a single mesh. Some other software's may give the this option but i don't think its the default workflow. 

Here's Just some Simple Breps/ Meshes explain it not about how complex your model is 

Rhino Breps exported as STL

Errors in STL highlighted Magics

Rhino Meshes Exported As Stk

Errors in STL highlighted Magics

Rhino Single Closed Brep Exported as STL

Error Free Stl in Magics

If its not possible to make a SINGLE Closed Mesh or Closed Brep in Rhino to export these errors can be solved in software like Magics either though repair or Shrink wrapping the mesh parts. Note though Magics is not a cheap software .. a few £1000 i think. 

I don't have a 3d Builder here so can't test it in that software

Hope this clears things up a little. 

Matt

Attachments:

• STL PARTS EXPLAINED.3dm, 849 KB

Permalink Reply by martyn hogg on October 5, 2016 at 5:02am

I think many of us have gone down the Boolean route and got frustrated

Have a look at the Cocoon plugin and see if this can help you generate the shapes you want but in a different way.

It uses lines, curves, points and surfaces as input driving geometry to produce a thickened mesh output that will easily convert to an STL.

I think the Boolean trap catches so many because it is a basic principle of 3D modelling but it works best for regular geometry only really

Permalink Reply by Paul N Jeffries on October 5, 2016 at 3:35am

As a software architect with ~40 years of tech experience, I would again suggest that the root cause of the product's unknowability is the lack of rigor so far exhibited in defining the layers of abstraction. If proper rigor were applied, then, from a user’s perspective, a solid really would be a solid. The proper way to reduce a solid to a set of adjacent surfaces would be to use a function like ExplodeSolid, and to get a set of curves from a surface we would have to use ExplodeSurface, and so on. So rigor doesn’t prohibit users from pulling back the curtain, but rather empowers the core development team to enforce encapsulation at the current layer of abstraction — whether point, curve, surface, solid, or whatever.

I think the extra commands you are suggesting would be unnecessary and unhelpful - one of the nice things about 'Explode' is that it works on anything (be it polycurve, polysurface or mesh) and a new 'ExplodeSolid' variant would only reinforce the misconception that there is something fundamentally distinct about 'solid'/closed polysurfaces vs open ones.  I would perhaps suggest the opposite - that the categories of 'Solid' tools (many of which actually work fine on open polysurfaces as well) be renamed to simply 'Polysurface' or 'BRep' tools to make it clearer that 'solids' are merely special cases of polysurfaces rather than a distinct type of their own.  I don't think that the way Rhino actually encapsulates these geometry types is all that confusing, but the presentation makes it so by not matching the implementation.

Permalink Reply by David Rutten on October 5, 2016 at 2:32am

Here are my thoughts in no particular order:

• Yes Rhino has trouble with boolean operations, it's been getting better over time and we keep working on them, but it's still not perfect. Rhino6 is a lot better than Rhino5, but it still fails sometimes when one feels it ought to have worked.
• Rhino is not good at dealing with messy geometry (curves that go back on themselves, unnecessary multiple knots, edges that are further apart than the tolerance, ...). It tends not to create this kind of geometry, 9 times out of 10 it is imported, but that doesn't help you as a user.
• It is never the user's fault when the program doesn't work as expected. It's a bug. Whether or not it is easily fixed is not part of my definition of a bug.
• Sometimes, users can learn to detect, fix and circumvent problems. In this not-ideal world that is a sad reality.
• If Rhino cannot do reliably what you need to do, then clearly Rhino is not the program for you. This is not your fault, it is not even necessarily our fault; Rhino does not aim to be all things to all people. If however you do stick with Rhino we will try to fix the bugs that get in your way. In the case of really complicated stuff like Booleans and Make2D that process is slow and frustrating.