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
Applications that want to work across a variety of devices likely want to handle XR select events, while also supporting additional inputs where available. To avoid duplicate events or colliding function assignments, it's important to know which gamepad information corresponds to the select event, and if I'm understanding it right, the selectComponentId attribute as described in https://immersive-web.github.io/webxr-input-profiles/packages/registry/#components is intended to provide this information.
However, what's the best way for applications to do this when using the MotionController library? I couldn't find code using the selectComponentId attribute for this in the library or example snippets.
For an xr-standard mapping, the primary trigger would correspond to the "select" component, but applications shouldn't necessarily assume that the select event is a trigger if they want maximum cross-device portability.
Would it be feasible to add an example and/or a helper method to encourage applications to handle this in a compatible way?
The text was updated successfully, but these errors were encountered:
Alternatively, if this is out of scope, could the library return a result in createMotionController indicating that this input source's device profile isn't a supported motion controller and should be handled in a different way?
For example, input sources such as screen touch on a handheld AR device, or an untracked "clicker" button such as the Cardboard trigger, would generally provide XR select events and/or XR input sources, but shouldn't be rendered as 3D controller models. In such a case, I think it would be helpful if the library would help distinguish this. If it's already possible, it would help to have an example or best practice documentation.
well, a clicker or hardware button is not exactly a motion controller!
But yeah would be nice to have the possibility of adding an agnostic interface for like cardboard button, maybe even regular gamepads and the likes.
But In general I agree that callbacks/documentation for any of the events would be nice. Right now i am emitting such events manually...
checkTriggerInput(controller: VrInputController, trigger) { if (trigger.values.state === Constants.ComponentState.PRESSED) { if (!controller.triggerPressed) { controller.triggerPressed = true; this.onTriggerPressed(controller); } } if (trigger.values.state === Constants.ComponentState.DEFAULT) { if (controller.triggerPressed) { this.onTriggerReleased(controller); controller.triggerPressed = false; } } if (trigger.values.state === Constants.ComponentState.TOUCHED) { this.onTriggerTouched(controller); } }
thanks @ManuelGraf - literally the only example I could find online of XR gamepad event callback handling... we could really use more documentation on this.
Applications that want to work across a variety of devices likely want to handle XR select events, while also supporting additional inputs where available. To avoid duplicate events or colliding function assignments, it's important to know which gamepad information corresponds to the select event, and if I'm understanding it right, the
selectComponentId
attribute as described in https://immersive-web.github.io/webxr-input-profiles/packages/registry/#components is intended to provide this information.However, what's the best way for applications to do this when using the MotionController library? I couldn't find code using the
selectComponentId
attribute for this in the library or example snippets.For an
xr-standard
mapping, the primary trigger would correspond to the "select" component, but applications shouldn't necessarily assume that the select event is a trigger if they want maximum cross-device portability.Would it be feasible to add an example and/or a helper method to encourage applications to handle this in a compatible way?
The text was updated successfully, but these errors were encountered: