You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The rootNodeName property is for most part being auto-generated but subsequently not used in either the viewer or motion-controller packages, which seems to have led to most assets not having any nodes matching these names. This effectively makes this property unusable as there is no guarantee the node exist.
It seems that the original intent of the rootNodeName was to have a node (per component) that forms the root of that component, with the corresponding mesh(es) and visual response nodes (_min, _max and _value) as its children. This can be seen in the generic-... profiles and some other profiles. However, many profiles don't have an intermediate node and instead have the visual response nodes all as (direct) children of the controller root node (this is also what the tutorial suggests).
I had hoped to rely on the rootNode to find all meshes that are part of a component and also serve as a location to point to when annotating the model to show which component performs which action in the experience. It seems that the value nodes are the next best thing, although since their position can act as a pivot, their position doesn't always reflect the position of the component on the controller.
In any case, created this issue to highlight the current issue with the profiles/assets and rootNodeName. Here's a quick summary of the profiles and their rootNodeName usage. The table shows a column for the property on the layout and for the components:
Root node (layout)
Root node (components)
generic-button
❌
✅
generic-hand
❌
❌
generic-touchpad
❌
✅
generic-trigger-squeeze-thumbstick
❌
✅
generic-trigger-squeeze-touchpad-thumbstick
❌
✅
generic-trigger-squeeze-touchpad
❌
✅ (left, right) / ⚠️ (none)
generic-trigger-squeeze
❌
✅
generic-trigger-thumbstick
❌
✅
generic-trigger-touchpad-thumbstick
❌
✅
generic-trigger-touchpad
❌
✅
generic-trigger
❌
✅
google-daydream
✅ (left, right) / ❌ (none)
❌
hp-mixed-reality
❌
❌
htc-vive-cosmos
❌
❌
htc-vive-focus-3
❌
❌
htc-vive-focus-plus
✅ (left, right) / ❌ (none)
❌
htc-vive-focus
✅ (left, right) / ❌ (none)
❌
htc-vive
✅ (left, right) / ❌ (none)
❌
magicleap-one
❌
❌
meta-quest-touch-pro
❌
❌
microsoft-mixed-reality
❌
✅
windows-mixed-reality
❌
✅
oculus-go
✅ (left, right) / ❌ (none)
❌
oculus-touch-v2
❌
❌
oculus-touch-v3
❌
❌
oculus-touch
❌
❌
pico-4
❌
❌
pico-g2
✅ (left, right) / ❌ (none)
❌
pico-neo2
❌
❌
pico-neo3
❌
❌
samsung-gearvr
✅ (left, right) / ❌ (none)
❌
samsung-odyssey
❌
✅
valve-index
❌
❌
yvr-touch
❌
❌
The text was updated successfully, but these errors were encountered:
The
rootNodeName
property is for most part being auto-generated but subsequently not used in either the viewer or motion-controller packages, which seems to have led to most assets not having any nodes matching these names. This effectively makes this property unusable as there is no guarantee the node exist.It seems that the original intent of the
rootNodeName
was to have a node (per component) that forms the root of that component, with the corresponding mesh(es) and visual response nodes (_min
,_max
and_value
) as its children. This can be seen in thegeneric-...
profiles and some other profiles. However, many profiles don't have an intermediate node and instead have the visual response nodes all as (direct) children of the controller root node (this is also what the tutorial suggests).I had hoped to rely on the
rootNode
to find all meshes that are part of a component and also serve as a location to point to when annotating the model to show which component performs which action in the experience. It seems that the value nodes are the next best thing, although since their position can act as a pivot, their position doesn't always reflect the position of the component on the controller.In any case, created this issue to highlight the current issue with the profiles/assets and
rootNodeName
. Here's a quick summary of the profiles and theirrootNodeName
usage. The table shows a column for the property on the layout and for the components:The text was updated successfully, but these errors were encountered: