Not sure if this is possible with device orientation input but I’ve been struggling trying to work with DeviceOrientationCamera.resetToCurrentRotation() and _initialQuaternion etc for my use case. Then I thought that what I’m really seeking is simply a “relative” mode for DeviceOrientationCamera, and given we have a target inherited from TargetCamera, it could be relative to this existing property (which I think isn’t actually used for DeviceOrientationCamera at present?). This makes conceptual sense to me, assuming it’s even possible.
So, if I create a “relative” DeviceOrientationCamera with a target, then all camera movement is relative to that target rather than simply being the unpredictable absolute orientation input from whatever device is in use.
Is this a possibility? I know we can’t get a consistent, predictable “bearing” across devices from the device orientation api alone, but it’d be good if we had the option to set an arbitrary bearing i.e. target, that all subsequent device orientation input is relative to.
It’s a question that’s been raised a few times by various people in different ways which makes me think that my confusion or misunderstanding on the subject is shared and maybe there’s an easier approach?
If you require to change a private variable for it to work (i.e. _initialQuaternion) then we are doing something wrong.
I am just not 100% sure what the anchor is that you want to attach the camera to. Is it an object in the scene? or an anchor in the real world? I assume it is the first one, but I need to understand how you expect it to work. Let’s say there is an object positioned in 0,0,5 (i.e. 5 units “forward” in world space). Will you set the camera to target this object? would you expect the camera to have its initial rotation looking at this object?
Yes, the first option, an object in the scene, but in our use case that 3D object represents a real-world object we assume the visitor is standing directly in front of.
Our project is a real world sculpture. The visitor scans a QR code in front of the sculpture to launch the experience and it’s important that the 3D representation of the sculpture is roughly in the same place as they’re moving their device around. Again, we make the assumption the visitor is standing directly in front.
i’ve just been unable to get consistent results across devices to ensure the 3D sculpture starts in front of the user.
A viable solution has alluded me up until this point as this area is not my strong suit.
I had another look at the Babylon.js code. Maybe I could set a new property _initialAlpha in FreeCameraDeviceOrientationInput._deviceOrientation() then use that to make subsequent alpha values relative to a user specified heading/bearing. It’s alpha that’s important here - beta and gamma don’t matter. Do you think this is an OK approach?
we usually don’t recommend using underscroe-variables, which are considered to be either hidden-public or private, and are not backwars compatible. Having said that - there is no public method/parameter can solve this alone, so it seems.
If it works, use it. I am sorry for not suggesting to solve this myself, I am just packed with work at the moment. I will try finding time to dive into the code, but can’t promise anything
and knows way more than me about the Device Orientation Camera