Am I just not ready for Rhino/Grasshopper?

I need a reality check from you, experienced Rhino and Grasshopper users.

I’ve been evaluating Rhino and Grasshopper off and on for a couple of months now. I’m very impressed overall. It has powerful yet accessible features that have been well factored.

I’m impressed with the mainline experience overall. BUT, and this is a huge but, Rhino5 has an absolutely massive bug right in the middle of the engine. I of course refer to the Boolean Problem. I’ve put the product down cussing 4 times already after realizing that I’d just lost 3 hours trying to figure out why something doesn’t work, only to realize that I’m up against yet another derivation of The Boolean Problem.

I’m written McNeel tech support about the issue. They’ve offered file-specific work-arounds in response. But these work-arounds don’t allow a solution that can be used resolve generalized characterizations of the bug in Grasshopper programs. Brian, the support tech I’ve dealt with on this problems goes on to say that I shouldn’t expect any significant fixes for this problem.

I’m shocked that major revision 5 of a seemingly mature product as Rhino is has such a gigantic, mainline bug in the very core of its engine. But even more surprising is Brian’s suggestion that perhaps I’m just not ready for a product like Rhino. He further suggests that I post, as I’m doing here, to see what other people think about this bug.

So what am I missing? Where do experienced Rhino/Grasshopper users find themselves on the continuum between this being a big hairy bug that should have been fixed long ago and my just not being ready for Rhino?

I’ll accept any input and consensus that prevails.

  • Bob

Hi Bob - as far as I can see, the example’s that you’ve provided to tech support, while one could say they should, in at least some cases, work, are not at all straightforward Boolean operations to figure out…


Then why do they fail? What makes them “not at all straightforward?”

Something I’m struck with in reading up on this big hairy Booleans bug in Rhino is how deeply the Rhino team has rationalized its existence. A union is a union, and has been since Descartes. Yet you and Brian suggest that it’s completely rational to expect users to manually tweak their designs when this multi-faceted bug shows up – or even for us to send you our designs so that you can do the tweaking for us. But it’s not always obvious to the user that the reason operations in their Rhino or Grasshopper documents are giving unexpected results is not due to “user error,” but rather The Boolean Problem. I’ve lost countless hours multiple times before realizing that I’d hit this bug yet again.

Well written software consists of layers of abstractions. At each level the complexities inherent to the level below are abstracted away and replaced with a set of services accessible through an interface. This remapping of the problem set is called encapsulation, and it occurs repeatedly in successive layers of a software system. Software must preserve encapsulation. It must present a simple, appropriate interface that hides the complexities of the implementation. Once a complexity has been encapsulated away at a certain abstraction level it must stay hidden — at that level and all subsequent levels above that. The great advantage for both developers and users of multi-level software systems is summed up with the technology mantra…

Minimum Visible Complexity

Once complexity has been abstracted away, both stakeholders are able to perform at a higher plane because they have a set of much more capable services at their disposal. Users can access services from any level visible to them, though developers may decide to hide certain layers. Some use cases call for the simplicity of a high level interface. Other situations call for access to the power and detail of a lower level interface. But encapsulation must always be preserved at the layer being used.

Rhino documentation will have you believe that it consists of a series of layers services that are aligned with the science of geometry. At a low level there are planes, points and lines. These constructs are brought together to create 2D geometric shapes like circles and polygons. These are brought together at the next layer to create 3D constructs. And at higher levels we find textures, lighting and so forth.

It’s one thing to enable users to access the endpoints of a circle at the axiomatic level. In this way the software is letting users in on the secret that circles are actually constructed from lines. But well written software must allow users to avoid secrets like that if they chose to use a higher level interface. Shielding users from these complexities is called “preserving encapsulation.” Preservation happens because the interface hides the implementation.

But Rhino doesn’t preserve encapsulation. Way, way up at the level of 3D booleans the users’ whole world falls apart. The manual says that a user can perform a boolean union of 2 solids. But all too often union of 2 solids fails. Why? Because their seams are too close? Seams? What seams? I have a solid here? Why do I care at this level that a solid consists of a series of surfaces? What’s going on here? I’m confused. Why aren’t things working when the math says it should???

McNeel needs to change the way it talks about this broken encapsulation that’s rampant throughout its software stack. It needs to stop making excuses and stop insinuating that it’s the users’ job to work around these bugs. McNeel needs to get serious about identifying these conditions in the code and adding code to handle these “special cases.” Because they’re only special cases in the abstraction layers below the level that the user is operating at. The user should never know the hoops the code jumps through to preserve the integrity of the interface.

Minimum Visible Complexity

What do others think?

  • Bob
1 Like

