Merging surfaces

mahir

I have a FS that deletes some faces from a solid and then fills in the open edges with opFill. Unfortunately, I don't see a Merge with all option for opFill. Now how do I recreate the solid part.I tried using Enclose, but I'm having trouble querying for the hollow surface body. qCreatedBy doesn't seem to do the trick. Little help?

https://cad.onshape.com/documents/833dffabd805010ce935bee2/w/d15b586cc7aa564eee76cc28/e/e06b1747a4949c3641434da2

Jake_Rosenfeld

@mahir

@konstantin_shiriazdanov was on the right track.  If you set up something like this at the beginning of your function, it will track the bodies (in this specific case):

var corners = evaluateQuery(context, definition.corners); //array of individual corner surface queries
var bodies = qUnion(evaluateQuery(context, qOwnerBody(qUnion(corners))));

Generally, this is not a safe way to get a robust query for a body.  What's happening here is that we're setting up a query directly for the transient id of the body in question (you can see this if you println(bodies)).  You'll have to then trust that none of the internal operations will change the identity of the body, which seems fine in this specific case, but isn't a guarantee.


If you want the body right after you do the delete face, you could use:

const sheetBody = qOwnerBody(fillEdges)

Or, if I could suggest a more systematic change: try using fill instead of opFill and just use the "merge with all" behavior directly.  The syntax will look like:

fill(context, id, {
    "surfaceOperationType" : NewSurfaceOperationType.ADD,
    "edges" : [{"entities" : fillEdges, "continuity" : GeometricContinuity.G1}],
    "defaultSurfaceScope" : true // <-- "merge with all"
});

konstantin_shiriazdanov

it seems like turning solid body to surface by deleting face still keeps body "id" just changing the body type. what if to try query resulting sheet body with the query corresponding to the initial solid?
Edit:
the way described above doesn't work, nor I was able to get created sheet body by subtracting queries for all surfaces after and before deleteFace was applied.

Jake_Rosenfeld

@mahir

@konstantin_shiriazdanov was on the right track.  If you set up something like this at the beginning of your function, it will track the bodies (in this specific case):

var corners = evaluateQuery(context, definition.corners); //array of individual corner surface queries
var bodies = qUnion(evaluateQuery(context, qOwnerBody(qUnion(corners))));

Generally, this is not a safe way to get a robust query for a body.  What's happening here is that we're setting up a query directly for the transient id of the body in question (you can see this if you println(bodies)).  You'll have to then trust that none of the internal operations will change the identity of the body, which seems fine in this specific case, but isn't a guarantee.


If you want the body right after you do the delete face, you could use:

const sheetBody = qOwnerBody(fillEdges)

Or, if I could suggest a more systematic change: try using fill instead of opFill and just use the "merge with all" behavior directly.  The syntax will look like:

fill(context, id, {
    "surfaceOperationType" : NewSurfaceOperationType.ADD,
    "edges" : [{"entities" : fillEdges, "continuity" : GeometricContinuity.G1}],
    "defaultSurfaceScope" : true // <-- "merge with all"
});

mahir

Thanks, @Jake_Rosenfeld. Using fill did the trick. I generally avoid using the UI version of functions, but in this case it seemed to be the most robust path - finicky creatures those transient queries.

Jake_Rosenfeld

@mahir

Definitely finicky.  A useful way of getting around them (if you need to) is to create a robust query like this:

const transQ = qUnion(evalauteQuery(context, something));
const robustQ = qUnion([transQ, startTracking(context, transQ)]);

The union is needed in the second part because tracking queries do not evaluate to their original geometry, so we're unioning together the original geometry with any future geometry.  In this way, whether the transient id changes or stays the same, the query will evaluate to what you expect.  YMMV, but if you ever use this and it doesn't behave as expected, we're here to help.

In most cases (including this one) the `op` functions do provide a more convenient programmatic interface.  The tradeoff is that the full feature may do a lot more than any one underlying operation, so sometimes it's worth it to wrangle an odd set of parameters to get the robust functionality.  Some other cases of this are patterns, mirrors, and any time you want to interact with Sheet Metal.