Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:

  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

opBooean INTERSECTION with multiple bodies from opPattern

dave_cowdendave_cowden Member, Developers Posts: 445 ✭✭✭
Hi, all:

I'm having a problem with opBoolean, BooleanOperationType.INTERSECTION.

Suppose I have a query with multiple bodies, which are disjoint.  Lets call these bodies A and B
Now, I have another body C.

My goal is to create ( A union B ) intersection of C   Suprrisingly, i cannot get it to work. Using this:
opBoolean ( {  "tools": qUnion ( [ A, B,C ] ), "operationType": BooleanOperationType.INTERSECTION );

always returns nothing, presumably because A and B are disjoint.

Performing a union on A and B first doesnt help-- since they are disjoint, the union still produces two bodies.

I know what you are thinking: why not use "keepTools": true, and  compute ( C intersection A ) union ( C intersection B)?

In my case, this does not work well because I'm using opPattern with a list of transforms.  This directly creates the bodies A and B.  A and B could be a list of 100's of items.  Computing the intersection of each item with C would require writing a loop that would do each transformation individually, which would be horrible.

Am i missing something obvious?  In other cad systems I have used, there is a notion of of 'compound solid' to address this. it allows me to express the intent that I want to essentially  (A union B ) intersection C 


Answers

  • mahirmahir Member, Developers Posts: 852 ✭✭✭✭
    edited September 2016
    I can confirm what you're seeing, and I'm pretty sure that it's functioning as intended. Think of it this way - opBoolean isn't doing a chain of intersection pairs. It's simultaneously intersecting all bodies within the query, and it's correctly determining that no volume is shared by ALL bodies. This will be the case anytime any of the bodies have zero intersection.

    Another option is to use the SUBTRACT_COMPLEMENT operation type. I'm not sure how it works exactly, but after a little testing it does what you want more or less. Assume you have body A that intersects disjoint bodies B, C, D, and E. You can use opBoolean with A as the target and B thru E as the tools. You end up with the intersections of C thru E with A. Don't ask me what it does with B intersect A. It doesn't show up for some reason. That being said, you can do what you want with two opBooleans - one for intersect(A,B) and the subtract_complement for the rest. It's better than looping through all of them "horribly".
  • dave_cowdendave_cowden Member, Developers Posts: 445 ✭✭✭
    Thanks, @mahir

    Yeah I figured this is working as intended... It just makes things a bit of 

    I will try the subtract complement. It sounds like it has a bug if it ignores the first tool, but I will try.



  • mahirmahir Member, Developers Posts: 852 ✭✭✭✭
    Definitely buggy. Once they fix that, it sounds like SUBTRACT_COMPLEMENT will do the trick. I don't remember seeing this option before, so maybe they're in the middle of implementation. It's definitely not an option in the stock Boolean feature. I'll submit a bug report.
  • kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 438
    Yep, you're right. SUBTRACT_COMPLEMENT seems to be ignoring the first body passed in. That's definitely not the intended behavior.

    Dave, you're also right that your proposed workaround with a loop of several intersections will be slower than a single SUBTRACT_COMPLEMENT (by how much depends on the case). If you want a workaround that makes your skin crawl but likely has good performance: Create a cuboid over the whole bounding box, subtract your tool bodies from the cuboid, and subtract the resulting cuboid from the target body.

    The bottom line is: Your case is exactly why SUBTRACT_COMPLEMENT exists and the onus is on us to fix this bug. Do note that when we fix it, upgrading to the latest FS version *will* change behavior, so unless you want to deal with that upgrade, I'd avoid writing code that depends on the buggy behavior.

  • dave_cowdendave_cowden Member, Developers Posts: 445 ✭✭✭
    Hi, Kevin, thanks!

    i definitely had a workaround in mind, but a different one: i was just going to create some trivial body i dont care about and use it as the first tool for SUBTRACT_COMPLEMENT.  

    in short, this is really helpful-- i'll somehow get a SUBTRACT_COMPLEMENT-based solution to work. probably i'll make a wrapper function and us that, so that when the issue is fixed my wrapper will change instead.
  • mahirmahir Member, Developers Posts: 852 ✭✭✭✭
    Looking at the code for Boolean, the giant cuboid is how OS does a subtract complement anyway.  In the meantime, it might be useful to write an opBoolean2 function that can easily be replaced with the standard opBoolean once the bug is fixed. 
  • mahirmahir Member, Developers Posts: 852 ✭✭✭✭
     Looks like you had the same idea. That's why you should refresh before you reply :)
  • dave_cowdendave_cowden Member, Developers Posts: 445 ✭✭✭
    ;)  Great minds think alike !
  • dave_cowdendave_cowden Member, Developers Posts: 445 ✭✭✭
    bump-- as of 4/2017, this bug still exists. I rediscovered it after completely forgetting it existed :)


  • mahirmahir Member, Developers Posts: 852 ✭✭✭✭
    I haven't gotten around to testing it, but I received notification that the SUBTRACT_COMPLEMENT was fixed.
Sign In or Register to comment.