Am I just not ready for Rhino/Grasshopper?

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?

5 Likes

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”)

2 Likes

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:
Lukasz

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

3 Likes

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.

–Mitch

6 Likes

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…

Philip

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.

Wow.

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

–jarek

5 Likes

Jarek,

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

Bob,

In my regular work I don’t use GH much. I know it well and It is a very powerful toolset but our projects are usually one-off, quick turnarounds so there is no time to build complex definitions.

I definitely can see how Boolean problems can be more difficult to deal with from GH-user standpoint when one can’t apply some fixes and tweaks via direct manipulation of geometry.

–jarek

By this do you mean the you’re an architect who’s been using CAD software for 40 years, or that you’ve been designing software for 40 years?

I’ve been doing 3D work for about 10 years. But look me up on LinkedIn if you want details. I was just saying that, though I’m fairly new to Rhino, this isn’t my first rodeo.

1 Like

Thought you sounded more like a computer pro than a designer. At least you went to a good school. Go Blue! Did you know Fred Ball before that?

This is why we long time rhino users prefer it over alternatives. However, with all software, there are limitations. I use SolidWorks for somethings (mechanical style items) and Rhino for others (freeform surfaces). I haven’t gotten around to merging the two. There’s a bit of overlap, but really it is about using the right tool for the job. The benefit with Rhino is that it can model just about anything.

The beauty and frustration (at times) of Rhino is it will mostly give you some form of output even if you’re asking it to do something which isn’t really doable. You can work with Solidworks or Spaceclaim within the parameters of typical 3D modelling for manufacturing and they will calculate draft angles, sheet metal development and probably fillet things in a more economical and Fisher-Price like one button approach but they are limited too. Where other high end programs may just tell you it can’t perform that task and leave you hanging, it limits the user’s ability to tinker with surfaces - to rebuild and remodel things and enable them to create exactly what it is they desire. Without forcing them to change their approach and end up delivering something that works within the parameters of the program but not the parameters of the client’s vision.

I’ve been using Rhino since about 2006 and AutoCAD and a whole host of other programs too. Some of which were pre WYSIWYG and I’ve been involved in some complex projects for a host of end users over the years. My approach has been to learn something when it rears its head and not sit down with the manual and go through every aspect of the program. I still ask dumb questions like a noob and I’m always learning.

I forget the name of my AutoCAD tutor back in college in the early 90’s but his motto has stuck with me ‘if it seems like there should be an easier way of doing it, there usually is’.

Rhino can’t be all things to all people, if there are issues then it may be your approach? If it’s not your approach, then maybe there is another program which performs the operations that you need in a way in which you’re used to?

One week I might be designing a gold watch, the next it could be an 18ft mushroom for a stage show, the next it could be POS for tea or a 9 metre complex sculpture to 5 axis CNC a positive to be made from stainless steel and carbon fibre. I get frustrated sometimes but 9/10 times it’s my fault that something doesn’t work. I’ve learned to accept the limitations of the program but it’s always evolving and we’re part of a community that tests, debates, votes and has a say in the development of the program – IMHO that’s priceless.

Andy

6 Likes

Hi Bob,

The matter we are dealing with is software not able to solve certain mathematical problems. If all booleans in Rhino would work, most -if not all- of this discussion would not be necessary.

However as a long time Rhino user it’s my understanding that there are and always will be practical limits in creating flawless algorithms as @dale has pointed out.

Geometry can be of such nature that correct intersections are (almost) impossible to calculate within the given set of variables. That’s why (I believe) @pascal asked to find if other software was able to produce proper boolean results. Note that these limitations also apply to the process of finding and reporting the cause of a failure.

So we are facing software that has its limits, just like any software. Developers have to choose how to handle the limitations.

I fail to understand your suggested steps towards a solution:

I’d say the abstraction is already in place, be it not as you propose:

  • Rhino can define and work with NURBS surfaces,
  • NURBS surfaces can be trimmed to form Breps.
  • Breps can be joined to form composite-Breps.
  • composite-Breps ( poly-surfaces ) can form closed volumetric boundaries, but do not have to.

The moment you decide that Rhino will need to enforce geometry to always be closed solids, you end up with limiting the options for users to manipulate this geometry. My understanding is that major solid modelers are all working with Breps under the hood and go through hoops to maintain solids, at the cost of properly defined geometry and user freedom.

In the end anything of the above does not solve issues regarding failing intersections.

I understand your frustration however and the feeling there is a need for a different approach,
Yet my take is that it comes with the freedom given by Rhino and Grasshopper to create and manipulate geometry at a deep level. It’s both liberating and frustrating because we are not kept away from failing algorithms but instead are presented the best options available and are free to deal with it ourselves.

Maybe you can elaborate some more on how the software should be organized different to optimize the issues you find as I as a long time user am anything but fresh and objective.

Thanks for taking the time and effort to contribute in this discussion and bringing issue like these up, it’s what made and makes this community and software so valuable.
-Willem

3 Likes

You are correct there - all of these issues relate back to the same thing - Rhino’s NURBS/Brep geometry engine and in particular its intersector function. This has nothing to do with encapsulation or any of the other things you mentioned above, but simply to do with the complex math of figuring out the intersections between any arbitrary set of surfaces you can imagine. And I mean arbitrary - Rhino allows you to make just about any curve or surface shape you want, even if it’s completely twisted and bad. Rhino expects the user to be aware of what they are inputting and doesn’t “pass judgement” on the quality of the geometry for the most part.

If there is a clear-cut intersection between parts, Rhino generally does extremely well. However, in cases where there are concurrent surfaces or near-tangent overlaps, the intersection gets hard to calculate, especially in the world of fuzzy floating point math. In this area there end up being a lot of “special cases” - the list of ones that are solvable gets longer all the time, but there are also a large number that have not yet been addressed or are difficult to do.

The fact that Rhino has a “home-grown” geometry engine as opposed to a licensed kernel such as ACIS or Parasolid that most other software use has both advantages and disadvantages. The advantages are complete control over what happens and the ability to open up the core functionality to things like Grasshopper, scripts and other programmed add-ins - as well as lower cost to the end user. The disadvantage is that developing and maintaining your own geometry engine uses some of the limited resources available in a small company - resources that have to cover the development of entire program, not just the geometry engine.

I’m all for the improvements in the geometry engine as far as intersections, trimming, joining and filleting go. But the list of stuff people ask for goes far beyond that. You found a lot of posts relating to Booleans for example, go have a look for how many have to do with rendering and display or user interface…

Rhino is constantly evolving, and every new version brings thousands of under the hood improvements that most people don’t realize are even there - because things just magically work. But if you’re only doing mechanical design, you may find that Rhino isn’t the best at doing what you want to do, and that you’d rather work with a more constrained modeler that may have more reliable fillets and Boolean ops - at the expense of not letting you do some types of stuff - stuff which you may not want to do anyway. That’s up to you to decide. You can please all of the people some of the time and some of the people all of the time, but you cannot please all of the people all of the time.

–Mitch

5 Likes