How can I split a part by multiple surfaces?

arthur_peters

I would like to split a single part into two parts by more than one surface. The reason is that while two small cuts would separate the part fairly easily, however creating a single surface to split the part would be complex to the point I don't even know how to approach it in general. So I want a way to take a body and some surfaces and cut the body using all the surfaces at once in useTrimmed mode so that I don't cut off random other parts of the shape. opSplitPart only taking a single tool is the main limitation I'm trying to work around.

Here is a manual example of the situation I am trying to handle: https://cad.onshape.com/documents/dac69982a60f83e429567279/w/a21ff6bef62be4030dfe93a9/e/ee7ce2784d7b50842f798214 (the cutting planes are highlighted)

Clearly, I could construct this so that the cuts are not needed, but my goal is to provide custom features that enable cutting and unfolding a solid shape similar to what is supported by the sheet metal tool. And doing so requires cutting up an existing and arbitrary body in a very controlled way. The first step of cutting up a part that has loops in it is the main issue that requires multiple cuts at the same time.

My current prototype is here if you want to look at it: https://cad.onshape.com/documents/b25934ce231bc7cc54b5f71b/w/22d6559f521f6dd2f91c3c2c/e/8e145788671a67d49b5b2a02 The problem with it is that it is insanely slow, due to my silly use of evCollisions. There is a more involved example at: https://cad.onshape.com/documents/146fd7ba5fc8678a0760f717/w/f9737f85504f7bdd029475c7/e/a5b719e8c9ae48517efc2320 It works sort of. But it's extremely slow (regen takes 5s for simple operations) and hard to control since the splitting techniques I'm using is very messy.

MichaelPascoe

1. Nice FeatureScripting, this is super cool!
2. Depending on the application, I've found that using an arc to connect the two splitting surfaces works fairly well.

Alex_Kempen

You seem to be correct, which is rather unfortunate. There might be a complicated workaround where for each input plane, you start by splitting the part, then use a combination of startTracking, qSplitBy, and qAdjacent to identify which parts need to be booleaned back together (you could also get the cutting surfaces and use those to assist with identifying parts that need to be booleaned). Not fun, but theoretically workable?

arthur_peters

I implemented my idea above: https://cad.onshape.com/documents/b25934ce231bc7cc54b5f71b/v/749d47d9aaa8640d0c043f00/e/ffd0b7e213744c52f4161653

Here is a simplified example as a picture.

It's not as fast as I would like. It takes ~150ms to do the splits shown in the picture. But I think it's workable even as a sub-operation within a larger feature.

MichaelPascoe

1. Nice FeatureScripting, this is super cool!
2. Depending on the application, I've found that using an arc to connect the two splitting surfaces works fairly well.

Alex_Kempen

It seems like you could use a combination of splits and boolean intersections to generate individual surfaces where each splitting tool intersects the part (i.e. the cutting surfaces only exist where the surface intersects the part). You would then need to decide which splitting faces to keep based on some criteria - you could get fancy and use a points manipulator to do it dynamically (and somewhat awkwardly), or take an additional input like another face to aid with deciding which intersections should be kept. Once you've figured out the specific tools you'd like to use to cut your part, you should be able to loop through each tool surface and use opSplit (with useTrimmed set to true) to cut your body.

arthur_peters

MichaelPascoe said:

1. Nice FeatureScripting, this is super cool!
2. Depending on the application, I've found that using an arc to connect the two splitting surfaces works fairly well.

I don't think this will work for me. The problem is that I cannot assume anything about the surrounding geometry, since this is going in a custom feature. In any specific case their may be no direct path to the "outside" from the cut planes.

I was thinking about this last night and my plan is as follows:

1. Perform a non-trimmed split with the one tool surface.
2. Find all the split faces which are NOT the split we actually wanted (with BB checks followed by confirmation with a e) and record them in a robust way.
   
3. Repeat 1 and 2 for each tool surface.
4. Build a graph of all the parts with edges being the unwanted split faces which connect parts.
5. Compute the connected components of that graph. (Union find FTW.)
   
6. Union each connected component separately.

