Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- 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_cowden
Member, Developers Posts: 475 ✭✭✭
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:
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
?
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
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
? 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
0
Answers
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".
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.
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.
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.