Spliting objects, deleting the unwanted parts, running BooleanUnion, one of the objects disappears and booleanUnion mysteriously fails. Undoing the BooleanUnion command. Copying the objects to rhino 7, and running the BooleanUnion on the objects without any modification, as they were in Rhino 8; Rhino 7 does the job correctly and beautifully where Rhino 8 fails.
you can watch the video to know what I’m talking about.
McNeel should address this issue. it seems that splitting one object from another, then booleanion the 2 objects, Rhino 8 fails, where Rhino 7 succeeds.
Intersect makes a closed curve plus two tiny open ones. The closed curve has some tiny segments as well. I know this is a bad example. Still somehow V7 figures it out.
Thank you for sharing. This example surely the BU would fail; Since BU relies on intersecting curves to split the surfaces, delete the ones that can’t be joined and then join the open polysurfaces where their split edges tightly meet… the intersect made one closed curve which is required for BU to work, but what caused it to fail was those 2 tiny open curves. I tried it in 8 and 7 and both the interest yielded those 2 tiny open curves which caused the BU in 7 and 8 to fail. The question would be: why Rhino created those +2 tiny curves in the first place?
I deleted the 2 tiny curves and used the closed curve to split bottom part, the split command failed (here is why BU fails too). to work around it, surprisingly, extract the upper surface and then split it with the closed curve, Rhino mysteriously split the surface into 3 parts. Why couldn’t split it while it was still part of the polysurface? this happens all the time. extracting then splitting would solve it, but why this workaround? anyway. doing this, the whole parts can be joined as one single polySurface.
I prepared the file for you to test it. Originally the file was created in Rhino 8.8. I split the white parts by the violet parts as you can see, deleted the unwanted parts, and I run BU which caused the parts to mysteriously disappear… copy and paste to Rhino 7 and run the BU which as you can see works fine. Something not right in Rhino 8 that needs fixing.
I share here the file with you, and I included here 2 videos one runs in Rhino 8 which fails and the other video that runs in Rhino 7 which works. Uploading: BU in 7 Works.mp4…
Yup. Ran into the same issue. Simple, valid geometry (kid’s toy) will give “broken” geometry with random surfaces missing in RH8.0 but boolean operations on the very same geometry will work just fine in RH7.0 … super annoying and totally unpredictable (same tolerances, no non-manifolds, surface normals matching, no holes). Using Rhino since V1.0 so I think I can build half-way decent geometry… bug seems to be rare but super frustrating nonetheless. … No fix found so far. Firing up my ancient computer with RH7.0 on it still the only workaround I have found.
Happy holidays to you too! May 2025 be a successful and prosperous for you where you will achieve all your personal and business goals - such as being able to tell the various functions of communication in an online context, with the effect of not coming across as passive-aggressive or rude. Source 1: Schulz von Thun, F. (1981). Miteinander reden: 1. Störungen und Klärungen. Allgemeine Psychologie der Kommunikation. Hamburg: Rowohlt. Source 2: The Art of Misunderstanding & The 4 Sides Model of Communication | by Victoria Schiffer | SEEK blog | Medium
somthing odd with your bottom surfaces… they are just barely not planar. or at the very least not co planar. and it’s by a tiny bit… possibly inside the tolerance gap
sub object select the lower surfaces and notice that there is a scale handle on the gumball indicating a tiny non planar situation.
if you delete the bottom surfaces and run the Boolean it works fine. you can then cap and have a valid closed surface.
I’d have to get this in front of the math guys to see what specifically is happening but figured I’d share my findings.
Hey, how 'bout you learn to post useful questions that contain actionable information and examples for people who might be able to help instead of nonsensical, unbelievable rants? If I’m curt with you it’s because I’m trying to cut through the bull to figure out what the problem is and don’t care about anything else, least of all what strangers online with a daily increasing chance of being bots think of my “manners.”
A) Thank you for your effort and a detailed reply!
B) Apology accepted.
C) It was not a question, it was a statement. Because I realized that the bug is apparently very rare and the folks at McNeel have bigger fish to fry, I did not formulate it in a way that it would cause work for anybody. It was a statement for those in a similar situation that this CAN happen occasionally. In this forum, I can see people of tremendous talent and experience and I don’t expect them to waste time on my tiny problems. If I DO need help, I will - of course - give people some stuff to work with.
D) Especially in times when bots and trolls can and DO sabotage a lot of communication for various reasons, manners are about the only thing left that differentiates services (paid or pro bono) and they are also the context to content, a well-known effect in many industries (and in communication theory) that the “tone”/“tonality” in marketing-speak is, paradoxically, more important than actual content. Yes, frustrating for us tech-minded souls, but that’s how the human brain is wired… I do pro bono work (operating a helpline for people with environmentally induced health problems) and I have learned the hard way that the “tone” thing is THE key factor when you want to help people. Wrong tone and they flat-out reject you help, no matter how bad their situation is…
E) Still wishing you a great and peaceful year 2025, your work is very much appreciated!
Well, I would have had about the same response as @JimCarruthers - without a file that contains a repeatable example, there’s no chance anything will get fixed. “Me too” posts without examples don’t really help anyone.
Intersections and Boolean operations are extremely complex things with thousands of lines of code and lots of “special cases”. They are constantly getting worked on. It is distinctly possible that when fixing the code to address one reported problem, something that worked before might get broken. If it is a rare case, nobody will notice it immediately. So something that worked in V7 might stop working in V8 and it won’t get fixed until someone posts an example of the V8 failure that can be debugged.
Thank you for your response! As I had mentioned in my initial post, this little hickup happened while working on a toy project. As the design and geometry are client work (and some of the files technically are not owned by me), I can’t share them publicly or with a 3rd party in any way. The NDAs and other legal stuff that I had to sign are pretty clear on that.
With the Nuremberg ToyFair’25 approaching fast, I simply don’t have the time to create a file that is causing exactly the same issues. As I found a workaround (going back to RH7.0), I thought I’d simply share the fact that this (apparently very rare) issue in indeed real. I did not expect anybody to look into the issue, I just assumed that the folks at McNeel were aware of the issue and that it would eventually be addressed or a better workaround posted at some point in the future.
The only meaningful hypothesis I can come up with sort of aligns with what you are saying: It’s my impression that the internal representation of geometry ever so slightly differs between versions 7.0 and 8.0 and when importing geometry from an earlier version into 8.0 (in my case a an existing component we developed a few years ago), boolean operations between imported geometry and geometry built from scratch in 8.0 can occasionally fail, no matter how clean and simple the geometries might be. But to validate this and to build a file that is showing exactly this behavior, I simply lack the time.
as someone who worked in toys for a loooong time… you can share bits of the model that give you trouble… just not the whole model.
also you are welcome to upload privately to us via tech@mcneel.com or use our uploader Rhino Accounts which are both private between you and us. Non Disclosure is the default here with client files and they are all deleted after your problem is addressed.
we are very keen to see boolean failures so we can help diagnose the modeling issue or improve our tools.
Wow! I knew the team at McNeel is amazing but I never expected this level of support … and during the holiday season!!! Ok, once the (pre) trade fair madness (and the end-of term madness) is over, I will make use of the ways you laid out in your comment! All in all I am super impressed with how stable and reliable boolean functions have become over the years … and maybe that’s why a small problem now feels more annoying than in the good old days when flipping normals, adjusting seams and playing with tolerances was just part of the normal workflow. Again, thanks for taking an interest in my little problem.
I hope you have a great start into a peaceful & healthy year 2025!
hi Kyle,
I did not notice that “somthing odd with your bottom surfaces… they are just barely not planar.”The issue here is why Rhino 7 Unified the objects without any problems, while Rhino 8 Failed?
if the problem was serious, then both Rhinos 7 and 8 should yield same result, if they did, I would have automatically think that something wrong with the surfaces, but since Rhino 7 did not have any issue with the model, it is logical to assume that Rhino 8 has some bug.
