Device orientation camera

Where does it takes its input from:

  1. device orientation event
  2. device motion event
  3. one of sensor api interfaces like absolute and relative orientation sensor api
  4. or geolocation by speed and heading data it yields

I am not aware that this camera can change locations, only rotation. Here is the input source code:

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.

I read the MDN doc as experimental features and not deprecated :slight_smile:
If deprecated we definitely need to fix that


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 they are globally 94% supported on devices, so, they are perfectly fine to use.

1 Like

Also there is the Generic Sensor API upcoming and supported on 64% devices globally currently. :wink:

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 :slight_smile:
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? :slight_smile:

1 Like

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 and 90 values and may optionally support 180 .

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)?

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 :slight_smile:

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