poll: true breaks cardboard button usage

[kylebakerio]

And possibly other stuff too, though I haven't found any other issues yet somehow?

The problem is here:

    play: function () {
        let sceneEl = this.el.sceneEl;
        if (this.data.poll) {
            this.updateControllers({});
            sceneEl.addEventListener('controllersupdated', this.updateControllers);
        } else {
            this.addSessionEventListeners();
            sceneEl.addEventListener('enter-vr', this.addSessionEventListeners);
        }
    },
    

Basically, this.addSessionEventListeners() never gets called--either at initialization, or upon entering VR. So, no listening for select-start and select-end happens, which is how the gaze psuedo-controller reports screen touch.

I've added a manual call to addSessionEventListeners(); and that does indeed make it work on cardboard with the cardboard button, but I don't know if that breaks anything else yet--I'll go test that now. After some more testing, I'll probably offer a pull request.

[kylebakerio]

So, testing with the quest now, I see that grip buttons seem to count as 'double clicked'. I assume that applies to grip and trigger buttons, and that they're basically being caught by the poll + non-poll mechanisms now.

This means the correct answer is probably fixing a bug in the polling code itself.

The bug I was experiencing there was that a 'button down' for the gaze controller was firing as soon as I started an xrSession (started VR mode), but never a button up, and never any registered clicks after that point. I'll dig deeper on how to use that 'properly' and fix the real problem there, now that I understand how the code flow works here.

[kylebakerio]

        if (inputSource && inputSource.gamepad) {
            gamepad = {
                id: inputSource.gamepad.id,
                buttons: inputSource.gamepad.buttons
            }
        } else {
            gamepad = {
                buttons: [{pressed: true, value: 0.75}, {pressed: false, value: 0.25}]
            };
        }

This is clearly the problem. inputSource.gamepad is undefined. As a result, you just get what I described--these two buttons always locked on. This seems to be an unfinished code path with a dummy hard-coded value just thrown in.

[kylebakerio]

Alright, hacked in the update. I tested it with an oldschool gamepad in cardboard, with the 'cardboard button', and with the quest 2, seems to all work now. Will make a pull request.

[Seeingred0]

Thanks for digging into this! I've seemed to of got it working here in a glitch - https://glitch.com/edit/#!/cardboard-button

However I think there needs to be some logic changes to include a tick function for cardboard VR navigation right? I think we cannot add a tick function to that component whilst we're using play: and pause:

Also worth noting, looks like Chrome / Android don't like A-Frame 1.1.0, it makes you go in/out of VR mode twice to get the display working. 1.2.0 don't have these problems.

[kylebakerio]

I'm currently back to using 1.0.4 in my project, as I had too many conflicts with various libraries when 1.2.0 was new. I do want the hand tracking functionality of 1.2.0, and I think many of those libraries have updates now, so eventually I do want to update. (There were some issues with 1.1.0, I recall, 1.2.0 came relatively quickly after it.)

Cardboard VR button is working for me with this fork in my project in 1.0.4. I'm not sure what you mean by "cardboard VR navigation", but the story is:

1. before my pull request a few days ago, you could get the cardboard button working if you did not enable poll=true. When you don't use poll=true, you don't use the tick() function in the library, and it's instead event-driven, as far as I can tell. This, however, doesn't give you access to all the buttons on the controllers.

2. after my pull request, poll=true will now work with the cardboard button as well, and it does this by simulating a psuedo-cardboard-controller to match the new style that can be observed in the tick() function like other webXR controllers. It takes the selectstart event and selectend event, and if it detects them and detects that they were from the gaze psuedo-controller generated by the browser, updates the psuedo-controller that can then be analyzed by that tick() function in the library like other controllers.

[kylebakerio]

Basically, when poll=true, the tick() method is being used, always. My update allows the tick() method to see updates to the psuedo-controller, which I make updates to based on the selectstart/selectend events.

think we cannot add a tick function to that component whilst we're using play: and pause:

I'm not sure what your point is here or why this matters. I haven't checked, but my intuition is definitely that pause would cause the tick() to stop running.

[Seeingred0]

Got it! Managed to get it working with a click button. Next up trying to figure out how to transverse across the scene whilst button is held down!

[kylebakerio]

https://github.com/n5ro/aframe-extras/tree/master/src/controls

'touch controls' implements this style of movement for non-cardboard mobile usage, btw. but it would also be pretty straightforward to implement this yourself--the component in the docs that is used to teached you how to use the tick handler to have something follow you shows how to approach the problem.

Just adapt it to move the camera rig instead of some other object, and add an event listener for your new button, and voila.

[Seeingred0]

Nice, thanks for that! I managed to find a way to implement touch when on chrome VR without the library. Also added movement to the tick function to move in the direction of the camera.

The only issue I'm seeing now is that it looks like when you use camera.object3D.position it then overrides the nav mesh constraint via movement-controls. If I can get this fixed it'll be the ideal work around for android users - https://glitch.com/edit/#!/nav-mesh-testing

[kylebakerio]

Probably more consistent to just call the existing 'move forward' function within movement-controls, firing upon your own custom event triggered by the cardboard button, imo. Then it should just 'play nice' with everything else, e.g. navmesh. But if you want to keep going that route, I'm sure you can find a way.