Querying for the [other] part given two faces that touch each other? (with one face from each part)

Answers

• Options

  kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 565

  February 2016 edited February 2016 Answer ✓

  Two things: First, there are half-decent ways of getting the entity you want in this specific scenario, but second, the geometry in the general case may be unfriendly to this kind of search, so you may be better off not relying on the search succeeding.
  
  To form the query:
  evDistance is probably the best tool for the job. A good heuristic is probably to select the face closest to the center of the first face, like:
  

      const distanceResult is DistanceResult = evDistance(context, {
              "side0" : centerPoint, // Vector
              "side1" : qEverything(EntityType.FACE)
      });
  
      const indexOfClosestEntity is number = distanceResult.sides[1].index;
  
      const closestFace is Query = qNthElement(subQuery, indexOfClosestEntity); // use immediately
  

  Performance in this case would actually be pretty good – certainly faster than a FeatureScript loop checking each face, possibly comparable to a native query for, say, qClosestElement (which does not yet exist).

  
  Or not to form the query:
  While something like qCoplanarFaces might get made at some point, there are simple cases where that wouldn't return the right thing for this feature. What if that face curves off at the other end (e.g. isn't planar)? What if that face is offset slightly to allow room for glue? What if that part is actually four separate parts, all coplanar, all of which need to be cut?
  
  To me there seem to be two separate things you might be using that face for:
  

  1. Positioning new geometry:
     If you're using the face to, say, position a sketch to make a cut in, that's starting to feel like fishing for redundant information (After all, there already exists a known, coplanar face). Rather than being dependent on a second geometric source of information to make your features (problematic if the sources disagree), why not define the second sketch in terms of the first? That is, make geometry based on positions in the coordinate system you already have.
     
     Notably, you don't need a planar entity to create a sketch. You can just make a Plane data type, and use newSketchOnPlane() instead of newSketch().
     
     
  2. Defining which part to merge with:
     If you're using the face to define which part you're adding to or subtracting from, you can look for a body rather than a face. For this, I'd take a look at what's done in an extrude feature in the ADD and REMOVE modes, where "merge with all" is a boolean, and if it's unchecked, the user populates the merge scope manually. Defaulting to "merge with all" seems like a pretty decent strategy for something like this.

  
  

  5
• Options

  Emily_Qi_Wang Member Posts: 13 EDU

  February 2016 edited February 2016

  Thanks for the many suggestions, Kevin! We decided to not query, and followed the strategy used in extrude.fs. In summary, this involves querying for all the parts in the part studio with a qEverything, removing the tools and anything that's not a solid body from the qEverything result, and then doing a boolean operation. 
  

  0