Three.js: r101 randomly overrides camera.y to 1.6

[makc]

this is a change I am getting while trying to upgrade from r92.

there is this code in render():

which, when you step inside, does this:

why is this?

[makc]

For now I am using work-around (changed

        renderer.vr.enabled = true;
        WEBVR.getVRDisplay( function ( display ) {
            renderer.vr.setDevice( display );
            document.body.appendChild( WEBVR.getButton( display, renderer.domElement ) );
        } );

to

        WEBVR.getVRDisplay( function ( display ) {
            renderer.vr.enabled = true;
            renderer.vr.setDevice( display );
            document.body.appendChild( WEBVR.getButton( display, renderer.domElement ) );
        } );

)

[kkolinko]

why is this?

Maybe it is the height of user's eyes from ground, when one is standing and wearing VR goggles (1 m 60 cm)?

The code is in src/renderers/webvr/WebVRManager.js. The original commit that introduced the value of "1.6" was cfd22c2c4f4621d770f3a5af68b0533e69af5959. Also see #11619.

[Mugen87]

why is this?

When you enable VR mode, the renderer assumes a default position of the camera (at the origin with a specific height). It simulates in some sense the standing pose of a user wearing a VR headset. Note that this behavior is specific to WebVRManager and does not happen with WebXRManager.

I don't understand what you mean with "randomly overrides". The behavior should be consistent when using WebVRManager.

[mrdoob]

Does this still happen with r102?

[Mugen87]

Closing since the OP does not respond.

[makc]

I never upgraded to 102, so would not know, sorry :/

[speigg]

Same issue happens in r103. The camera position should probably not be modified when no XR/VR device is available.

[Mugen87]

Let me clarify. Instead of this:

https://github.com/mrdoob/three.js/blob/d8746022fabbc9adc7b9c5f978845315782cca61/src/renderers/webvr/WebVRManager.js#L237-L244

The code should do this in your view, correct?

if ( isPresenting() === false ) return camera;

[speigg]

Correct. It should match the behavior in the WebXRManager.