-
-
Notifications
You must be signed in to change notification settings - Fork 35.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update DeviceOrientationController to include manual drag+zoom overrides + event bubbling + consistent FOV support? #5338
Comments
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 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 |
OK. I have been seeing that most developers using I do agree with keeping things simple though. Perhaps the first thing we should do is update all the |
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?
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 |
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? |
Nice! :D |
Closing, see #5338 (comment) |
I've been trying to figure out how I could add the features of the threeVR
DeviceOrientationController
toTHREE.DeviceOrientationController
. Having tried numerous times to simplify my library I think it makes the most sense to replace the currentTHREE.DeviceOrientationController
with a compatible version of the threeVRDeviceOrientationController
as is.To summarize, the additions to
THREE.DeviceOrientationController
this will bring include:rotatestart
,rotateend
)zoomstart
,zoomend
)userinteractionstart
,userinteractionend
)orientationchange
)compassneedscalibration
)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 currentTHREE.DeviceOrientationController
class).The text was updated successfully, but these errors were encountered: