On 25/04/2016 03:31, Chris Van Wiemeersch wrote:
Do we want to know the value of the press? Does the API for the Steam Controller, for example, return the force of the press as a float? The reason I ask is because with Touch events, there's a `force` property on the `Touch` interface: https://developer.mozilla.org/en-US/docs/Web/API/Touch/force
Likewise, Pointer Events have "pressure" https://w3c.github.io/pointerevents/#widl-PointerEventInit-pressure
P
We should probably introduce something similar to the Gamepad API. The `Gamepad.vibrate` proposal generally looks good, but I have a few concerns. `navigator.vibrate(pattern)` works well for pulse vibrations of varying durations and pause intervals, but the API doesn't allow the following: 1. vibrating at a higher/lower _strength_ (i.e., every vibration is emitted at the same strength, but you might want to do neat effects such as fading in and out) 2. selecting which vibration motors (haptic axes) to vibrate (e.g., with controllers that allow haptic feedback in different regions, such as left/right/top/bottom; a perfect example is the PlayStation DualShock controllers) > This is pretty basic as far as gamepad haptics go, but it's also provides a lowest common denominator interface that should be supportable by anything with a motor in it. It gives up some granularity (For example, it doesn't allow developers to trigger the two motors in an Xbox controller individually), but it provides a clean, universal interface that's easy to use and mimics existing features on the web platform. Brandon, you addressed my #2 above, but my concern is once the API is changed, it's going to be hard to change it again. If you take a look at all the content libraries out there for the Gamepad API, there's a ridiculous amount of logic and special casing web developers are having to do just between the Firefox and Chrome implementations - and between Windows and Mac. We already have `GamepadButton`, but perhaps we should have a `GamepadAxis` and _there_ is where we should add a `vibrate` property for each haptic axis. There are probably other ways of handling this, but just a thought. Those are my initial thoughts. If I think of anything else, I'll let y'all know. On Thu, Apr 21, 2016 at 10:14 PM, Brandon Jones <bajo...@google.com <mailto:bajo...@google.com>> wrote: I'd like to propose the addition of several new features to the Gamepad API, primarily born from needs that have been identified while developing the WebVR spec <http://mozvr.github.io/webvr-spec/>, but which also cover topics that have been under discussion in the past but deemed lower priority for one reason or another. First, I'm proposing that we add an optional "pose" object to the the Gamepad interface that would expose all the information necessary to track a controller with 3 Degree of Freedom or 6 Degree of Freedom tracking capabilities. The primary motivator for supporting this information is to allow devices like HTC Vive controllers or Oculus Touch to be exposed, but the same structure could also expose motion and orientation data for devices such as Wii, PS3, and PS4 controllers, as well as anything else that had a gyroscope and/or accelerometer. interface *GampadPose* { readonly attribute Float32Array? position; readonly attribute Float32Array? linearVelocity; readonly attribute Float32Array? linearAcceleration; readonly attribute Float32Array? orientation; readonly attribute Float32Array? angularVelocity; readonly attribute Float32Array? angularAcceleration; }; partial interface *GampadPose* { readonly attribute GamepadPose? pose; }; Position is given in meters from a device-specific origin. Velocity and acceleration are given it meters per second, and orientation is a quaternion. If provided all arrays should have 3 elements to except the orientation, which has 4. The proposed pose interface largely mirrors the VRPose <http://mozvr.github.io/webvr-spec/#interface-vrpose> interface from the WebVR spec, but drops the timestamp since that's already provided on the Gamepad interface itself. The VRPose interface could conceivably be used directly, but I'm assuming that we'd rather not have a dependency on a separate work-in-progress spec. Second, I'd like to see the API more explicitly support devices that have touchpads. It's my feeling that the existing axis array is sufficient for exposing the touch position, but we need a way to indicate if the touchpad is currently being touched to disambiguate a value of zero from no input. This can be handled currently by assigning a button to report pressed = true when the touchpad is touched, but since many touchpads also can be clicked as a button you end up with two buttons associated with a single input. I'd like to proposed that we extend GamepadButton with a "touched" boolean to make this case explicit. interface *GampadButton* { readonly attribute boolean pressed; readonly attribute double value; readonly attribute boolean touched; }; For non-touch controls it seems sensible that this would always report false. Finally, I'd like to propose that we add gamepad vibration controls. This has been talked about in the past as well, and the thinking has typically been that the Gamepad API may want to try and use the Vibration API <https://w3c.github.io/vibration/> somehow instead of exposing a new interface. However that API doesn't currently have a way to target anything other than the device's default motor (usually for a phone), and I don't see there being much interest in extending it to do so. Still, I don't see much sense in re-inventing this wheel so I suggest exposing the same interface on the Gamepad object. partial interface *Gampad* { boolean vibrate (VibratePattern <https://w3c.github.io/vibration/#idl-def-VibratePattern> pattern); }; This is pretty basic as far as gamepad haptics go, but it's also provides a lowest common denominator interface that should be supportable by anything with a motor in it. It gives up some granularity (For example, it doesn't allow developers to trigger the two motors in an Xbox controller individually), but it provides a clean, universal interface that's easy to use and mimics existing features on the web platform. I've included several developers that have been participating in WebVR's development to provide some feedback from that end of things. These are some reasonably large additions, but they can be layered on to the API as it stands today without breaking backwards compatibility and cover features that have been discussed as possible additions previously. Hopefully we can figure out a way to incorporate them that works for everyone. --Brandon
-- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