hmm well to point one thing out in advance is that circles are mathematically always divided into straight lines thats not a secret, but a well know lets call it in that case “wrong” solution :smiley: ok but obviously somebody seems pissed off here

so i am getting interested, you guys are talking about something which nobody can see. it may sound rude but please show us some example… that booleans not always work due to the complexicty of nurbs is understandable but whatever please anyone knowing about that show us what you are talking about.


Truly, I’m not pissed off. I’m the new kid on the block. I think Rhino, and Grasshopper even more so, are awesome. If I seem didactic above it’s because it’s my sense that if this bug is to be resolved the effort must begin with a shift in how the people at McNeel that I’ve spoken to so far are looking at whose problem it is. I dove into my treatise on abstraction and encapsulation because I don’t believe The Boolean Problems’ continued existence can be justified by saying that Rhino users should be expected to rotate seams or because their designs aren’t at all straightforward. No, to my mind, this is a major set of bugs at the very heart of their graphics engine.

Or I’m completely off base, and if that’s the case I would really appreciate it if experienced Rhine/GH users just explain that to me. I really am open to either outcome.

One discussion that I initiated that deals with this bug is here.

Thanks for any input.

  • Bob

As I said in your other post when I use Boolean I almost always get results. You stated your new to Rhino, that said you need to play around with lesser drawings from scratch so you can get used to doing something like this.

All my best … Danny

no, they actually are circles in rhino… not a collection of straight line segments.

(or maybe i’m misunderstanding you?)

I’m also new to Rhino. And I think you are both right and wrong. You are right about encapsulation, but what makes things a little more tricky is that Rhino is also a NURBS tool, which offers Solids, which can be made from those same surfaces. This is where the mere Solids perspective perhaps isn’t regarding all aspects that makes sense.

I like your take on user encapsulation though, and relevant priorities. Perhaps more can be done about The Boolean Problem, but at the end of the day perhaps there must remain glitches due to the surface modelling aspect.

What absolutely can be done though, is something half inbetween: Many tweaks must re,main accessible, but when a Boolean operation fails the software must give better response. Like, not allowing to click an object which per definition is NOT a solid. For a start. Second, when an operation fails, a message with a detailed analysis should be shown, pointing out which object(s) are failing, and elaborate hints about how to fix the problem(s).

I’m a newbie myself, and I would appreciate if Rhino would be simpler to both learn and use. If the software gave more hints it would be easier to learn, and thus easier to use.

// Rolf

i use the boolean tools all the time… one of my most used methods. and they always work in the way i’m using them.
(and i mean every single time)

that said, the file from Bob’s link in the post above yours isn’t something i’d say is user error and the surfaces, from a user pov, seem like they should intersect with no problems…

so, the tools work well and reliably in the cases many of us use them in… but if something like the example file is failing to intersect, i don’t necessarily agree with the idea that Bob should try more simple models… i wouldn’t really say his technique is off in this instance.

A computer program is more than math.
It could better be compared with - for example - econometrics. Both use math as a tool to describe a model. In the case of econometrics the model is updated when experience shows that the current model is not refined enough to explain all cases. In the case of Rhino, the developer is given models as concrete examples of what the code should be able to solve. That will never ever be all thinkable cases. The Rhino process is that a user provides a model that shows a problem, an issue is filed, and - when the correct resource-severity combination is reached - the issue is resolved.

Also, Rhino was not written as a solids modeler. The boolean functions are nothing more than an automation of the intersect-trim-split-join workflow that was intended at the onset. Lazy users demanded this process to be automated and got what they asked for - at the same time losing valuable feedback that came with the manual process. Rhino 6 attempts to return some of that feedback to the user.

Additionally, Rhino initially went out of its way to allow the user to make whatever the user deemed necessary. To a certain degree this is still true. In some cases this means creating geometry that on its own might be fine but when used as input for other functions that the user at a later stage wants to inflict upon it will cause the model to fail. Program error? User error? There’s a case to be made for both.

Why? Why tie the hands of users that understand how a boolean in Rhino works?


It should have read “NOT a valid Solid” (the naked edges thing). But then again, Boolean takes also open surfaces ( = naked edges), so OK, you’re right. Warning then? Or, separate commands for solids (with corresponding warnings if not valid) ?

In any case, no matter the rationale for providing lots of complexity and tweaks on user demand, important is also making sure that the learning curve isn’t too steep. Learning faster = better usability, less complaints. :slight_smile:

// Rolf

There’s always SketchUp…
(as they say: “3D modeling for everyone”)


