Support Gear VR Touchpad controller 0.4.0 #2183

machenmusik · 2016-12-18T08:07:48Z

The gearvr-controls component interfaces with the "Gear VR Touchpad"
controller exposed by the Carmel and Samsung Internet VR browsers.
As that controller has no pose,
the tracked-controls component cannot provide its usual
functionality (but an instance is added anyway since other components such
as aframe-teleport-controls use that to find controller entities). Instead,
the look-controls component is added to mimic a 3DOF controller using HMD orientation,
similar to gaze-based cursors.

This component adds button mappings and events, but does not currently provide
a controller model since it is assumed that end users will use this indirectly
through higher level components such as the hand-controls component.

When used via hand-controls, as there is only one "Gear VR Touchpad",
currently this component will only bind to the right hand, not the left.

…if present. NOTE: Carmel currently defers sending the button down event, and doesn't send touches, so holding down the button to see where you're teleporting doesn't work

dmarcos

It feels weird to me to incorporate a touchpad as part of hand-controls. I have no idea how you're supposed to control your hands with 2 axis. I feel that the touchpad is more appropriate to be paired with a gazed based cursor. The application should detect if there are tracked controllers and if not used an alternative interaction method (e.g: gazed based cursor) that better adapts to the capabilities of the device

dmarcos · 2016-12-18T08:25:59Z

src/components/carmel-gearvr-controls.js

+ */
+module.exports.Component = registerComponent('carmel-gearvr-controls', {
+  // since aframe-teleport-controls looks for tracked-controls, add one
+  dependencies: ['tracked-controls'],


the gearvr controls is just the trackpad on the headset right? I don't think it fits in the tracked-controls models.

+1, but at a higher level, would this make more sense in the registry vs core? I think it's valuable to include, in either case.

Also wondering if the name (and functionality) could be broader than carmel and gearvr. Assuming this is purely using gamepad API, this could be trackpad-controls or dpad-controls.

right, it is not a tracked-controls really, it only has a stub of that because others like aframe-teleport-controls are looking for entities with that label. it makes hand-controls allow gaze-based usage on Carmel, so that things like aframe-teleport-controls can just reference hand-controls and not worry about specific implementation. if you try https://chenzlabs.github.io/aframe-teleport-controls/mesh/ with Carmel you can see what I mean (swipe and hold, then release).

@donmccurdy i agree this could be more generic like touchpad-controls if the behavior were consistent across browsers (not just Carmel) and controllers (not just Gear VR Touchpad), but it is not clear that is the case. happy to rename if that helps.

would this make more sense in the registry vs core?

hand-controls is in core, so AFAIK the only way to make it understand something else is in core...

renamed to gearvr-controls and added support for Samsung Internet GearVR. (The test scene I use looks low-res in that browser for some reason, but the functionality works as expected.)

dmarcos · 2016-12-18T08:26:33Z

src/components/carmel-gearvr-controls.js

+  dependencies: ['tracked-controls'],
+
+  schema: {
+    hand: {default: 'right'},


It feels weird to assign a hand to the trackpad

that is for compatibility with hand-controls only

machenmusik · 2016-12-18T16:02:58Z

The application should detect if there are tracked controllers and if not used an alternative interaction method (e.g: gazed based cursor) that better adapts to the capabilities of the device

Yes, this gets back to some of the original conversation on #2124 and #2132.

These changes allow applications to do that easily by using hand-controls='right', rather than having to explicitly include all of oculus-touch-controls, vive-controls and carmel-gearvr-controls and handle them separately which is tedious and scales poorly (what are they supposed to do with Daydream then)?

And rather than having a well-known component responsible for figuring out which controllers are attached and only injecting the right one(s) -- that was auto-detect-controllers -- since you guys specifically rejected that approach in core previously, but then we still have higher level like hand-controls in core so people can use "out of the box" rather than having to go hunt everything down in the registry.

machenmusik · 2016-12-18T16:22:07Z

I have no idea how you're supposed to control your hands with 2 axis. I feel that the touchpad is more appropriate to be paired with a gazed based cursor.

@dmarcos I just realized, you may not have understood from the description that this is basically what the PR does -- modified the description to make it more obvious that for Carmel GearVR, it is look-controls and HMD orientation that is used for controller pose, not the 2D position from the touchpad.

dmarcos · 2016-12-19T20:30:38Z

I think hand-controls should just be exclusive to tracked-controls. Other method inputs should map to different interaction models that are not hands. A gamepad or the gear VR touchpad should map to a controls schema other than hand-controls: a gaze based interaction for instance

machenmusik · 2016-12-20T00:48:48Z

IMO, there's no particularly good reason why hand-controls needs to be exclusive. For zero-DOF controllers like GearVR, the hand position and pose can be emulated from player position and HMD (gaze), and the hand model as visual representation and pointing animation can still be retained. For 3DOF like Daydream, the hand position can be emulated from player position, and the actual controller orientation can be used.

As previously discussed, I think most of this comes up because hand-controls is in core and serves as showcase example as well. If you'd like a switch to enable/disable emulation, that makes sense to me...

ugh, but I forgot that the hand-controls schema has nowhere to put a switch at present :-/

dmarcos · 2016-12-20T00:59:40Z

I want to keep hand-controls simple and exclusive to tracked-controls. The tracked-controls demo (walking and reaching objects out with your hands) is not a very good experience with GearVR or a Daydream control. For experiences that use just pointing at targets I can see a 3DOF controls to be used but for GearVR you probably want something different than emulating a hand with your gaze. You're idea of responsive controls is really worth exploring and probably an excellent addition to the registry. We're trying to keep the core as nimble and simple as we can with pieces that are highly reusable and not very opinionated.

machenmusik · 2016-12-20T01:12:36Z

So as things stand there are no examples of what to do with A-Frame on GearVR (and Daydream), I agree with your statement that the tracked-controls example really calls out for Touch and/or Vive controllers, but I think https://chenzlabs.github.io/aframe-teleport-controls/mesh/ shows that the hand-controls component can still be useful in other situations. It sounds as though you are asking those looking to support the most numerous VR platforms by far to go outside A-Frame, rather than also having examples of how to use non-tracked controllers as part of A-Frame.

machenmusik · 2016-12-20T01:16:24Z

Maybe all that needs to change here to accommodate your perspective is that hand-controls should not inject gearvr-controls -- but this code should still exist in core; if one wants to allow GearVR emulated hand control, then simply do <a-entity hand-controls="right" gearvr-controls> (or left) -- and if not, gearvr-controls is available to be leveraged directly.

If you agree, I will happily make that simple change

dmarcos · 2016-12-20T01:23:39Z

Also I'm not sure if a gearvr-controls makes sense. At the end of the day it's just one kind of gamepad. The same as the x-box or a PS gamepad. Maybe a gamepad-controls makes more sense. One could register mappings for different gamepads. This could also simplify tracked-controls to just handle the pose changes.

machenmusik · 2016-12-20T01:29:48Z

right now the mouse/touchpad emulation is activated for GearVR when using Samsung Internet VR browser, and there is specific hackery to leverage the Carmel gamepad mapping. The first could be made more generic like the auto-enter discussion, but the second probably shouldn't be. are you suggesting splitting those into two components?

dmarcos · 2016-12-20T01:44:47Z

right now the mouse/touchpad emulation is activated for GearVR when using Samsung Internet VR browser, and there is specific hackery to leverage the Carmel gamepad mapping

This is why I push back on this kind of changes. I want to minimize the liabilities in the core. We don't have the resources to pay close attention to each browser, version and device to adapt the code to all the quirks (specially for those in experimental phase). The reason of having the registry is:

Enable permission less innovation where multiple solutions to a problem can coexist and compete.
Having a community that helps provide all the functionality that we don't have the resources to develop and maintain.

The core team will make its best to facilitate the conversation and create a system for people to share, discover and use those components.

dmarcos · 2016-12-20T01:49:40Z

src/components/gearvr-controls.js

+ * For Samsung Internet GearVR browser, it uses mouse and touch events
+ * to simulate appropriate Gamepad behavior.
+ */
+module.exports.Component = registerComponent('gearvr-controls', {


I would definitively add this component to the registry

…scussion on PR

machenmusik · 2016-12-20T01:57:30Z

OK, but even with gearvr-controls moved out of core, the other small changes (e.g. use !isOculusTouch rather than isVive) are needed for compatibility. I will close this one, and make a separate PR for the compatibility changes without the GearVR controls.

machenmusik · 2016-12-20T01:59:44Z

(the gamepad-controls comment is interesting though, as it makes the case to include emulated tracking in core to accompany them, for responsive controls more generically supported)

machenmusik added 4 commits December 18, 2016 03:03

The Carmel 'Gear VR Touchpad' will be bound to hand-controls="right" …

174b8d0

…if present. NOTE: Carmel currently defers sending the button down event, and doesn't send touches, so holding down the button to see where you're teleporting doesn't work

works well with teleport; currently hardcoded to bind to right hand only

3562070

added documentation, and changed default to right hand

92c7de1

added tests, fixed typo

217f7e6

dmarcos reviewed Dec 18, 2016

View reviewed changes

machenmusik changed the title ~~Support carmel controller 0.4.0~~ Dec 18, 2016

machenmusik added 2 commits December 19, 2016 13:43

support Samsung Internet GearVR browser; rename to gearvr-controls

01d1bbf

don't apply controller offset if not present

c5ce999

dmarcos reviewed Dec 20, 2016

View reviewed changes

don't inject gearvr-controls automatically from hand-controls, per di…

40e9b6c

…scussion on PR

machenmusik closed this Dec 20, 2016

This was referenced Dec 20, 2016

Compatibility changes to 0.4.0 for separate gearvr controller component #2192

Merged

Separate gearvr controller 0.4.0 chenzlabs/aframe#20

Merged

rzr mentioned this pull request Mar 19, 2019

Support touch move events of gearvr controller chenzlabs/gearvr-controls#3

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Support Gear VR Touchpad controller 0.4.0 #2183

Support Gear VR Touchpad controller 0.4.0 #2183

Uh oh!

machenmusik commented Dec 18, 2016 •

edited

Loading

dmarcos left a comment

dmarcos Dec 18, 2016

donmccurdy Dec 18, 2016

machenmusik Dec 18, 2016 •

edited

Loading

machenmusik Dec 18, 2016

machenmusik Dec 18, 2016

machenmusik Dec 18, 2016

dmarcos Dec 18, 2016

machenmusik Dec 18, 2016

machenmusik commented Dec 18, 2016

machenmusik commented Dec 18, 2016

dmarcos commented Dec 19, 2016

machenmusik commented Dec 20, 2016 •

edited

Loading

dmarcos commented Dec 20, 2016

machenmusik commented Dec 20, 2016

machenmusik commented Dec 20, 2016 •

edited

Loading

dmarcos commented Dec 20, 2016

machenmusik commented Dec 20, 2016

dmarcos commented Dec 20, 2016

dmarcos Dec 20, 2016

machenmusik commented Dec 20, 2016 •

edited

Loading

machenmusik commented Dec 20, 2016

Labels

3 participants

Uh oh!

Support Gear VR Touchpad controller 0.4.0 #2183

Support Gear VR Touchpad controller 0.4.0 #2183

Uh oh!

Conversation

machenmusik commented Dec 18, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

dmarcos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

machenmusik Dec 18, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

machenmusik commented Dec 18, 2016

machenmusik commented Dec 18, 2016

dmarcos commented Dec 19, 2016

machenmusik commented Dec 20, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

dmarcos commented Dec 20, 2016

machenmusik commented Dec 20, 2016

machenmusik commented Dec 20, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

dmarcos commented Dec 20, 2016

machenmusik commented Dec 20, 2016

dmarcos commented Dec 20, 2016

Choose a reason for hiding this comment

machenmusik commented Dec 20, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

machenmusik commented Dec 20, 2016

Labels

3 participants

machenmusik commented Dec 18, 2016 •

edited

Loading

machenmusik Dec 18, 2016 •

edited

Loading

machenmusik commented Dec 20, 2016 •

edited

Loading

machenmusik commented Dec 20, 2016 •

edited

Loading

machenmusik commented Dec 20, 2016 •

edited

Loading