[movement-controls] touch-controls not working when camera/rig is added dynamically

[neoklein]

In my a-scene I use orbit-controls for a first camera to show a kind of teaser for my model. When entering VR-Mode I add a camera rig and a second camera with movement-controls and set this camera to active.

On Oculus Quest the gamepad-control for the movement works but for Google Cardbox (with Iphone 6) I can't move with touch-controls (when setting the camery rig statically it works).

// First camera
<a-entity id="camera" camera position="0 1.6 0" look-controls orbit-controls="autoRotate: true; autoRotateSpeed: -0.05; target: 0 1.6 -0.5; minDistance: 0.5; maxDistance: 180; initialPosition: 0 0 5"></a-entity>

// Second camera
    <script type="text/javascript">
    document.querySelector('a-scene').addEventListener('enter-vr', function () {
     jQuery("#camera").after("<a-entity id='camerarig' position='0 0 10' movement-controls='fly: true'><a-entity id='vrcamera' camera position='0 1.6 0' look-controls></entity></entity>");
     document.querySelector('#vrcamera').setAttribute('camera', 'active', true);
    });
    
    </script>

To see it in action: www.neoklein.net/out-of-the-cave

Any idea what could be the problem?

Thanks for your great component!

[kylebakerio]

I actually just experienced this same problem. I would have pulled my hair out tracking it down, but luckily I had literally just added the camera switching method (same one as you) the day before, and then happened to be working on gamepad mode.

This was for me on desktop mode.

I'm using the latest aframe-extras (6.1.0) and A-Frame (1.1.0).

I just went ahead and removed my other camera for now, but it does make the load feel a lot messier. Hoping to get an oculus quest 2 in the next month, will have to test with that and see if it is only on cardboard or if it is there as well. It did apply to desktop for me too, though.

[kylebakerio]

Hey, I've been tracking down another bug that I think is of the same root as whatever caused this.

I'm still tracking it further, and would like to offer a pull request in the near future, but just in case--

many little things that seem like they shouldn't break this library, do, for me, and it is almost always traceable to the library losing track of the camera. I think this is just another thing that causes this weak behavior of the library to show up as an issue.

Try manually setting the camera via something like

rigEl.setAttribute('movement-controls',"enabled:true;"); // or however you choose to do it, this is roughly how I am
rigEl.components['movement-controls'].data.camera = cameraEl // check to make sure the property path is right, that's from memory

For me, that has temporarily seemed to fix a complex bug I had. Hopefully I can trace it down the rest of the way and do a pull request soon.

edit:

I've filed a more specific issue with a glitch illustrating what I believe is the problem, have to go to bed for now--but I wanted to add that I think the more consistent fix is to just always explicitly define the camera property. You might see if that fixes your issue.

[kylebakerio]

further comment: I added a pull request, you can see my proposed change there. In the meantime, though, just specifically specifying the camera when adding the movement-controls attribute instead of relying on it to auto-detect should work.

[vincentfretin]

From the discussion here and merged PRs, I think this is resolved? I'm closing it, if it's not the case please reopen.