Turn off hit testing visibility for render package geometry created for DM manipulator

[aparajit-pratap]

Purpose

https://jira.autodesk.com/browse/DYN-3219

TL;DR:
Hit testing was turned on for Helix line and mesh geometry during the helix updates that went into release 2.7. This interfered with the custom hit testing logic implemented in the DirectManipulation extension for manipulator geometry. This has therefore been fixed by disabling the hit test visibility specifically for manipulator geometry.

After enabling hit test visibility for mesh and line geometry in Helix, any mouse click events were being handled by HelixWatch3DViewModel.HandleViewClick. This method detects if there are any hits on scene geometry with the mouse pointer. If there are, then it finds the corresponding node that created that geometry and selects it. Selection of a Point.ByCoordinates node automatically draws a manipulator gizmo at the location of the point it creates.

Previously this method wouldn't return any hits, and therefore not find any nodes. However, after enabling hit-testing, this method began to find hits and tried to match the hit geometry with workspace nodes. This logic was never intended to work with manipulator geometry, and due to the current logic, the matched node returned would always be the first node added to the workspace. In the case where there are two Point.ByCoordinate nodes, for example, clicking on the second manipulator would therefore result in the first node being selected instead, which is why the manipulator gizmo would be drawn (appear to jump) on the first node instead of staying with the second.

This has been fixed by simply disabling hit test visibility just for manipulator geometry as hit testing on manipulators is
implemented separately in and specifically for the DirectManipulation view extension (see NodeManipulator.MouseDown).

Declarations

Check these if you believe they are true

• The codebase is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• This PR modifies some build requirements and the readme is updated

FYIs

@QilongTang

[mjkkirschner]

I'm guessing this is not easily testable?

[aparajit-pratap]

I'm guessing this is not easily testable?

Yes, we don't have a good way to test direct manipulation behavior currently.