This is a lot more complex than I hoped. And it doesn't handle splitting by surfaces with multiple faces well since each face will need to be used as a separate tool and it will result in a lot of small bodies that need to be reunioned at the end.

This approach is pretty similar to what I'm doing now. The difference is that I am tracking the connectivity between parts as I go instead of recomputing it using a massive evCollision call (which is really really slow of course). Also in this case I allow the user/caller to select which cuts are real cuts instead of my previous setup which required the user to specify a pair of entities that should be in separate parts. This made the resulting cuts ambiguous since various different cuts would split the two reference entities and guiding it to the right one was nearly impossible.

Alex_Kempen said:

It seems like you could use a combination of splits and boolean intersections to generate individual surfaces where each splitting tool intersects the part (i.e. the cutting surfaces only exist where the surface intersects the part). You would then need to decide which splitting faces to keep based on some criteria - you could get fancy and use a points manipulator to do it dynamically (and somewhat awkwardly), or take an additional input like another face to aid with deciding which intersections should be kept. Once you've figured out the specific tools you'd like to use to cut your part, you should be able to loop through each tool surface and use opSplit (with useTrimmed set to true) to cut your body.

... I will have to try that. I was pretty sure that would fail because each opSplit would fail to split the part on it's own. And as far as I know, opSplit cannot cut a a part in one spot leaving a disconnected, but touching, place but other connections between the parts in other places.

arthur_peters

Alex_Kempen said:

It seems like you could use a combination of splits and boolean intersections to generate individual surfaces where each splitting tool intersects the part (i.e. the cutting surfaces only exist where the surface intersects the part). You would then need to decide which splitting faces to keep based on some criteria - you could get fancy and use a points manipulator to do it dynamically (and somewhat awkwardly), or take an additional input like another face to aid with deciding which intersections should be kept. Once you've figured out the specific tools you'd like to use to cut your part, you should be able to loop through each tool surface and use opSplit (with useTrimmed set to true) to cut your body.

... I will have to try that. I was pretty sure that would fail because each opSplit would fail to split the part on it's own. And as far as I know, opSplit cannot cut a a part in one spot leaving a disconnected, but touching place but other connections between the parts.

Alex_Kempen

You seem to be correct, which is rather unfortunate. There might be a complicated workaround where for each input plane, you start by splitting the part, then use a combination of startTracking, qSplitBy, and qAdjacent to identify which parts need to be booleaned back together (you could also get the cutting surfaces and use those to assist with identifying parts that need to be booleaned). Not fun, but theoretically workable?

arthur_peters

Alex_Kempen said:

You seem to be correct, which is rather unfortunate. There might be a complicated workaround where for each input plane, you start by splitting the part, then use a combination of startTracking, qSplitBy, and qAdjacent to identify which parts need to be booleaned back together (you could also get the cutting surfaces and use those to assist with identifying parts that need to be booleaned). Not fun, but theoretically workable?

This is basically my plan above. However, using startTracking is a great idea. I was having trouble figuring out how to reliably figure out how the resulting objects touch each other. It is a bit complex, but it should be fairly easy to hide inside a library that just provides an operation that splits by multiple trimmed surfaces that collectively split a body, but do not individually do so.

I'll take a crack at it tomorrow night probably. I'm a software engineer by day. So implementing connected components on the part "touching" graph isn't too scary too me. Union-find for the win.

arthur_peters

I implemented my idea above: https://cad.onshape.com/documents/b25934ce231bc7cc54b5f71b/v/749d47d9aaa8640d0c043f00/e/ffd0b7e213744c52f4161653

Here is a simplified example as a picture.

It's not as fast as I would like. It takes ~150ms to do the splits shown in the picture. But I think it's workable even as a sub-operation within a larger feature.

billy2

Be careful, picking surfaces on the screen gives you a surface, picking the surface in the tree gives you the knitted patches.

arthur_peters

billy2 said:

Be careful, picking surfaces on the screen gives you a surface, picking the surface in the tree gives you the knitted patches.

When you say "knitted patches" do you mean the set of faces? (which IIRC are called patched in NURBS modelers)