Application shortfall

I’ll qualify this with my enthusiasm for Rhino in general.

However, I find this application is often a little bitch.

I expect design applicaions to help me design. I don’t expect to be making sure the application is happy. Surely there’s some means to allow for what’s crudley known as error correction so one does not have to inspect literally every single step.

In this instance, since I’ve been advised repeatedly to avoid the boolean function - being told it’s somehow a second rate solution to creating. Even though the intersections required for the operation were created by the tirm tool using the exact same object they’re somehow not suitable a few steps later.

I’ve exploded an object and went through the tedium of trimming and joining back together about 32 seperate surfaces. But there’s one - there’s always at least one, that will not be split or be trimmed as apparently it’s no longer tangent or whatever friggin condition it was in previously. Instead I get “Split failed, objects may not intersect or intersections may not split object.”

Really?? This is utterly silly. WTF!!!

In this instance, a surface must be trimmed or split in order to make a proper join. However the surface that was use to split other surfaces will not work on this last one.


My point is this: There’s seldom if ever an instance of failure that cannot be attributed to the user. But so what? I don’t use applicaions to keep myself up on technique. The application must facilitate the precision it requires. Otherwise it’s like fitting a biycycle with a jet engine.

Yes. the coding is grand, and the possibiltes endless, but what of pracitcal ease of use?

I’m exasperated with how easily this application runs off the rails.

Why does everyone keep talking about the boolean’s difficult task? As in " -you’re expecting the boolean to …"

Well, yeah, that’s exactly what I’m expecting. Why did anyone bother to make such a command set if it’s so consitently overtaxed?

Nobody involved in design and production is interested in making a tool or a progam look good. It’s a friggin bit of code - an inanimate concept. For fuck’s sake, make it better and quit giving me excuses for it, or blaming me for the .001mm bit of error I managed to make using your program.

Maybe this trouble will all fade away in time, but at this point - and you do solicit criticism, I find aspects of Rhino utterly assinine.

Hi James

One thing is, apart from any deficiencies in Boolean operations, you have a tool here which is capable of great precision, but… you do need to use it precisely. Even if you trim out the two internal surfaces here, - which is actually pretty straightforward if you think in terms of surfaces and not solids - you get still naked edges in one corner where a close look shows that the edges are messy -

Those edges are just off, that is all there is to it, and you’ll have to clean up there if you want a closed solid.

Back_PG.3dm (504.1 KB)


Here’s another example.

Both of these objects are solids. They overlapp without any significant coplanar problems and yet the boolean fails.

Back.3dm (1.2 MB)

“It is what it is”? it’s crap.

Next, we extrude the upper face and boolean it to the object so they don’t share a face line. The boolean subtraction works! Oh thank heaven. But then try to boolean the results together and again no dice.

That’s not the user. That’s the application. It’s bullshit. It’s not a wel-written command set. The boolean tool is a touchy waste of time and yet it’s exactly what’s required for complex modeling. It needs to be improved rather than defended.

The edges may be messy but the edges are the result of a trim operation. How am I supposed to guarantee the application will not deliver crap? I didn’t create those edges!

Here’s the absurdity: If one splits an object and mirrors it along the split axis, the two halves that share the same edge will boolean together (although there’s been at least two instances where even that failed) Yet, in any other case when edges that were created by a trim or split or boolean split operation will fail. Are you seriously going to argue that there’s a meaningful difference? Why are some seams more worthy than others if they are in fact created by the same curve? Why do you keep telling us that it’s our fault or point out the lines are messy when the lines were created by the application!

By creating accurate surfaces and doing some kind of critical “self evaluation”. Take attached part for example and compare it with yours.

Part_Mechanic.3dm (113.2 KB)

Turn on isocurves to see the difference. In general, if a part is mostly made from mechanical features like extrusions, revolved surfaces etc. built them using exactly the dedicated commands, in this case, _Extrude and _Revolve. This ensures that you get surfaces with low amount of control points. Everything above is unnecessary and will make you problems later. Remember that when you intersect surfaces, all this information (control points) adds up, and when multiple controlpoints fall into the same location eg. during boolean subraction, the operation can fail like in your case.

What does it mean “adds up” ? For example create two curves, a circle in front view and a bow in top view, now run _Crv2View command to built a 3d curve. Turn on points for all 3 curves to understand that the information in the circle and the bow is now transferred into the resulting curve. So whatever you do, try to keep the pointcount in your curves and surfaces as low as necessary.

An accurate line should have 2 points, and none inbetween. Compare this rule with your geometry after turning the isocurve display on. Why do you have 40 controlpoints along linear directions in your model ? If you see a surface which should be linear with so many points, delete it and examine why this happens. In most cases, the curves you used to build it “infected” the surface. So if the curve has unnecessary points, the surface likely takes over that.

Does that help a tiny bit ?


I imported your parts into solidworks and got an error on this one. Looking at the points in Rhino I’m completely mystified as how you could have modeled something so simple with so many cv’s and so oddly distributed.

Back Split.3dm (1.1 MB)

When boolean doesn’t work there is usually a good reason, so use split instead - apart from observations above, if you wish to use the surfs in their current state:

Extract and hide parts of gold poly (see images);
Then split green with gold;
Extract and delete split parts (grey);
Then split gold with remaining green and extract and delete gold parts.

The result will join back up into a closed poly, but there are a couple of naked edges at surfaces which after splitting, end in fine points - probably why the boolean was having a hard time…

The thing is, I get to such extremes because the obvious solution fails. Bit by bit I try to satisfy the application’s demands. Soving this modeling task should be rather simple, yet the simple way is as often as not rejectted so one tries to work around the application’s short-comings. I started out with a simple plane to fill in the gaps but that was not acceptable, so I end up sweeping profiles to get a solid that maybe just might actually boolean with the other friggin solid. Then, when someone looks over the forms I get reports of dismay. Yes indeed, how can one end up with such a complicated mess? Do you suppose that I designed the output to have so many CVs? I made a point of cleaning up every curve used to the absolute minimum nuimber of points and stil I get the crap you describe. Maybe it’s a Mac thing.

Continuing the discussion from Application shortfall:

Like I said, the ‘boolea’ is like some entity that needs an excuse. “the boolean” is a pain in the behind. I think the boolean needs to be tuned up to be a tool instead of a challange.

Perhaps quit using the Boolean tools for a while as a method of tuning up up your modeling skills.
Use Intersect to make curves of intersection. Use Trim/Split on the surfaces, and Join the results.
When you find a surface that doesn’t Trim/Split figure out why.
That’s all Boolean tools do other than they respect surface normal direction.

Just a suggestion.

1 Like

I feel your beginner pain. I went through some VERY frustrating weeks and months trying to teach myself Rhino, and this was before there was a forum to ask for help. I think it’s that ability to remember how hard this stuff can that makes me a good teacher.

I think a good plan of action is to review some of the excellent online courses. You might start with this one video titled Dave’s Golden Construction Strategies: how to analyze and model like a pro. This video is free and is part of a 7-hour beginner course at lynda. 25,000 people have seen it, so you might want to check it out.

In the course, I am not a big fan of Booleans. They only work predictably with two solids. Even worse, there is no way to “go back” if and when you change your design. I use other methods, which are outlined in the course.

The course includes all of the things I wish I knew when I started. In fact, I tell students the manual is more like a dictionary, when it should be more like a cookbook. So, focus on training that builds things FAST and EFFICIENTLY, not training that shows you 15 commands – when 5 will do the job… If you are not a member of lynda and want to join, here is a free 10-day link.

Boolean ops are just shortcuts for a combined intersecting/splitting/joining operation. They can be great timesavers when used appropriately, I use them dozens of times each day, I know what to do when they fail and I don’t lose any sleep over it. People that say “you should NEVER use this or that command”, or “every thing HAS to be built this or that way” are talking about their their own personal experience and workflows, which does not necessarily apply to all situations and all people.

The most important thing to understand is WHY these things are failing or are difficult. While there are certainly shortfalls and things in Rhino that desperately need improvement, it is for the most part a highly accurate and efficient piece of software. If you are having continual failures with basic operations, and you notice that very few other people are experiencing the same problems, it’s perhaps time to examine your own approach. As with any software package, some people will feel right at home with how Rhino works and others not. YMMV as they say…



I would nominate “JoinEdge” and “MeshToNURBB” as commands to NEVER use, unless of course you have one of the rare situations where they are useful…

Quick question: Is Rhino the very first 3D CAD application that you are using? If so, it can be very frustrating. Contrary to what its price point suggests, and how it is marketed, Rhino is not a great choice for beginners, and especially to self-taught beginners. It is at its best when used to compliment other packages by users who are already proficient in other applications, such as SolidWorks. or at least by those beginners who are able and willing to heavily invest the necessary time and effort to understand the underpinnings of the nurbs modeling.

Belive me Clement when I tell you that ‘self evaluation’ has been a life-long curse. I’m in the habit now of checking control points and I eliminate all the uneeded I find. But as you point out, certain operations will generate an excess that of course are unseen until inspected. I’ve add simplyfycurve to my process with that in mind.

Are you referring to this:

I made this piece some weeks back so I’m not exactly sure, but at the time I was using 2 rail sweeps for the edges and extruding a flat across the back and bottom. It might be a worthwhile feature that monitors point counts of objects, that’s included in the Description window. I refer to this frequently.

I DLed your model but it was hanging the application. When I reopened the file it was empty - very strange, DLing a second time gave the same result - no content. I did notice you used a single rail sweep instead of two. I was getting a strange bulging on the corners when I tried that and the ‘maintain height’ didn’t eliminate it, so I opted for 2 rails.

I’ve a habit of duplicating edges to get the lines I want to work with. The arcs used in any contruction are clean - - copied from the original layout/guides curves. I rely on the original curves throughout the process to maintain consistency. It’s only later they seem to accumulate additional points. Is there a command that will return an arc to it’s minimal points? I see this all the time on arced curves that were once simple but are now like a chaing of beads.

Yes, will do. Everytime I’ve done something over I’ve noticed improvment and further understanding. Patience is not always a strong suite for me. I see the boolean set for the potential it offers, IF I can master it. So far that’s not the case.

Indeed! It’s the apparent nonesense that makes one crazy.

I did a couple months on lynda and enjoyed your tutorials. I take in a great deal more info than I can assimilate. Also, the boolean demands I’m making are admittedly pushing my limits.

Years ago I spent a year learning form-z. Found no useful work and moved on. Three years ago I dedicated myself to Sketchup but I found the interface nonintuitive and the results less than what I require. Still, it has some modeling features that are better than Rhino.

Finally, I want to thank you all for the responses and the support. It’s very generous and well appreciated.


Hm, my file has been created in Rhino6 and saved as RH5 format. See if this works better:

Part_Mechanic.3dm (383.4 KB)

If you can open this, hide the polysurface and look at the colored curves. Start with an _Extrude of the red closed curve along the green line with an arrow. Do not cap the extrusion by setting _Solid=No. Next part is to _Revolve the naked edges of the extrusion, i´ve marked this with a blue arc, the revolve axis is the blue line below that arc. There is no need to use _Sweep1 here, the whole part can be built using Extrude, Revolve, Extrude, Revolve, Extrude. Then join everything and Cap it.

To see if your arcs are clean and have constant radius, use the command _Curvature and evaluate the curves which should be an arc. If you do not get constant values as with all your arc like roundings, these are no arcs but freeform curves. The more you do with Rhino, the more you’ll be able to identify this just by looking at the isocurve density. eg. extude a 90 degree arc into a surface. This is how clean an arc surface should look like.

_SimplifyCrv, when it does not do it, create a new arc by drawing it.


That’s quite clever. Thanks much.

How did you locate the axis lines you drew?

I’m dealing with another surface anomoly that this may apply to as well.

As you can see from the images I’m trying to get a compound corner using a blend surface funtion but there continues to be a strange result.

zebr.3dm (77.6 KB)


That modle opened well enough, but using it is very jumpy. There must be some issue with the newer vs older versions. Also, I’m using the MAC version if that’s any indication.

By finding the knot on the surface edges where the linear part ends and the curvy one begins. This is not easy if the surface consists of linear and curved parts. Therefore i suggested to built things seperated from each other so you get topologocal edges which you can use, eg. to snap to.

This is a simple situation which can be solved simple. Just use the command _BlendEdge or _FilletEdge once with the attached part. zebr_cg.3dm (336.7 KB)

Notice that i´ve added some annotation dots to your geometry. What are those tiny linear red lines going from your start / end of the arc ? Note that a blend, is not an arc. An arc has constant radius which a blend does not have. My example above can be used to _FilletEdge or _BlendEdge. If you use any of those commands, notice what Rhino creates, it splits the surfaces so the linear fillet (or blend) is kept seperate from the compound corner fillet (or blend). You get clean topology without doing any complex modeling tasks or creating any curves at all.


That’s very nice.

I didn’t know I could fillet open polysurfces - or rather went off in another direction. Modeling is a thinking process that ofter leads me into a corner that I don’t know how to get out of.

I’ll make use of these techs and if you don’t mind will get back to you about another solution for the upper edge.

Thanks again.

Later - this is the thing. That method works wonderfully. But as you can see from the image I’ve one more issue to solve. I need to accomodate a third radius where the main body meets the back.

That radius is only a 5mm.

Maybe the multiple radius fillet?

It looks odd. This is how the front was modeled - using sweeps and blended curves

Why not ? just remove this surface if you do not like it and create a new blend curve (the red arrow) to trim the adjacent surface so you have a better flow of the fillet.

After changing the trim, you have a hole with 4 edges which can be closed either using _Sweep2 or _NetworkSrf or _BlendSrf. I would suggest you experiment a bit what is better and try to influence the results…