Hi Bob
I can understand your frustration. I’m a Rhino user on a day to day basis for the last 7 years or so and I can tell You I’m still learning. I remember times when I was so frustrated with Boolean operations like “why the hell when I do Boolean difference I get union” an so on…Obviously my surface was flipped. Now I know how to deal with those “bugs” and I know if I want to Boolean objects which are planar or overlapping I have to scale one by a fraction. You might call it “absolutely massive bug right in the middle of the engine” but I call it SUMO…Rhino is such a powerful tool and I can’t imagine using any other software for my needs…all the plugins, grasshopper and other goodies overweight some bugs which you simply need to learn how to deal with or find another software. Nothing’s perfect. Good luck :slight_smile:

In my opinion fillets are much bigger Rhino issue :wink:


Well one of this things that becomes apparent in this conversation as well as the other current thread on a similar subject is that there a lot of opinions on how Rhino works and should be used, as well as some definite misconceptions. There are those that say “always do this!” and others that will say exactly the opposite, “never do that!”…

What is true is that Rhino is not necessarily designed with a lot of “safeguards” (limitations) that might be built into a solid modeler to keep the users from having open objects. This is because Rhino does not favor “solid” modeling over “surface” modeling; instead it favors the ultimate flexibility in creating any kind of object, at the expense of creating a number of “challenges” for users who are not familiar with how it works. jim called Rhino a “minefield” in the other thread, and while I wouldn’t go that far, there are definitely some traps for the unsuspecting…

As far as Boolean operations go, it is vitally to important to understand how they work - some info is on this page as posted above. As others have said, they are nothing more than automations of Intersect/Split/DecideWhatToDelete/JoinTheRest. As it doesn’t show you the manual parts in between, it won’t show you where it’s failing, and thus you won’t know how to fix what’s wrong.

That’s why you do need to know the manual process behind Booleans, so that you can get in there and fix things if necessary. There are people who say “never use Boolean operations in Rhino”. I do not personally favor this blanket approach to things. Many experienced users run Boolean operations every day without problems. But you do need to know how to react when they go wrong, otherwise you will be infinitely frustrated.



Exactly! Booleans (as well as “Intersect/Split/DecideWhatToDelete/JoinTheRest”, of course) are safe to use if you know what you´re doing. There´s nothing mystical about booleans…


Hi Bob

As you may already have discovered from the other replies … :wink: … people that use Rhino generally have found a way to make Rhino do what they need, then they happily enjoy Rhino’s great flexibility. Fine. :slight_smile:

I guess other people do not use Rhino because they were not able to do that …

I don’t think Rhino is good for any kind of work and workflow and needs.
Also I don’t think Rhino is easy to use, particularly it’s definitely not easy IMO using most of its power.
Any Rhino user will tell you that he/she is learning every day, year after year.

Then my humble answer might be:
If you find a way to match Rhino and the work you need in some way, that is exploring Rhino possibilities, plug-ins, maybe choosing some slightly different workflow, etc. , OK, keep on using Rhino.
Otherwise … you might be luckier with other programs

One last thing.
About the Boolean Problem:
My opinion is that Rhino’s geometry engine has its limitations, that may show themselves in booleans or other operations. Personally I hate most :wink: when they affect filleting and trimming … ah yes, and obviously failed closed joins.

But again, the challenge is finding some (often intricate) way to get your work done without beeing stopped by those limitations …
Or else give up and look elsewhere

Good luck ! :slight_smile:

1 Like

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 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.


In his reply to a companion posting in the Grasshopper discussions, 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
1 Like

Hi Bob,

Apart from other items and the Boolean Issue (yes, the booleans in Rhino are not perfect but far from bad) I don’t think the above conclusion is right. Rhino does have a fairly steep learning curve but well worth investing time in it. I think what was said is the software is deep and full of functionalities and specific options and settings to cater for various workflows and industries, allowing for a lot of flexibility, which is one of the best parts about Rhino. Having said that, as a 15+ years Rhino user I do still learn and discover things - not workarounds for problems, just new or smarter ways of doing things.

my 2c




Wow, 15 years.

I’m curious about whether you are a heavy Grasshopper developer. I ask because it’s difficult to impossible to take advantage of all these Rhino work-arounds that I’m sure you’ve learned over the years if you’re developing in GH. Everything possible in GH could be done directly in Rhino, but the justification for investing in the development of a GH algorithm is that you end up with a generalized solution that has broad applicability.

While you might not like having to dance around Rhino’s shortcomings, even though you know how, GH users face greater challenges using today’s Rhino – and might benefit more if Rhino were implemented with greater rigor.

Thanks for the 2c.

  • Bob
1 Like

But you can’t “react” when the Booleans are part of a Grasshopper algorithm.

  • Bob