Reference in-context geometry with implicit mate connectors?

EvanReese · November 20

Is it possible? The mate connector feature seems able to, but Hole and Sketch with implicit MCs don't pick up on in-context geometry. Is there a way to make this work in a custom feature?

hagus · November 21

I was curious so I did some digging around here. Perhaps I didn't understand the question clearly but I'll share anyway.

The first thing that seemed to jump out was that any feature definition with a query that supports BodyType.MATE_CONNECTOR can't reference in-context implicit mates. I have a local copy of the complete standard library so I'm able to rip through it and even have a local LLM go looking for clues. I couldn't find any magic or internal enums that changed this behavior.

But then I got curious as to how the mate connector feature lets you do it. The first thing is that it the originQuery field is picking edges and faces:

        annotation { "Name" : "Origin entity",
                    "Filter" : ((EntityType.EDGE || EntityType.VERTEX) || (EntityType.FACE && ConstructionObject.NO)) && AllowMeshGeometry.YES,
                    "MaxNumberOfPicks" : 1,
                    "UIHint" : [UIHint.UNCONFIGURABLE, UIHint.NO_QUERY_VARIABLE] }
        definition.originQuery is Query;

But that doesn't explain why the UI presents implicit mate connectors as a valid input to this query. Indeed, creating a trivial FS with this query did not present such an option.

Well … I duplicated the mate connector feature and got to commenting things out until I could find some piece of code that broke it. The more I commented out the more I suspected there's some special treatment at play, something about how the mate connector feature itself is defined that permits this UI affordance, because here is what I ended up with:

FeatureScript 2796;
import(path : "onshape/std/common.fs", version : "2796.0");

annotation { "Feature Type Name" : "Test In-Context Simple", "UIHint" : UIHint.CONTROL_VISIBILITY }
export const mateConnector = defineFeature(function(context is Context, id is Id, definition is map)
    precondition
    {
        annotation { "Name" : "Origin entity",
                     "Filter" : ((EntityType.EDGE || EntityType.VERTEX) || (EntityType.FACE && ConstructionObject.NO)) && AllowMeshGeometry.YES,
                     "MaxNumberOfPicks" : 1,
                     "UIHint" : [UIHint.UNCONFIGURABLE, UIHint.NO_QUERY_VARIABLE] }
        definition.originQuery is Query;
    }
    {});

So there are two piece of magic that turn this feature on.

the exported variable must be named mateConnector
there must exist a query in the definition named originQuery

Hey presto! NGL, I kept coming back to this for a few hours because it really bugged me, given all the tools I threw at the problem. Magic variables, oy.

There's a secondary question of where the selected implicit mate location is stored; I suspect in one of the hidden definition parameters. Indeed, without adding more hidden stuff back in, the UI prevents you from clicking on those highlighted points.

hagus · November 21

Looks like details about the particular implicit mate connector chosen are stuffed into entityInferenceType, an enum:

export enum EntityInferenceType
{
    PART_ORIGIN,
    POINT,
    CENTROID,
    CENTER,
    MID_POINT,
    TOP_AXIS_POINT,
    MID_AXIS_POINT,
    BOTTOM_AXIS_POINT,
    ORIGIN_X,
    ORIGIN_Y,
    ORIGIN_Z,
    LOOP_CENTER,
    VIRTUAL_SHARP
}

Derek_Van_Allen_BD · November 21

Kinda wild that the hole feature, which is one of the most likely tools on the toolbar to be used in assembly context, lacks this functionality.

eric_pesty · November 21

The other thing that bugs me with that is that if you reference a non-context geometry MC, you can then go back and edit the mate connector and it will let you pick context geometry directly!

Derek_Van_Allen_BD · November 21

I should take these lessons and apply them to Poly-Mates and update that script. That way I can use it as a context middleware for any features that need multiple mate connectors passed from studio to studio without needing to modify the other mainstream features.

hagus · November 21

https://forum.onshape.com/discussion/comment/123516#Comment_123516

That's one reason I got curious because I'm like: I was literally wondering this only two days ago.

Some initiate into the forbidden internals of Onshape will have to clarify the reasoning here. My hand-wavy guess is something to do with implicit mate usage actually resulting in the creation of an entity in the part studio, and a rule that says mate connectors must have an owner body in the defining part studio …

There might also be some logic about them being fragile or ruining rebuild times. I can't think of a reason why they'd be any worse than picking any other type of in-context entity. In my head an implicit mate reference is a mate whose origin is a tuple of [Entity, EntityInferenceType] so what's the deal.

Definitely curious about why UI selection of these special implicit reference points is a secret feature. One could argue that implicit mate reference actually have nothing to do with mates per se? If my tuple understanding is correct. Very interesting stuff!

Derek_Van_Allen_BD · November 21

Oof, I just discovered that these changes will require me to break backwards compatibility with my original implementation of Poly-Mates due to the naming requirement and differences in input parameters. That's a shame. 120 documents worth of implementation are about to blow up unless I can figure out how to have legacy support.

marci_van_dort · November 21

I've been trying to do this exact thing recently and at some point I got stuck. Naming the exported variable and query variable does indeed work to get it to show implicit mate connectors, that's a great find! And by copying the connectorEditLogic and findOwnerBody functions from the MateConnector implementation I managed to query the corresponding bodies as well. However I still haven't found a way to access the coordinate system defined by that implicit mate connector.

hagus · November 22

@marci_van_dort I dug around a bit and found this example in decal.fs:

selectedOrigin = evMateConnectorCoordSystem(context, {
     "originQuery" : definition.face,
     "entityInferenceType" : EntityInferenceType.CENTROID,
     "requireOwnerPart" : false
}).origin;

I think if you add:

export import(path : "onshape/std/entityinferencetype.gen.fs", version : "2796.0");
// defineFeature …

annotation { "UIHint" : UIHint.ALWAYS_HIDDEN }
definition.entityInferenceType is EntityInferenceType;

You can use the above query. I tested it out below. Note that evMateConnectorCoordSystem is marked as internal, but it does return the CoordSystem you want.

I shoved together a video here!

Here also is a link to the Onshape doc where I've been messing with this.

hagus · November 22

Someone with more forum tenure than myself might know how to raise the bat signal for the Onshape team before this hack escapes confinement too widely :) I'm sure they'd consider official API because the internal hacks are starting to add up …

joshtargo · November 22

i didn't read the other comments, but I have only ever been able to get this to work with one implicit MC per FS. It Seems to require some very specific naming.

hagus · November 23

https://forum.onshape.com/discussion/comment/123589#Comment_123589

Yeah that is a good point, since something outside the FS is driving the special UI. What I would suggest is to use an editing function that detects when a selection has been made, add the coordinate to a list, then clear the selection out. Kind of like the one-at-a-time way you deal with control points in Routing Curve.

EvanReese · November 24

https://forum.onshape.com/discussion/comment/123539#Comment_123539

Ah now that's interesting! Someone correct me, but I believe it's because the implicit mate dialog and the actual Mate Connector dialog are actually the same feature. The code has this definition.isForSubFeature hidden boolean which I think drives the UI a bit for that.

@hagus The fact that changing the constant name breaks it reminds me of the Plane feature renaming planes. It only works if the const is cPlane.

Derek_Van_Allen_BD · November 26

https://forum.onshape.com/discussion/comment/123589#Comment_123589

Yeah that's what's hanging me up from implementing multiple implicit MCs in Poly-Mates. I can get multiple locations to load, but not attached to the same face as each other and the evMateConnectorCoordSystem() call keeps breaking in random cases or shifting around the origins of previous in context selections based on later ones. Maybe if I encapsulate the whole in-context routine into its own sub-feature it'll work?

Derek_Van_Allen_BD · November 26

Okay I've discovered two more special cases with feature names that appear to be hardcoded exceptions to usual practices. I'm trying to get dynamic naming applied to my Poly-Mates feature to show the user that a query variable is being generated in the feature and that that's where the definition lives. Problem is, I can't rename old features when I apply computed properties for the feature name. Every attempt I've made at modifying a custom feature has been an either-or type situation where you either get the ability to drive the name based off of computed properties or get the ability to modify the name in the feature tree.

Routing Curve and the Hole feature are 2 exceptions to this rule, their names in the tree are based off of computed properties but the user still has the ability to overwrite them with their own custom name upon right click. But if you copy and paste the code for either one of those features and change the name in the feature export to something else:

export const hole = defineSheetMetalFeature()

vs

export const nothole = defineSheetMetalFeature()

this breaks that functionality.

So I guess I'm going to have a bunch of Poly-Mates features that will never get a new name upon updating if someone starts to use them with QVs.

Reference in-context geometry with implicit mate connectors?

Answers

Howdy, Stranger!

Quick Links

Categories