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
A couple of us discussed this a bit at TPAC: We think it would be useful to expose a set of squeeze events like we have select events, for a "primary squeeze" action (currently defined in the gamepads module). This basically exposes an event for buttons[1] (if nonempty) just as select is an event for buttons[0]. Devices would not be required to trigger this event (unlike the primary action, which is mandatory).
Select and squeeze seem to be the two main webxr-exposed buttons that are common across most devices and have familiar and uniform meanings (it wouldn't make as much sense to expose, say, a "B button pressed" event)
This is also good for AR devices that wish to expose hands as input sources: these hand-input-sources do not have gamepads, but can have select or squeeze events. We eventually need to come up with a way to expose articulated hand tracking, but a lot of applications need just one or both of these events to work, without needing gamepad support.
Minor clarifying note: addEventListener() is perfectly happy to accept unknown event types, so adding a new event like this after shipping is not backwards compatibility breaking.
(See immersive-web/webxr-gamepads-module#2 for the "squeeze" naming if unfamiliar)
A couple of us discussed this a bit at TPAC: We think it would be useful to expose a set of
squeeze
events like we haveselect
events, for a "primary squeeze" action (currently defined in the gamepads module). This basically exposes an event forbuttons[1]
(if nonempty) just asselect
is an event forbuttons[0]
. Devices would not be required to trigger this event (unlike the primary action, which is mandatory).Select and squeeze seem to be the two main webxr-exposed buttons that are common across most devices and have familiar and uniform meanings (it wouldn't make as much sense to expose, say, a "B button pressed" event)
This is also good for AR devices that wish to expose hands as input sources: these hand-input-sources do not have gamepads, but can have select or squeeze events. We eventually need to come up with a way to expose articulated hand tracking, but a lot of applications need just one or both of these events to work, without needing gamepad support.
cc @thetuvix @NellWaliczek
The text was updated successfully, but these errors were encountered: