Skip to content

Conversation

@machenmusik
Copy link
Contributor

@machenmusik machenmusik commented Mar 22, 2017

Per discussion on #2423, this PR separates the axismove changes and omits the emulated property.

This PR extends #2413 / #2415 to oculus-touch-controls as thumbstickmoved, and also addresses spurious axismove events discussed in #2423.

@machenmusik
Copy link
Contributor Author

@cmvanb - we decided to close #2423 in favor of this PR, which should have the same benefits

| Aup | A button released. |
| Atouchstart | A button touched. |
| Atouchend | A button no longer touched. |
| Achanged | A button changed. |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we make all the event names lower case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the ones that correspond to buttons A, B, X, and Y are uppercase for clarity because that is the way the button labels are always used, IMO don't think we should lowercase them? worried about namespace collisions too. Note the existing support is the same way...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done and also propagated into #2446

@dmarcos
Copy link
Member

dmarcos commented Mar 23, 2017

Our event names don't have uppercase. Can we keep them lower cased?

@dmarcos
Copy link
Member

dmarcos commented Mar 23, 2017

we could do abuttonchanged

@machenmusik
Copy link
Contributor Author

buttonchanged is a slightly different but used event; personally not in favor of abuttonup, abuttonchanged, bbuttonchanged, etc. due to being too close to the separately used buttonup, buttonchanged, etc. -- but it is of course technically possible by changing mappings here and also in #2446.

@machenmusik
Copy link
Contributor Author

@dmarcos @ngokevin any more thoughts on this one? hoping to get #2446 in as well, but this one first.

interested in outside perspectives on backward compatibility (whether the event names change is problematic for existing usage) -- I think right now most things use trigger / thumbstick / grip which aren't changing.

'right': {
axis0: 'thumbstick',
axis1: 'thumbstick',
axes: {'thumbstick': [0, 1]},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer to have axis + index instead of an array for consistency with buttons

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes processing harder e.g. you can't just do buttons.forEach ... i would argue we should change buttons to array for consistency instead.

Copy link
Contributor Author

@machenmusik machenmusik Mar 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so like axes, buttons could be a keyed map of either singletons or arrays (if aliased)
buttons: { thumbstick: 0, ... }
or if you prefer, one of:
buttons: { 0: 'thumbstick', ...}
or
buttons: ['thumbstick', ...]

really this:
var buttonName = this.mapping[this.data.hand]['button' + id];
should look like
var buttonName = this.mapping[this.data.hand].buttons[id];

more readable IMO

@machenmusik machenmusik force-pushed the axismove-for-touch-and-vive branch from e988b4f to f0b3309 Compare March 24, 2017 20:26
// touch events aren't happening (touched is stuck true);
// synthesize touch events from very low analog values.
analogValue = evt.detail.state.value;
isPreviousValueEmulatedTouch = this.isEmulatedTouchEvent(this.previousButtonValues[button]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Touch is going to be supported soon in Firefox. I would prefer to wait for the implementation to land rather hand handling the quirks that we are going to remove soon.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Touch is supported in Nightly, see #2446

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this touch emulation a good idea from the UX perspective? Can we move it to a separate PR?

Copy link
Contributor Author

@machenmusik machenmusik Mar 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that code is not new. it's already in. (if you look more carefully at the changes, the prior early-return is changed so the buttonchanged event fires properly, and some comments are capitalized.)

whether it is still needed depends in part on the Nightly button/axis mapping, which we should probably discuss in #2446

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update: the 2017-03-22 build of Nightly makes Touch mapping compatible with Chromium, so #2446 is no longer required. Also, Nightly provides analog value for all buttons, so we do in fact need this emulated touch code (e.g. to make hand-controls work correctly) since Nightly does not otherwise provide capacitive touch events.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked our Firefox devs what's the ETA for the touch events. This will be coming soon so I would try to get rid of the hack and wait for Firefox to catch up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

according to @ngokevin there are cases where analog values have very small nonzero values, which may still need functionality similar/identical to this...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We filed bugs about making the threshold configurable in Firefox to address the small values.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can get rid of all the emulated touch logic since Firefox is already supporting touch events.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On oculus touch controllers I believe the touch flag should be independent of the button value since they have a capacitive surface.

var data = this.data;
var isPresent = this.isControllerPresent(this.el.sceneEl, GAMEPAD_ID_PREFIX, { hand: data.hand });
var isPresent = false;
var whichControllers;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can do in one line var whichControllers = ...

@ngokevin ngokevin added this to the 0.6.0 milestone Mar 30, 2017
@machenmusik machenmusik force-pushed the axismove-for-touch-and-vive branch 3 times, most recently from 19b7e9b to b2f7242 Compare April 7, 2017 20:55
@dmarcos
Copy link
Member

dmarcos commented Apr 11, 2017

I'm a bit lost with all these PRs. What does this one includes?

@machenmusik
Copy link
Contributor Author

axismove events similar to #2413 / #2415 for oculus touch (prior commits were vive specific, which frankly we should really avoid where possible in future...)

@machenmusik
Copy link
Contributor Author

This PR extends #2413 / #2415 to oculus-touch-controls as thumbstickmoved, and also addresses spurious axismove events discussed in #2423.

this.addControllersUpdateListener();
this.addEventListeners();
window.addEventListener('gamepadconnected', this.onGamepadConnectionEvent, false);
window.addEventListener('gamepaddisconnected', this.onGamepadConnectionEvent, false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do window.addEventListener('gamepaddisconnected', this.checkIfControllerPresent, false);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see below comment on the everGotGamepadEvent flag

this.onGamepadConnected = bind(this.onGamepadConnected, this);
this.onGamepadDisconnected = bind(this.onGamepadDisconnected, this);
this.onAxisMoved = bind(this.onAxisMoved, this);
this.onGamepadConnectionEvent = bind(this.onGamepadConnectionEvent, this);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get rid of this since we can do window.addEventListener('gamepaddisconnected', this.checkIfControllerPresent, false);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see below comment on the everGotGamepadEvent flag

// apparent issue with FF Nightly only sending one event and seeing one controller;
// this.everGotGamepadEvent = true;
// this.removeControllersUpdateListener();
onGamepadConnectionEvent: function (evt) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get rid of this method

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see below comment on the everGotGamepadEvent flag

// this.everGotGamepadEvent = true;
// this.removeControllersUpdateListener();
onGamepadConnectionEvent: function (evt) {
this.everGotGamepadEvent = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This flag is never checked

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can see why in the comments, but yeah we can remove them for now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually it is checked in onControllersUpdate (which last I recall is actually fired every tick). so the idea is that if you got gamepad connect/disconnect events, you don't always need to be checking to see when it shows up

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have to set the flag to false on gamepaddisconnected?

Copy link
Contributor Author

@machenmusik machenmusik Apr 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no because we expect gamepadconnected next time since we're getting events, right? so we don't need to poll every tick

// apparent issue with FF Nightly only sending one event and seeing one controller;
// this.everGotGamepadEvent = true;
// this.removeControllersUpdateListener();
onGamepadConnectionEvent: function (evt) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get rid of this method and do window.addEventListener('gamepaddisconnected', this.checkIfControllerPresent, false);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the question is whether we should restore the check in onControllersUpdate (don't look for touch controllers every tick the controllers list is updated), which would probably be more efficient

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added the check in onControllersUpdate to match the other controller types.

@machenmusik
Copy link
Contributor Author

machenmusik commented Apr 12, 2017

summing up recent comments - in daydream-controls, everGotGamepadEvent is in fact used in onControllersUpdate, which is more efficient. oculus-touch-controls was not and so was checking for controller presence every tick, so changed it to stop doing that if everGotGamepadEvent (like the other controllers).

add axes mapping, axismove handler and emulated property, as well as tests

add emulated property to docs

accommodate temporary Nightly issue where Touch is supported but has lowercased handedness in id string

Pass along changed event with button state, using the buttom mapping for convenience.

pass along axis changed flags from tracked-controls, and check them in oculus-touch-controls and vive-controls to avoid spurious axis moved events

add update comment per discussion on PR

fix typo

for compatibility, if no changed array for axismove event, treat as changed

map to forEach, per discussion on PR

remove emulated property per discussion

change button names so events are lowercase
@machenmusik machenmusik force-pushed the axismove-for-touch-and-vive branch from c6ff814 to 16ba6de Compare April 14, 2017 17:56
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 14, 2017
@machenmusik machenmusik force-pushed the axismove-for-touch-and-vive branch from 985a871 to 16ba6de Compare April 14, 2017 17:58
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 14, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 14, 2017
@machenmusik
Copy link
Contributor Author

Since #2545 was merged first, I've incorporated the salient aspects of #2588 here now per discussion.

@dmarcos
Copy link
Member

dmarcos commented Apr 16, 2017

Thanks!

@dmarcos dmarcos merged commit 2827f9c into aframevr:master Apr 16, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 17, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 17, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 18, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 18, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 21, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 21, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 21, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 21, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 24, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 24, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 25, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Apr 25, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request May 25, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request May 25, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Jun 22, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Jun 22, 2017
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Jun 22, 2017
disable everGotGamepadEvent usage, seeing issues with latest Nightly

make sure vive-controls doesn't match tracker

bring in line with latest aframevr#2513

work around Nightly bug to get both controllers and trackers working at the same time

bring vive-tracker in line with aframevr#2513

fix tests

per separate discussion, use controllers list from system not getGamepadsByPrefix

bring in line with aframevr#2505

make sure that queryObject values are used even if falsy e.g. index 0

tracked-controls needs to know about hand to filter properly and find vive trackers, given current Nightly bug.  since empty string is always changed to default value (even when default is undefined), need to use 'none' to indicate empty-string hand

re-clone tracker tests from controls

use newly committed vive-tracker model

add rotation property, which applies if no rotationOffset and allows full 3DOF rotation

correct pose orientation for tracker to be what is generally expected of controllers

fix default vive-tracker rotation correction, per discussion

updateControllerModel for all tracked controls components; use fixed vive tracker model until published to CDN

use new tracker model from CDN

add rotation parameter

apply rotationOffset the old way, to avoid precision issues

add rotation offset test, with EPSILON

change sentinel hand value to avoid node test failure

zero pivot point

update tracked-controls hand docs per discussion on PR

fix duplicate play/pause presumably from botched merge
machenmusik added a commit to chenzlabs/aframe that referenced this pull request Jun 22, 2017
disable everGotGamepadEvent usage, seeing issues with latest Nightly

make sure vive-controls doesn't match tracker

bring in line with latest aframevr#2513

work around Nightly bug to get both controllers and trackers working at the same time

bring vive-tracker in line with aframevr#2513

fix tests

per separate discussion, use controllers list from system not getGamepadsByPrefix

bring in line with aframevr#2505

make sure that queryObject values are used even if falsy e.g. index 0

tracked-controls needs to know about hand to filter properly and find vive trackers, given current Nightly bug.  since empty string is always changed to default value (even when default is undefined), need to use 'none' to indicate empty-string hand

re-clone tracker tests from controls

use newly committed vive-tracker model

add rotation property, which applies if no rotationOffset and allows full 3DOF rotation

correct pose orientation for tracker to be what is generally expected of controllers

fix default vive-tracker rotation correction, per discussion

updateControllerModel for all tracked controls components; use fixed vive tracker model until published to CDN

use new tracker model from CDN

add rotation parameter

apply rotationOffset the old way, to avoid precision issues

add rotation offset test, with EPSILON

change sentinel hand value to avoid node test failure

zero pivot point

update tracked-controls hand docs per discussion on PR

fix duplicate play/pause presumably from botched merge
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants