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.
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
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:
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
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
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,
Dennis
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.
Hi Bob,
It seems clear to me that Rhino is not working for you. And, it is highly unlikely that it ever will.
Please return your license where you purchased it for a full refund.
Thanks for trying Rhino and Grasshopper.
All the best,
Could I get a summary of your thoughts that bring you to this conclusion?
Thanks,
fwiw, i tried intersecting/splitting one of your example files in fusion360 and it fails there too…
not necessarily saying much regarding your gripes with rhino… just saying that it’s likely you’re going to experience similar behavior in other modeling applications with these surfaces.
(the file containing these two surfaces)
The thing about Rhino is that it’s a Swiss army knife full of more Swiss army knives! There’s always a dozen or more ways of doing the same thing in Rhino. We’ve all been there, stuck, frustrated, going crazy why won’t this work!?
Post your problem on here and within a few hours at most you’ll have multiple solutions waiting.
Keep at it!
@neobobkrause if you could post a collection of files that fail to do what you want, and put them in a Dropbox folder that you can share here, that’d be a great next-step for this conversation.
Then people can case-by-case approach them and help you understand where the limitations are in NURBS, BREPs, poly-surfaces, and their representations in the software, as well as the limitations imposed by the tolerances of working with non-perfect math (floating precision and all that…) and how this and other CAD programs describe geometry.
At some point we all have to acquiesce to our tool limitations, and not ask them to do things in ways they weren’t designed to operate.
Therefore, please post example files with short descriptions, and also expand on your prior CAD experience, because different packages operate under different paradigms of operation and geometry description—NURBS surfacing vs. polygon modeling vs. Catmull-Clark SubD surfaces, vs. voxel-based representations, ‘Solid-modeling’ paradigms whether parametric or ‘direct’… It helps to know what mindset you’re coming into this from too.
I think such a collection of files that give problems might be like playing ‘Stump the Band’. If you think you are a real Rhino gunslinger, then download a problematic file and have a go at it.
I think most things have already been said very well, so just to add a voice to the discussion:
I have been using CAD software since over 20 years, (starting at a very young age) and have to say - at the moment Rhino has the best maintained codebase i every worked with. Its not perfect - nothing ever is - but compared to any other, lets call it ‘flexible’ software package (e.g. Maya, Max, blender…) it is bay far the most stable and well maintained.
And as said before, everyone has to adapt and learn what works and what not - idiosyncrasies as you called them. And while there are products that may perform better at certain tasks by reducing flexibility, Rhino (for now) seems the best balanced i ever worked with while modelling, programming, scripting and GH.
Thanks again to all who are sounding off in this discussion. I haven’t dropped out, but rather I’m on deadline and won’t be able to add anything until perhaps Monday.
@neobobkrause for a neo kid on the boolean block you need a lot of attention.
i saw in the other thread that pascal suggested you a simple solution not to bool the crap out of what you need to build it up not from booleans but from planes which you program as needed… why dont you just do that in future? booleans are a tool for the lazy who have no initial idea what they want but just fool around, ok thats harshly said but there is a solution to your problem… take it. AND the issue seems to be also on the list for further investigation now as dale wrote but still you keep persistently addressing very aggressively any kind of attention you get.
you cant just turn the whole world up side down to gain what you want being equally ignorrant because you know that you found something special here 
i am very sorry to speak that out but i think the discussion would´ve been “solved” about 20.000 letters before 
and with all due respect @bobmcneel showing somebody the door because of a problem which seems not solvable is an absolute no go, people are here to get helped not be kicked out… this may sound very disrespectful but to be honest in the whole discussion that punched me down the most.
i sure am nobody here but when i see people acting like that, my toe nails role up a serious amount.
so pls people get a grip be patient and fair… over and out (at least for me).