resetToCurrentRotation() is called on pointer up. This works great for mobile devices that support device orientation input, but results in uncontrollable spinning on devices that don’t e.g. desktop with mouse input.
Is there a way to detect the input mode and avoid calling resetToCurrentRotation() or avoid spinning on unsupported devices like desktop with mouse input?
Don’t know where this PG comes from, but there are already 2 (unhanded) cameras in the scene for this second PG (speaking scene, mouse and desktop side). No wonder it goes haywire with this treatment.
A calmer version for a desktop/mouse use…
‘https://www.babylonjs-playground.com/#12WBC#1041’
Thanks @mawa but that doesn’t quite answer my question. I may have confused things by adding the second PG. The first PG only has a single DeviceOrientationCamera which falls back to free camera operation if no device orientation input is available. When calling resetToCurrentRotation() on that camera on desktop with mouse, it spins uncontrollably.
So my rephrased question would be, how can I prevent this spinning on DeviceOrientationCamera.resetToCurrentRotation() when it’s operating as a free camera i.e. without device orientation input?
In my full application I have multiple cameras, an ArcRotateCamera and a DeviceOrientationCamera, and I need to call resetToCurrentRotation() on the latter without it causing problems on desktop.
Yes, I thought it would not provide the complete answer. I just needed a calmer version because the original one was giving me a headache;) To be honest, I do not really understand this prototype version (what it does or what it’s supposed to do). An expert would have to give you the answer.
However, I do have a scene (for the time, desktop only) with multiple camera types, a GUI, a 3D GUI and post-process and for one thing I know, you have to be careful with how you attach/detach controls and cameras. I guess you also checked this PG:
I realize there is little in the doc about the DeviceOrientationCamera and then, this feature has also undergone a lot of changes overtime. I find it even hard to determine the old PGs from the more actual/workable versions.
I guess I shall call in @Evgeni_Popov and @PolygonalSun once more on your case (and will also happily soak up the input;) since I will likely want to add such a cam for the mobile version of my scene.
It shouldn’t be too long…just hold’on
I made another PG (https://www.babylonjs-playground.com/#12WBC#1053), this time taking great care to attach/detach controls etc, but the same uncontrollable spinning occurs on calling resetToCurrentRotation() on desktop with mouse inputs, if the user has rotated away from initial orientation.
I’m obviously misunderstanding something … just not sure what exactly.
And I also tried completely disposing of and recreating the DeviceOrientationCamera when reset button is clicked, which eliminates the uncontrollable spinning on desktop BUT then the initial orientation isn’t reset correctly on mobile (it flashes to the initial orientation but then immediately snaps back to the previous device orientation input).
I read the thread once more this morning, 'realized that I wasn’t even sure of what you are trying to achieve. What is the initial ‘orientation’ or ‘rotation’ or ‘target’ for your active camera. I’m afraid I don’t really understand the entire scenario and the playgrounds featured, well, I don’t know what they do exactly… for me, on mobile (iphone for now) they mostly do nothing…but then, all I have is a gray, green or red cube with no axis or anything. So, I guess the question is what exactly is supposed to rotate or orientate or return to some (undefined) initial position/rotation/orientation on pressing reset? or will there be a reset button at all? Could you may be schematize or better describe the scenario somehow; may be this would help the experts (or myself) provide a better/faster answer to your problem?
Ideally what I wanted was to use DeviceOrientationCamera to match the position and orientation of a real-world object, that the user is standing in front of, with a model in the 3D scene, but different mobile devices implement device orientation input in different ways, so there’s no easy way to get an absolute, say true north, heading consistently across all devices.
So the next best option for my use case is to assume the user is facing this real-world object (there wil be instructions to that effect) and reset the initial/starting orientation of the DeviceOrientationCamera to point at the 3D model.
In the linked solution above, @RaananW suggested I try resetToCurrentRotation() to do this, which works when device orientation is enabled, but when permission is denied by the user (iOS requires a permissions step) or device orientation is not supported (e.g. desktop) then this uncontrollable spinning results when I call resetToCurrentRotation().
So, I basically I just need to know how I can seamlessly support both user/device scenarios - either detect when device orientation input is being used and only call resetToCurrentRotation() in that case, or call resetToCurrentRotation() in such a way that it doesn’t create this spinning on desktop.
Right. Now I think I get it. May be could have started with this to get a faster reply (i.e. from @RaananW).
Your fix should be just around the corner now (hopefully)
@RaananW I’m really sorry to bug you again, but I think I spoke too soon. After more testing of FreeCameraDeviceOrientationInput.WaitForOrientationChangeAsync() on desktop (Windows Chrome & Edge) it’s still spinning. The promise seems to always be fulfilled, whether device orientation input is available or not. Probably I’m misusing it.
See PG:
Strangely enough …
on Mac Chrome the promise is (correctly) rejected but the rejected callback isn’t called.
on Windows Chrome & Edge the promise is (incorrectly) resolved but error also results!?
Sorry all. Marking this as solved again. Thanks for your patience. I can’t get correct behaviour on Windows chromium based browsers but it seems it’s just the one machine. No one else I’ve asked to test this can replicate the behaviour I’m seeing on my machine and it also works fine on my Macs, Android and iPhone … so it’s just one of life’s great mysteries.
So, in fine, you checked this on MacOS, iOS and Android (common browsers). What about the chome/chromium on bootcamp/WIN? I could check it for you (or else, I believe you can since you have a mac, obviously;). What is you latest PG?