The samples seem to have gimble lock issues

[greggman]

I'm using the emulator in Chrome but for example

I don't see that on my iPhone. Is that a bug in Chrome or in Full-Tilt or?

[richtr]

Since this issue does not occur in Android (Chrome) or iOS (Safari) I'm going to suggest that the raw deviceorientation data of the emulator does not match the raw deviceorientation data produced on mobile devices and that this therefore seems to be a bug with the Chromium Dev Tools 'accelerometer' [1] emulation feature.

UPDATE: See my follow-up comment below for a full investigation and explanation.

Do you want to file a bug against the Chromium Developer Tools ('Platform-DevTools') over at https://crbug.com and see if we can get input from the developers who implemented this emulation feature?

Also, thank you for providing an animation with your bug report! This makes is so much easier to understand the issue. :)

[1]: nitpicking but it really should say Device Orientation in the console not Accelerometer

[richtr]

I filed this as an issue on the Chromium project at https://code.google.com/p/chromium/issues/detail?id=504343.

Please vote for this issue if you want to see it addressed.

[greggman]

Doh, I filed an issue too

https://code.google.com/p/chromium/issues/detail?id=504403

[richtr]

So this problem has been bugging me for a while and so I decided to investigate it further.

I'm going to start by saying that based on my investigations, the Chrome device orientation emulation seems to be working correctly.

What is happening here is that as a mobile device rolls, the visual output to the screen on that device is compensated by the amount of real-world roll observed, making the whole scene appear to remain upright regardless of the physical orientation of the mobile device.

When emulating with Chrome, the emulator tells the page that roll is occurring but the physical screen itself does not roll. Instead the desktop computer remains sat in the same position on the table. The web page is told to compensate the visual display by the observed roll and it therefore makes it look like the web page is 'spinning' when the physical screen itself is not also simultaneously rolling.

This brings me on to the second part of this explanation:

What the OP is observing is the transition of the gamma from [0 to 90 degrees] and then, continuing in the same direction, from [90 to 0 degrees]. When it rolls from [0, 90] to [90, 0], at least one other axis must also flip to ensure the scene continues to 'point' in the right direction. I explained why another axis must flip during such a 'flip' transition in this StackOverflow answer. That answer may be worth studying in detail.

The upshot of all this is that the Chrome emulator is in fact working correctly but because a Desktop or Laptop's screen does not physically roll it appears to flip drunkenly when using the Chrome emulator on those devices.

Proof of this phenomenon can be seen in the following video. The mobile device shown on the screen is actually rendering an iframe for the standard Full-Tilt VR demo page and it's purpose is to compensate for the roll by orienting the mobile phone in the way it is actually being held by a user given the device orientation values. The background scene is the non-roll-compensated scene similar to the one observed by the OP.

Now that we know this is not a bug in either Chromium or this library, per se, what should we do? I was planning to clean-up and release the mobile phone emulator shown in the video above but it is only in hack form right now on my local machine.

This is certainly mind-bending stuff but I'm pleased to now have a real explanation of this phenomenon.

[greggman]

Then it seems like emulator needs a "lock orientation" button since we want that simulated too. Since the emulator did not change it's emulation to landscape it should have not rolled the device

[richtr]

Here's a better emulator that provides the same precise values as Android devices:

https://github.com/richtr/deviceorientationemulator

This avoids the 'gimball' issue that is currently present in the Chrome Dev Tools Emulator.

Then it seems like emulator needs a "lock orientation" button since we want that simulated too.

I agree this would be good. I haven't added this to the emulator linked above yet either but hope to do that soon.

[greggman]

I don't know if you're interested in this (maybe too much work) but you can create DevTools extensions

For example: https://github.com/spite/ShaderEditorExtension

BTW: If your curious what I'm using this for

[richtr]

The popup-based emulator works across different browsers.

We may just see the Chromium DevTools emulator be fixed as part of https://code.google.com/p/chromium/issues/detail?id=504343 so it probably doesn't make sense to create a DevTools extension in the interim.

[richtr]

All of the Full-Tilt demos will now fallback to deviceorientation event emulation in the case that the current browser does not support these events.

You should give it a try in any browser that does not emit DeviceOrientation events and let me know if you find any further issues.

The device orientation emulator I created for this purpose can now also remove the effects of device roll from the data so you can now test any deviceorientation-based web applications without the effects of device roll interfering with your work \o/ :)

I'm closing this issue now. This has been very productive and let me know if you find any further issues.

[gpellegri]

Hi, I'm starting to check the Chrome emulated accelerometer and I've some doubts too on it.. someone here is speaking about the emulated data during the rolling of the device but reading the specifications (http://www.w3.org/TR/orientation-event/) it's clearly written that "it also means that the angles do not match the roll-pitch-yaw convention used in vehicle dynamics", so if you think about roll like the roll of an airplane I think it's not right. What is going wrong with the Chrome emulator is (I think, but please correct me if this is wrong) the implemented axis system. In the w3c specifications is written that alfa, beta and gamma are a set of "intrinsic" Tait-Bryan angles of type Z-X'-Y'', but it seems that Chrome is using a system Z-X-Y. I don't know Full Tilt but if you want to use the accelerometer with the device screen in front of you (beta=90°) you are working on an augmented reality like-system and to have the right values of Z,X and Y you have to play a bit with math and matrices, there is an example at the end of the specifications page. Anyway, with a true device and a true accelerometer I hope it'll be easy to check :)

Best Regards and good luck Giordano Pellegri