Could/Should JointOrigins be avoided for adding type information?

[Jekannadar]

The Joint API internally uses JointGeometry or JointOrigins to create a joint.

JointGeometry is created from Faces or Curves by specifying a JointKeyPointType. These KeyPoints seem to correspond to the snap points seen in the Joint command, and the documentation vaguely supports this notion.

JointGeometry is persisted when a Joint is created, as the snap-points can be edited and highlighted when editing an existing joint.
JointGeometry is however denoted as "transient" by the Documentation, so it might not be standalone saveable.

It should however be possible to annotate the JointGeometry's associated entity with the associated KeyPointType and GeometryType. This would allow recreating the JointGeometry during assembly, akin to the Joint API example in the documentation.

Questions:

• Is the preSelectMouseMove hook no longer broken?
• Can the KeyPoints be visualised? Their Origin can be retrieved and visualised on hover.
• Can the KeyPoints be visualised with adequate performance? Calculating all KeyPoints, creating JointGeometries and retrieving the Origins could be done on preSelect, which shouldn't be to bad.
• If the KeyPoints can be visualised, what needs to be selected? The Joint commands usually selects the underlying face and visualises the JointGeometry.
• If the KeyPoints can be visualised, how are they selected? The mouse coordinates would need to be checked and projected to see which point is currently closest.
• Implementing this means that transient objects need to be recreated. Additionally, removing types is no longer as simple as jsut deleting the origin. Is it worth the additional complexity? (Probably no, more relevant for a company than a Ph.D)

Non-Technical Questions:

• Creating JointOrigins has the "Reorient" Feature. Especially for difficult parts, like sliders, this is very useful to accurately model the joint. Can this be recreated without JointOrigins? (Maybe, but it's a pain. I am not quite sure how sliding axis change work or if they are possible in the GUI. Should test)
• From an UI perspective, is it less clear or unnecessary to switch? Arguably, the type needs to be displayed at the JointGeometries origin either way, and an indicator is necessary either wayfor clarity. Switching everything to then just display a custom graphic there instead of a JointOrigin seems a bit absurd.

[Jekannadar]

Using JointOrigins has worked well, and they very cleanly represent the theory behind frame transformations.