Best strategy to make features robust in boolean operations?

dave_cowden

I'm encountering a problem I've had many times, but I've never really found an elegant way to solve it.

When making a feature that does boolean operations, there are many opportunities for BOOEAN_INVALID, due to line-on-line geometry.  

Usually, I've resorted to ugly 'add 0.0001*meter' kinds of solutions, to make things i'm subtracting a bit larger, a bit smaller, etc.  The goal is to shield the user of the feature from the need to fiddle with the geometry to make it work.

Is there a canonical/elegant way to solve this kind of issue?  Of course its easy to simply notify the user that an adjustment is required, but _usually_ the user's intent is clear...

lougallo

To avoid nonmanifold?

konstantin_shiriazdanov

faced this situation with opBoolean in my feature script where opBoolean used in a loop many times, and for some iterations it just shows BOOLEAN_INVALID, so i had to wrap opBoolean into try { }

dave_cowden

@lougallo yes that's right. When using Onshape interactively, I rarely see non-manifold errors.  

for example this shape removes a corner, and has the top sketch exactly lined up with the side of the block. But it does not produce BOOLEAN_INVALID



But frequently when I do the same type of operation in FS programmatically, I"ll get BOOLEAN_INVALID in this same type of case.  I have become occustomed to adding small dimensions to the cut to make sure it is not line-on-line with the side, but that has always seemed like a hack. Then it occurred to me that there might be a smarter way, because i dont have to do it in the GUI.  

@konstantin_shiriazdanov  yes in my case i wrap with try, and in fact I report a nicer regenError to the user, highlighting the features that are wrong.  But i want to do better, and actually make it 'just work'.  

ilya_baran

Do you have an example you could share where an FS boolean is failing and a "similar" interactive boolean succeeds?  That does not sound like correct behavior...

dave_cowden

I'll try to create an example. My current example is too complex to be useful to repro.  My situation involves text, in which the lower boundaries of the letters coincide with the side of an object.

I'll see if i can create an example

ilya_baran

Ah, that explains it -- our text letter boundaries are not usually straight lines but may be very close to straight, so I expect that's where the issues come from.  It's worth checking that that's indeed the problem, but if it is, I don't know of a better approach than adjusting by something too small to be noticeable.

dave_cowden

Yep that sounds right. I usually see it with letters that have curved bottoms. For example a j when the curved portion is near an edge, or a c or d 

Besides adding a tiny offset, I can't get it to work.

kevin_o_toole_1

Adding an offset sounds like the correct solution, otherwise (as people have pointed out above) the result is non-manifold.

To explain a bit more: Either of the cases below cannot be extruded into a single body (even if there's geometry properly joining them elsewhere) because the adjoining edge would be non-manifold.


Formally, a manifold 3D body is one where a sphere of sufficiently small radius cannot be placed anywhere such that it intersects more than two regions of space (i.e. inside and outside the manifold body). Along the extruded edges above, you can place a sphere that goes inside, outside, and back inside the resulting part no matter how small the radius of that sphere, so the result is non-manifold.

A good heuristic for identifying most non-manifold bodies is an edge that touches more than two faces.

Note that the everything above is all fine and dandy if the edges are on different bodies (since you have two distinct edges each touches two faces). It's only when you need to boolean them together into a single body that it's an issue, at which point you need to decide whether the result you want has a small gap or a small overlap.

dave_cowden

Hi Kevin. Thanks for the extremely detailed answer on manifoldness.  I get it, I'm mainly looking for the right way to craft the user experience so that things just work when these situations appear. 

It's easy  to throw up my hands, and give a regen error, combined with highlighting the problem faces. But that doesn't really make it easy sometimes for users know what exactly they should do to fix it. And, even if they do, it is extra, icky work.

I suppose that arbtrary, too small to notice offsets are the right answer in my case.