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.

Merging surfaces

mahirmahir Member, Developers Posts: 1,052 ✭✭✭✭✭
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?


Best Answer


  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 1,048 ✭✭✭✭✭
    edited April 2018
    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?
    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.
  • mahirmahir Member, Developers Posts: 1,052 ✭✭✭✭✭
    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_RosenfeldJake_Rosenfeld Moderator, Onshape Employees, Developers Posts: 1,612

    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.
    Jake Rosenfeld - Modeling Team
Sign In or Register to comment.