Decouple update of transform node matrix and attributes#147
Decouple update of transform node matrix and attributes#147jcfr merged 4 commits intoKitwareMedical:masterfrom
Conversation
…ansformNode Follow-up on API originally introduced in 59b7d1b (Adding interface and logic to maintain MRML transforms for each generic VR tracker).
Generalize updates of node attributes to all type of devices and introduce two distinct functions: * `updateTransformNodeFromDevice` * `updateTransformNodeAttributesFromDevice` All transform nodes are now consistently set with these attributes: * `VirtualReality.<DeviceType>Active` * `VirtualReality.<DeviceType>Connected` * `VirtualReality.PoseValid` * `VirtualReality.PoseStatus` where `<DeviceType>` may be "HMD", "Controller" or "Tracker"
Similarly to HMD, left and right controllers, this commit updates the `vtkMRMLVirtualRealityViewNode` API to support creating default transform nodes associated with each generic trackers.
Simplifies the API to accept "deviceHandle" instead of a string reprensation of the device handle called "openVrDeviceId".
|
Built and tested locally ✅ Note that due to the lack of HTC vive hardware, the changes related to the support for generic trackers couldn't be tested. |
|
I'm just wondering if device type is one of "HMD", "Controller" or "Tracker" then why don't we add a VirtualReality.DeviceType attribute and then the same VirtualReality.DeviceActive and VirtualReality.DeviceConnected attributes could be used to indicate that the transform is valid. With the API proposed in this PR you need to do know what device types are possible and then do trial-and-error to find an attribute that can tell if the status is valid. The attributes can also be contradicting (if you have both HMD and Controller status attributes then which ones should be used?). I works consider making transform status a Slicer core feature (a proper property of transform node). It would be used in SlicerIGT extensively, but it could be very useful without that, too, just to temporarily disable a transform to quickly see the transformed nodes with/without the transformation in effect. Transformable node display node could tell what to do if transform is invalid: use the current transform but make the node appear more transparent and/or different color: use identity as transform; or ignore transform status for display. |
This makes sense. Also, since
Agreed. In the context of this PR, I intended to keep the same attributes that were introduced. |
This makes sense. Additionally, we could have the idea of the transformable object being |
+1 for this - I would love to have a hotkey to toggle the status of transforms. Currently I do this with the transforms context menu in the Data module but it's a multi-click and error prone operation. |
The following changes are done anticipating subsequent commits introducing support for both
OpenVRandOpenXRGeneralize updates of node attributes to all type of devices and introduce two distinct functions:
updateTransformNodeFromDeviceupdateTransformNodeAttributesFromDeviceAll transform nodes are now consistently set with these attributes:
VirtualReality.<DeviceType>ActiveVirtualReality.<DeviceType>ConnectedVirtualReality.PoseValidVirtualReality.PoseStatuswhere
<DeviceType>may be "HMD", "Controller" or "Tracker"Simplify introducing
CreateDefaultTrackerTransformNodeAPI. Similarly to HMD, left and right controllers, this commit updates thevtkMRMLVirtualRealityViewNodeAPI to support creating default transform nodes associated with each generic trackers.