Keyboard and mouse control of UniversalCamera have worked in the past, but have recently stopped working correctly (from the Playground testing I can only say it worked in 4.x latest but does not in latest 5.x - side note, it would be helpful to be able to select a specific version among the released 5.x versions too). Now the keyboard control has no effect on the camera and the mouse control acts differently, i.e. it keeps spinning if you move it to the edge of the screen, whereas in Firefox/Chrome, the camera moves only as much as the mouse does (+ the keys work).
Update: The example in the docs where the camera controls are basically build from scratch - that one still works as intended: https://playground.babylonjs.com/#CTCSWQ#1
According to @PolygonalSun it looks like it might be related to camera.inputs.attached.mouse.touchEnabled = true; which is kind of a relief as it does not break the default case and he should have a fix for this one soon.
I just wanted to provide an update to this as well. From what I’m seeing, if you go to the PG and just click on the canvas to provide it with focus (without any mouse rotation), the keyboard will still work. It stops working once the camera has rotated. Furthermore, in the move code, it looks like something is messing up the camera’s cameraDirection vector that controls how much to move it. I’m still searching for the root cause but I just figured I’d give an update.
Update: I found the root cause. The issue actually happens when touchMoveSensibility is 0. Because of how we initialize the local direction vector in the checkInputs function of freeCameraTouchInput.ts, we have the potential for a divide by zero issue which will break cameraDirection and render movement useless. The fix is super simple so I should have a PR up shortly after I verify that there are no additional side effects on other browsers. Great find @jure!
This resolves the issue of keyboard navigation, which is the primary one described in the initial post (and also the more breaking one), but the difference in mouse look/navigation remains.
Check this example with the code from the PR:
Click and drag with the mouse in Safari and e.g. Chrome or Firefox and notice the different behaviour. In Chrome and Firefox the camera rotation stops soon after the mouse movement stops, whereas in Safari the rotation keeps going.
Just to clarify, this did not use to be the case, as can be verified by using an older branch, e.g. from Apr 29:
Thanks @PolygonalSun! I wouldn’t be surprised if the root cause of both of these issues is the same, and is somehow centred around mistakenly enabling certain touch modalities in the controls.
I’m working on finding the root cause but from what I’ve found, it’s using the UniversalCamera’s Touch controls as the primary input method for mouse, as opposed to other browsers which are using the mouse controls. I suspect that there’s some condition that isn’t getting properly evaluated for Safari. When I have a better idea of what we’re working with, I’ll update this thread.
Here’s what I’ve got. The reason for this behavior is that isMouseEvent in FreeCameraTouchInput.ts is incorrectly evaluating mouse events in Safari. Because of this, isMouseEvent is evaluated as false and the code that would normally return before executing touch code is actually being run. I’ve created a PR that fixes this logic for Safari while preserving the logic for other browsers.