Where does it takes its input from:
- device orientation event
- device motion event
- one of sensor api interfaces like absolute and relative orientation sensor api
- or geolocation by speed and heading data it yields
Where does it takes its input from:
I am not aware that this camera can change locations, only rotation. Here is the input source code: https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/Inputs/freeCameraDeviceOrientationInput.ts
Oh I mentioned geolocation api just for it can be used to determine the heading of the user probably assuming the heading will be in device held position if the user’s device has a non zero speed.
Read it. Ok it makes use of “deviceorientation” event, and “orientationchange” event which is deprecated according to mdn browser compatibility table in that page.
None the less, your question is answered (mark it). You also now know where you need change / PR it for an upgrade.
Not fun of that tone.
Also answers need to be explicit, so none of above qualifies as an answer or answers in general sense.
Hey!
I read the MDN doc as experimental features and not deprecated
If deprecated we definitely need to fix that
Hey!
I have meant deprecated for “orientationchange” event only since in its MDN page browser compatibility table there is a deprecation warning. But in specifications table it seems as Living Standard.
However, “deviceorientation” and “devicemotion” events are mentioned there on MDN as experimental, you are right, and according to caniuse.com they are globally 94% supported on devices, so, they are perfectly fine to use.
Also there is the Generic Sensor API upcoming and supported on 64% devices globally currently.
I wonder if the device do not have a magnetometer, can deviceorientaton
event still give absolute
values somehow by the help of some other sensors. As a physicist I do not think it can unless device has a somehow-super-non-drifting preset-0degree-to-true-north-in-factory gyroscope.
On the other hand Gelolocation API data has a heading
data when speed
data it has as well is non zero. But that data in that api is I think assumes that your velocity is always in the direction of your device’s top or back of it (maybe most probable orientations you hold it).
Any insights on this.
Last time I tried geolocation it failed miserably
Anyway, if you find a way to improve the camera with new API, I will gladly review and merge the PR
I have experimented with google maps app on my bus ride back hime after job today. I enabled location services high accuracy. I used it on my android phone LG G4 and I think/know my phone does not have a magnetometer: I rely on what this app says also on a website demo I have created with html and javascript deviceorientation
event and tested on my phone served over https
and the event.absolute
value was false
always.
My observation was gui heading was always pointing correct on the map even though I turn the phone side or upside down. I think it cant be used to get device orientation.
Maybe I can see how input of it works and make fallback kind of code, new generic sensor api -> device orientation api.
But none did answer my magnetometer, absolute orientation related question above. Any insights on that?
Oh! @Deltakosh, I have realized now from spec that actually the window.orientation
actually can only have values: -90
, 0
, 90
, 180
The possible values for the
window.orientation
angle are:-90
,0
,90
,180
. User agents must support the-90
,0
and90
values and may optionally support180
.
So it is used for screen orientation and so in babylonjs source code for this camera I suppose, like portrait or landscape or upside down. I for got now.
Is it feasible to set the location and orientation (maybe with setting target with setTarget
) of the camera in a scene
frequently as the user change them by moving with a navigator.watchPosition
results and maybe deviceorientation
event or generic sensor api manually, respectively?
One needs both a translating camera like universal camera and rotating camera like device orientation camera.
Will it be production quality or camera input model babylonjs employs has required tricks covered in that respect, performance-wise, accuracy-wise, and energy-wise?
Could device orientaiton camera implemented that way without handicapes?
Well yes I do not foresee any issue doing that.
Regarding production quality, we can still try by hiding the feature behind a boolean at the beginning
You mean the possible API usage fallback system (generic sensor api AbsoluteOrientationSensor else RelativeOrientationSensor, else deviceorientation event)?
@Deltakosh
guess what popped up:
Understanding DeviceOrientation events by creating a small 3D game with babylon.js
in the following page:
Unfortunately target page says: This site is no longer available.
Here we are:
Understanding DeviceOrientation events by creating a small 3D game with babylon.js | Eternalcoding
Yeah! I should have guessed it was moved to eternalcoding from sitepoint.
I am using new BABYLON.DeviceOrientationCamera, but without result.
Any advice is welcome
Regards,
Alex