Hi,

I've got a fairly simple case here of subtracting two cylinders from each other which is failing in the current (April) beta. The objects are close to the origin and sanely sized. Subtracting the smaller cylinder from the larger one takes a long time and eventually fails, either doing nothing or deleting both objects entirely. If I move the cutting cylinder to the other side of the origin, on the side of the cut cylinder with the seam, it works exactly as expected, and if I move the centerline of the cutting cylinder off of the tangent of the cut cylinder's surface, it also works. Ideas?

/Ella

Hi Ella, the booleans seem to be having trouble with the "seam edge" of the vertical cylinder just grazing along the other surface:





I'll try to investigate it a bit, but it may be something that will require tuning from the people who make the geometry library that I am using. That kind of grazing situation can often be a difficult area in intersection calculations.

Currently to make it work the easiest thing is to rotate the vertical cylinder by 90 degrees so that seam edge is "out of the mix" for the intersection, see attached file boolean-bug2.3dm which should now boolean ok.

- Michael

oh, right! I didn't realize the seam edge was lining up like that on the cutting object. Clearly still a bug, but yeah, that's easy -- I knew there had to be some kind of special case there. Thanks!

Hi Ella, I've dug into this bug for a bit, and the problem is that the surface/surface intersector seems to get stuck in a loop and keeps tracing the intersection curve over and over again, until the curve gets to 15,036 control points in it when it decides that it is too complex and bails out.

It's not very easy for me to determine where the exact bug is in this one, but it appears to have something to do with not handling the tracing near the seam area properly.

I have gathered it up and sent it to the company that makes the geometry library that I use, so hopefully they will be able to fix it up. I'm not sure how long that will take though.

Thanks for posting the bug!

- Michael

Yeah, that makes sense, given the really long runtime behaviour I was seeing -- it had to be some kind of loop. And hey, at least it's an interesting bug. :-)

/Ella

Funny though, Moi 1.0 generates a different result.

The library must have changed since.

Marc

Hi Marc, yup slightly different behavior in v1 although similar - that strange meshing artifact that you see there in v1 is due to the same kind of bad intersection curve being generated where it is looping around and around on itself.

They say they are going to be able to investigate this problem next week.

- Michael