Previously, on mobile devices using touch to rotate a UniversalCamera, if you dragged your finger to the edge of the screen and held it there, the camera would keep rotating until you released it. Pretty handy for making big turns.
Starting with 5.0.0-beta.2, the camera now stops rotating when your finger stops moving. It appears to have been this PR, which doesn’t explicitly mention this change in behavior.
Is this the new behavior to expect going forward?
Let me summon @PolygonalSun
Off of the top of my head, I’d imagine that the rotation should stop when finger movement stops to allow for precise movement (which reflects the new behavior seen). With the given PR, I’m not seeing anything that would suggest a change in behavior like you’ve described though. The only thing that I’m seeing is that there’s been added movement for the y axis. Just out of curiosity, would you be able to provide a PG that I could use to repro this and make sure that I’m understanding what’s going on?
With the given PR, I’m not seeing anything that would suggest a change in behavior like you’ve described though.
The conditions under which touch causes rotation on the y axis have changed. The x-axis rotation notably remains consistent pre- and post-beta.2 (no additional rotation at the edge of the screen), so that makes this the likely culprit.
You can observe the new behavior on the standard documentation PG: https://playground.babylonjs.com/#DWPQ9R#1
Don’t think there’s any way to load an older alpha release in PG, though.
Great suggestion from @gabrieljbaker - you can observe the old behavior on our production site right now, @PolygonalSun. https://framevr.io
Thanks for the PG and link. For the PG, 4.2 and 5.0 (both before and after that commit in the PR), appear to have the same behavior. When I went to the FrameVR page, it looked like the rotation behavior matched what I’ve seen with VirtualJoysticks. Do you use the VirtualJoystick class or some kind of custom virtual joystick implementation for touch input?
@PolygonalSun, let me know tomorrow if I should move the code back but the PR looked like it made sense 
This is so frustrating having you spend all this time doubting me on whether the problem even exists. Can you just give a definitive answer on whether you’re keeping this behavior so I know whether I need to extend the TouchInput class to restore the old behavior or wait for the resolution?
I’m sorry that this is frustrating. I just wanted to verify what factors were in play so that I could faithfully repro it and determine why it was occurring. That’s why I was asking about VirtualJoysticks and asking for a PG. I was able to get it to repro by adding a specific line though:
camera.inputs.addTouch();
The FreeCamera treats touch behavior similar mouse behavior so adding the touch specific input function call was what I was missing. As far as the answer to your question, I think that we need to revert that commit and redo the code without the change in behavior. I would recommend to wait for this change to happen and this thread will be updated when that revert occurs. @sebavan, would you be able to do the revert?
For anyone who want’s the old behavior back, extending FreeCameraTouchInput to override checkInput isn’t possible because too many props are private instead of protected, but you you can patch in the previous version of checkInput. See https://playground.babylonjs.com/#DWPQ9R#882
Revert is in PR:
Reverted Code Changes from PR 11697 by PolygonalSun · Pull Request #11799 · BabylonJS/Babylon.js (github.com)
PR is merged
Thanks @PolygonalSun!
@FrameVRWill @gabrieljbaker Sorry to get you in trouble, I just wonder maybe a flag in checkput or somewhere is needed for that? In my opinion, I just think it should stop rotating when it’s not a rotation camera, looking for your advice though, thanks~