Boolean operation

Replies to This Discussion

Permalink Reply by David Crisp on March 2, 2011 at 1:26pm

My biggest problems with booleans are poor geometry and shared surfaces.

 

Make sure that the object is built without any folding edges or overlapping single surfaces (like a pipe that is bent too hard). This is a common problem among beginners, but one that can be overcome with good mathematics and experience. (For example, put your cross sections on the outside of a curve, rather than the inner.)

 

Rhino 4 was supposed to fix the shared surface problem, and although it helped, this still gets me. It is a given that we have to build on the same plane or have an end that is shared with another part. You could just split and join, depending on the simplicity of the file, more than likely though you'll have to move one of the parts to be booleaned. Either move it or scale it so that they don't share a surface. Most parts can be moved or scaled without making too much difference in the visual or physical look. A move as little as .05mm or a scale of 1.005 should suffice.

 

If you have to do intersection to get difference, then check the direction of the surface normals. Generally, on a polysurface the arrows should point out. If not, flip the direction, and try again.

 

Good luck!

 

 

 

 

• ▶ Reply

Permalink Reply by sid porobic on March 2, 2011 at 1:40pm

Thanks for  the  reply David... I am aware of  the most problems you mentioned....but I am finding Booleans unpredictable. Today I had  a case with one  student when to get  intersection he had  to do difference, That is  something I would not  believe if I did not witnessed it. I have to mention that normals were facing outwards.

• ▶ Reply

Permalink Reply by Charles Fee on March 4, 2011 at 10:00am

Sid- I encountered the same thing you've described, in exactly the same way. While there has been a SIGNIFICANT improvement at RH-4, the problem remains, and just as you've described it. The solutions provided by David are very good, but once you've verified the normals, check one other thing to try and eliminate ever having to move the subtract component .001 or some such- get into the habit of always overlappoing your parts. For instance, let's say you're cutting a hole into a box. Draw the circle on the surface just as you'd expect, but when extruding the circle to a cylinder, use BOTH directions, enter the "depth" as usual, and subtract the cylinder from the cube. Shared surfaces create a divide-by-zero type problem which the programmers at RHINO haven't yet dealt with effectively. To their credit, the condition is greatly improved, but your reported issue remains. I continue to get failed booleans but not NEARLY as often, and I just work around them- the frustration isn't worth it. Good Luck  and let us know how it goes !

• ▶ Reply

Permalink Reply by sid porobic on March 4, 2011 at 11:26am

Thanks Charles. Unfortunately I find that sometimes the only way is  to go back and draw it again hoping that next  time it would work. Have not tested booleans with Beta 5 properly. I wonder if they work better or lets say more consistent.

 

 

• ▶ Reply

Permalink Reply by Charles Fee on March 4, 2011 at 12:54pm

Yes, it gets frustrating. I haven't heard about whether there's a significant improvement in RH-5. Typically software developers pay more attention to adding new functionality than improving existing, so I'd have to hear from someone more familiar with this particular issue in 5. Good luck !

• ▶ Reply

Permalink Reply by Pascal Golay on March 7, 2011 at 11:40am

Hello- One thing to keep in mind is that Boolean operations are really sort of shortcuts for trim/split/join, so if the Boolean fails, and I realize this is what you may be doing now, usually trim/split will either work or tell you where the problems lie.

There is no question that there are cases that look dead simple where Booleans fail but very often it is possible to troubleshoot. The best tool for troubleshooting Booleans is the Intersect command. If you do not get a clean set of curves that you could trim the objects with from Intersect, then the problem lies either in the intersector, or in how the user has arranged the inputs, or with the input objects themselves. Usually a careful look at these intersection curves will help figure that out. Please do not hesitate to post examples that fail to us at McNeel (tech@mcneel.com) and we'll try to sort it out.

 

As for the confusion with Difference/Unioin etc sometimes giving unexpected results, this is more straightforward-  Rhino allows Boolean operations among open objects. With fully closed objects, there is no ambiguity about what is inside and what is outside but for open objects, however tiny the opening, Rhino has no way to tell if what it thinks is the outside corresponds to what the user sees as the oustide. Rhino makes its decision on the basis of the surface normals as indicated by the Dir (direction) command - the white arrows indicate the surface normal direction. Dir can flip the direction of open objects' normals so it is possible to come to an agreement with Rhino as to what the outside is. If the user  and Rhino agree on what the outside is, then the Boolean result should be as expected as well.

 

