Re: [gamepad] New feature proposals: pose, touchpad, vibration

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 <bajones@google.com
> <mailto:bajones@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

Received on Monday, 25 April 2016 13:48:56 UTC