Roll in FreeCameraDeviceOrientation

[MasterSplinter]

Hey,

Are there any objections for me to modify FreeCameraVRDeviceOrientation to take into consideration roll?

This for one should give a more virtual reality like experience and two should fix mobile devices when orientation switches between portrait and landscape?

 

-P

[GameMonetize]

Pinging @RaananW who is also working on this:0

[MasterSplinter]

He's on vacation   I'll just write up a version of this and he we'll sort out the fiddly bits and PRs when he gets back. 

[MasterSplinter]

@RaananW and @Deltakosh it looks like TargetCamera_getViewMatrix() uses Matrix.LookatHToRef() which uses a fixed up value.  So the code supports roll but this is getting thrown out. 

[RaananW]

Hi,

A message from my very nice  vacation - it is solved already, I'll commit the changes after I'm back from my vacation. Roll is supported.

Back to my family!

[MasterSplinter]

@RaananW beautiful work btw. I just finally pulled and tested.  I am curious I felt like I was getting inaccurate data from chrome?

 

Btw, have you noticed devices that have no gyro.. seems to create a virtual one based on magnometer and accelerometer.

[RaananW]

Thanks

I am actually using mainly chrome for testing (both mobile and desktop versions), so, no - I haven't noticed that. Wanna share your experience? or maybe somehow reproduce it?

 

The nice thing about the device orientation event, is that it has less to do with the sensors installed and more to do with the way the OS is sending this information. The browser is getting the 3 axis it needs, doesn't matter how. So I would assume a device without gyroscope will actually do that, but I haven't really encountered one. 

[MasterSplinter]

On 5/20/2016 at 4:01 AM, RaananW said:

Thanks

I am actually using mainly chrome for testing (both mobile and desktop versions), so, no - I haven't noticed that. Wanna share your experience? or maybe somehow reproduce it?

 

The nice thing about the device orientation event, is that it has less to do with the sensors installed and more to do with the way the OS is sending this information. The browser is getting the 3 axis it needs, doesn't matter how. So I would assume a device without gyroscope will actually do that, but I haven't really encountered one. 

@RaananW Just to get your thoughts on this... We seem to have a decent amount of latency  on mobile devices on on passing through device orientation events.  

https://github.com/toji/webvr-samples/blob/gh-pages/js/third-party/webvr-polyfill.js

I found this polyfill for the future implementation of webVR api.  They seem to have very low latency almost native feeling.  Digging through the source it looks like he's listening for the devicemotion event as opposed to deviceorientation and applying a filter to smooth the data received data.  

Several thoughts:

1)  Could devicemotion be more optimized than deviceorientation?

2) Could the filter improve performance?

3) Combo of both?

4)  Could there be a bottleneck somewhere else in babylon with the orientation data being pass through too much?

[RaananW]

Hi!

Let's answer some questions:

1) devicemotion (according to the standard) has very little to do with the device orientation (well, that's why there is a "device orientation" event ). Device motion is more about acceleration and rotation rate, less the current state of orientation. more here - https://www.w3.org/TR/orientation-event/#devicemotion . I think the most important thing to remember here, is that this data is provided by the browser. It is up to the browser's vendor to provide correct information. So, if for example I am using chrome, I must consider if I trust google well enough to provide the right data in the right event, OR use different types of events to create the filters myself. I am a very trusting person myself, I will stay with deviceorientation

2) What filter? The data you receive is usually already filtered (kalman filter probably).

3) the deviceorientation is calculated using the same data you will be using. See answer to 1.

4) Yes and no. This is, again, up to the browser. Having said that - the implementation simply updates 3 values when they are received from the browser and not more than that. Afterwards those values are being used during rendering. So the bottleneck would not be the amount of times those values are updated (3 floats and that's it) but rendering, which is our usual bottleneck.

 

[MasterSplinter]

I can't remember where I found it -- but the devs at Chrome haven't updated or optimized device orientation in several years -- Rather choosing to focus on webVR orientation implementation.  It doesn't seem far fetched with a filter and some drift correction you could get better performance from devicemotion.  EXPERIMENT TIME!!!

[RaananW]

I doubt that with the raise of google cardboard experiments, google devs have neglected to fix problems with device orientation. the device orientation event provides the same data native apps are getting for the orientation. and, i actually never experienced any problem with it... Apart from it being in euler angels , which sucks in general.

I am also not sure what you mean with "webVR orientation". the oclulus, for example, provides its own orientation calculation. it is not something you can get from each device you are connected to. a smartphone won't provide you with this data.

Besides, looking at this - http://www.html5rocks.com/en/tutorials/device/orientation/ , you will notice the person talking about how to use it is a google employee.

Run experiments, it is fun and you can actually learn a lot from it, but I will stay with a future-safe implementation. that is actually working rather well!

BTW, about WebVR - I commited a fix for WebVR, so oculus rift works.

 

[MasterSplinter]

Here is the chatter I was referring too...

https://bugs.chromium.org/p/chromium/issues/detail?id=413327

[MasterSplinter]

Here's a quick demo I did this afternoon overriding the orientation events using devicemotion...  

https://rawgit.com/wpdildine/babylon_deviceorientation/master/index.html

Now all I have to  do is tape two phones together and see which one works better lol.

Side note:  Do we have a method of working directly with quaternions as opposed to converting to euler angles?

[GameMonetize]

Hey!

 

quaternion to euler angles: https://github.com/BabylonJS/Babylon.js/blob/master/src/Math/babylon.math.ts#L1867

[MasterSplinter]

I saw and was using that function was wondering if I could plug quats directly into camera orientation.

 

BTW, Now I've gotten fairly deep in your library ...  All I gotta say is <3 <3 <3

[GameMonetize]

Love pretty much appreciated

Cameras (since 2.4) now have a rotationQuaternion: https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/babylon.targetCamera.ts#L10

 

[JCPalmer]

Have to put export camera in quaternions on my list.