As an expoeriment, make a plane and an intersecting sphere. Try to BooelanUnion the sphere and the plane- note what happened, UNdo and use Dir (Flip option) to flip the normals on the plane (you will not be allowed to flip the sphere, closed objects always have their normals pointing outward)  and repeat the Union- see how that goes the other way? Note that Boolean2Objects allows you to toggle through previews of all the Boolean possibilities if only two objects are involved, and hit Enter when you see what you want.

 

I hope that helps some.

 

-Pascal

• ▶ Reply

Permalink Reply by sid porobic on March 7, 2011 at 11:53am

Thanks Pascal for  your reply. This is all useful to know. I will have to start collecting these files and  sending them to you.

• ▶ Reply

Permalink Reply by Charles Fee on March 7, 2011 at 1:49pm

Pascal-

Thanks for your reply. As you seem clearly aware, these things remain a concern. That your team takes them seriously enough to reply here is a credit to the attention you are willing to pay to these user issues. RH-4 is greatly improved over previous versions, and I'm confident RH-5 will be even better ! How much attention was paid to problems with booleans in RH-5 ?

Thank your team again for me.

C.F.

• ▶ Reply

Permalink Reply by Enrico S. on March 11, 2011 at 4:33am

Normals direction, absolute and relative tollerances, and unclosed polysurface may couse  these probles.

• ▶ Reply

Permalink Reply by chris on March 11, 2011 at 4:42am

One thing I've noticed with boolean commands is that if you're doing it on a surface you've created from complicated surfaces, is that you have to make sure the surfaces have joined correctly. If you type the command 'show edges' you should be able to see the edges that aren't joined correctly. Sometimes this includes points(intersections between surface edges) and this can interfere with the boolean commands. Sometimes 'joining edges' will fix the problem, and sometimes you'll have you completely redo the surfaces where the edge join is causing you issues.

 

As previously mentioned, if the Boolean command doesn't work, try a split, or a create curves from intersection and then join the gaps in the curves (I usually edit controll points) and split the surface using the curves.

 

I hope that helps. 

Chris

• ▶ Reply

Permalink Reply by Charles Fee on March 11, 2011 at 9:45am

Chris-

Good call. Everything you've mentioned is something I've worked with as a result of the problems I've encountered using BOOLEAN operations. That the user has this level of "inside" access tho is a 2-edged sword: 1. A HUGE advantage when troublesheeoting problems, and huge assets when also used for other opreations not necessarily boolean-related, but 2: NECESSARY as a troublesheeoting aid for troublesheooting problems. That you're so familiar with these tools as they relate to troubleshooting bolean related problems, tells me that you've encoutered the issues as well, and have worked hard to deal with them. Thanks for sharing the results of your experience.

 

However, that you've found it necessary to work that hard to solve or at best really, to manage the issues, is unfortunate, but a necessary reality.

 

When I encounter the boolean related problems that I run into, its ALWAYS beccause I've constructed one RHINO closed sub-part and then the RHINO closed sub-part to add or subtract from the base part to create my target part. I very rarely (if ever) create some creative seperate surface and create multiple creative shapes that I then must re-stitch together to then boolean into my target piece. Under the conditions where I've properly created the sub-parts and properly positioned them (no divide by zero sorts of contructions, etc.) and still get failures, its most often because my composite has reached a level of complexity that may be beyond RHINO's precision, relatively low tolerance range and surface-mesh to part matching algorithms to handle effectively.

 

That the programmers have done such an excellent job in improving the situation at RH-4 is impressive, but the best we can do is improve our contruction techniques (no software is infinitely forgiving- its up to US to master our tool)  and master the management techniques like those posted by expert users above, to succeed at our art. We push our tools to the max, often well beyond their initial design basis. That RHINO remains such a robust solution is a genuine testament to the developers, the support they get from management and the STRONG user community that shares their work-arounds and solutions.

 

Ok- I've carried on enough.

 

Good luck and let us know how it goes !

• ▶ Reply

Permalink Reply by sid porobic on March 11, 2011 at 10:01am

This is turning out to be a very good discussion. Thanks for all comments and please do share your experience.

Sid (AKA Sepo)

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page