Update DeviceOrientationController to include manual drag+zoom overrides + event bubbling + consistent FOV support?

[richtr]

I've been trying to figure out how I could add the features of the threeVR DeviceOrientationController to THREE.DeviceOrientationController. Having tried numerous times to simplify my library I think it makes the most sense to replace the current THREE.DeviceOrientationController with a compatible version of the threeVR DeviceOrientationController as is.

To summarize, the additions to THREE.DeviceOrientationController this will bring include:

• Manual drag override controls for mouse/touch + disable flag + interaction start/end event bubbling (rotatestart, rotateend)
• Manual zoom override controls for touch + disable flag + interaction start/end event bubbling (zoomstart, zoomend)
• General manual user override interaction start/end event bubbling (userinteractionstart, userinteractionend)
• General Screen Orientation Event bubbling (orientationchange)
• Additional Device Orientation Event bubbling (compassneedscalibration)
• Flag to enable rotation matrix-based deviceorientation computation (we use quaternions by default)
• Constrain FOV when screen switches from portrait<->landscape. i.e. always make scene objects appear the same size whenever screen orientation changes occur.
• Default to using a 'heads-up' orientation for the camera/target object (in-line with the horizon) if/when deviceorientation is not supported on the current device. This is useful on e.g. Desktop where deviceorientation may not be supported or only partially supported like in Chrome on Mac. i.e. the scene looks good on Desktop browsers too and can be interacted with via the drag override control.

You can look at a live VR demo that uses these proposed changes to preview what these updates could bring to THREE.DeviceOrientationController.

Let me know if a) you think this is a good idea @mrdoob and b) whether I can issue a pull request for this library (with changes applied for it to hang-off the THREE object as per the current THREE.DeviceOrientationController class).

[mrdoob]

I don't think this is a good idea. I think it's better to keep controls logic as simple as possible and modularise as needed. The way I see it DeviceOrientationControls should just take care of the quaternion.

You can do things like this:

var dummy = new THREE.Object3();
scene.add( dummy );

var camera = new THREE.PerspectiveCamera(...);
dummy.add( camera );

new THREE.DeviceOrientationControls( dummy );
new THREE.CustomControls( camera ); // manual drag, manual zoom, ...

I actually think the current DeviceOrientationControls is overcomplicated (shouldn't need a connect(), shouldn't even need a update())...

[richtr]

OK. I have been seeing that most developers using THREE.DeviceOrientationControls are not providing good (or, frankly, any) fallback controls in the case that DeviceOrientation Events are not supported on the user's device/browser. The current controller also doesn't make the demos look great on Desktop browsers where DeviceOrientation Events are partially supported. On Chrome for Mac for example I always seems to be starring at my feet by default :)

I do agree with keeping things simple though. Perhaps the first thing we should do is update all the THREE.DeviceOrientationController-based demos we have to also provide suitable fall-back controls as a sort of 'best practice' along the lines of your suggestion above. What do you think?

[mrdoob]

On Chrome for Mac for example I always seems to be starring at my feet by default :)

Ah! You have a MacBook Pro? MacBook Air doesn't support DeviceOrientation... As far as I understand that problem comes from the spec assuming that the screen is looking up by default (mobiles). What's the best way to handle this?

Perhaps the first thing we should do is update all the THREE.DeviceOrientationController-based demos we have to also provide suitable fall-back controls as a sort of 'best practice' along the lines of your suggestion above. What do you think?

Sounds good to me! The main problem I've been having with all this is that there is no API to check if the device supports deviceorientation or not. You need to add a listener to it and add the controls if the value isn't null. This makes things trickier than they should be...

[richtr]

Perhaps the first thing we should do is update all the THREE.DeviceOrientationController-based demos we have to also provide suitable fall-back controls as a sort of 'best practice' along the lines of your suggestion above. What do you think?

Sounds good to me! The main problem I've been having with all this is that there is no API to check if the device supports deviceorientation or not. You need to add a listener to it and add the controls if the value isn't null. This makes things trickier than they should be...

I agree. It is extremely difficult since the event may be available but may just return null. In other implementations, the first events fired always return null while the sensors are 'warmed up'. That makes it difficult to detect this stuff reliably right now without using e.g. a setTimeout function to check no subsequent events are fired that do provide full event data.

I've requested some changes to the W3C DeviceOrientation Events API specification (w3c/deviceorientation#12) so we have a way to reliably detect whether device orientation is supported by the current UA or not. Let's see what happens there?

[mrdoob]

I've requested some changes to the W3C DeviceOrientation Events API specification (w3c/deviceorientation#12) so we have a way to reliably detect whether device orientation is supported by the current UA or not. Let's see what happens there?

Nice! :D

[Mugen87]

Closing, see #5338 (comment)