There’s always SketchUp…
(as they say: “3D modeling for everyone”)
There’s always SketchUp…
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
In my opinion fillets are much bigger Rhino issue
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…
As you may already have discovered from the other replies … … 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.
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 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 !
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.
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.
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.
But you can’t “react” when the Booleans are part of a Grasshopper algorithm.
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.
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.
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.
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.
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.
I think you are on the hunt for the perfect software. I wish this holy grail existed. I have been on this same hunt since I started using AutoCAD in 1987. In all the years I have been using various CAD and graphic design software all of them have some sort of quirky problem they can’t handle that drives one mad. Some programs handle certain processes better than others, so if Rhino is not capable of dealing with your models in a way that makes sense to you, or you find frustrating, you should move on. But don’t fool yourself into thinking that the program that handles your particular operation better than Rhino won’t have it’s own set of frustrations in some other area. It’s necessary to have more than one tool in your “toolbox” and you will probably find as I did, that you need several programs with different strengths and weaknesses to get your work done.
Best of luck,
Must Rhino’s Permissiveness Bite Users Down The Road
It seems that commonly cited reasons why booleans are failing, is that the underlying geometry is flawed in a myriad of ways. – Boundary edges aren’t actually coincident. Breps aren’t actually closed. Curve seams are parallel (?). While this brings up concerns that I’ve already mentioned related to encapsulation being broken and interfaces not being respected, it also begs questions related to how, why and where Rhino is accepting flawed geometry even when it causes operations to fail later in the design process. Actually, we already understand how’s, why’s and where’s of flawed geometry. The real questions relate to how users can control Rhino’s level of permissiveness and how to mitigate the downstream consequences.
In the admittedly short time I’ve been using Rhino and Grasshopper it feels like I’ve spent eons trying to figure out why operations like booleans are failing. I can’t count how much time I’ve spent waiting in blocks of 2 to 5 minutes for a solid boolean operation to complete only to be rewarded by the message: Boolean failed. Don’t know why. I understand that it may already be too late at that point for the command to provide a suitably informative, actionable message for the user. I also know that the root cause goes back to when Rhino agreed to accept a substandard piece of geometry to create a closed curve, or a surface, or a solid.
Rhino (and Grasshopper) should include the ability for a user to communicate the level of permissiveness they wanted Rhino to exhibit. Rhino seems to currently have a high tolerance for bad data, and I see the advantages of doing so — but also see the significant downsides. I want the option to lower the tolerance level. And I want Rhino’s primitives and file reading functions to honor that setting.
This will allow me to identify geometry not suitable for higher level operations at their point of creation, when it’s still early enough both for Rhino to communicate the flaw clearly and early enough for me to fix the problem. Operations performed as part of a Grasshopper algorithm, a mainline case for many of us, the level pf permissiveness in this way because an easily configurable debugging tool.
Materials Are Used To Create Structures
Warning: This section might be a bit CS-geeky to some…
Just as a building architect shapes materials like wood, glass, and metal to create building structures, aren’t NURBS and Breps the “materials” Rhino users use to create structures like curves, surfaces, and solids? You raise a good point: that there need to be formally defined interfaces and abstraction layers for both materials (NURBS and Breps) and structures (curves, surfaces, and solids).
The properties and capabilities of NURBS and Breps need to be encapsulated behind a clean interface. (And this is where my limited experience with Rhino might show…) Aren’t Rhino’s points, curves, surfaces and solids polymorphic? That is, aren’t there a set of abstract interfaces (Curve, Surface, Solid, …) that client code uses to manipulate these structures? This would allow NURBS and Breps to just be concrete subclasses that adhere to these standard interfaces. (NURBSCurve, BrepCurve, etc.) Developers break encapsulation and go around the interface at their peril.
Note: I’m just talking architecturally, not implementation.