Closed drbct closed 5 months ago
@drbct Can you please replace all materials in your scene from MeshStandardMaterial
to MeshPhongMaterial
and test again? Scene.environment
can't be used in this context so you have to assign the environment map to the envMap
property instead. But since you said using envMap
produces the same (wrong) result, it should be good for a test.
I want to clarify if PMREMGenerator
breaks in XR. In might be necessary to disable XR in PMREMGenerator
during the generation process. The generator is not used with MeshPhongMaterial
.
Can confirm. This example using envMap
MeshStandardMaterial
: https://jsfiddle.net/7hdo4bsj/1/MeshPhongMaterial
: https://jsfiddle.net/7hdo4bsj/2/Can you test with one of the build files of https://github.com/Mugen87/three.js/commit/d2b06eeb0ef72b54ddc0113e7bf30ba208aa2a6f if the issue is fixed?
I've added a patch to PMREMGenerator
that hopefully fixes its usage in XR.
Works like a charm; Thanks for the quick response!
Apologies if I'm misunderstanding this fix, but I'm not able to get the THREE.CubeCamera to update properly while using WebXR, and it seems to be related to the pmremVersion.
Here's a sandbox: https://codesandbox.io/p/sandbox/pmrem-threejs-fgcmdc
It's a slightly modified version of the official dynamic cube reflection example.
I've added a VR button. It renders fine on desktop. In my Meta Quest 2, it renders, but the perspective is warped and unusable.
The problem can be fixed by commenting out the MeshStandardMaterial in line 49 and uncommenting the MeshBasicMaterial in line 55, and then uncommenting line 113:
cubeCamera.renderTarget.texture.pmremVersion--;
With that, it renders fine on the Meta Quest, seemingly because the PMREM update is bypassed.
Is anyone else experiencing this? Or is using the cubeCamera to generate a dynamic envMap not supported yet in WebXR?
I can't test fiddles and codesanbox apps with a Quest since VR is not allowed inside their iFrames.
Any chances to share a standalone test application that demonstrates the issue?
@drbct Do you see any regressions in r163
with your XR apps compared to the dev
version we have tested with? Is the original issue of this thread still solved with the current release?
It should work on your Quest if you open in a new tab that uses SSL: https://fgcmdc.csb.app/
Thanks! Indeed, I can confirm the perspective is completely broken.
Would it possible for you to make a test with this version of the build file? Does the bug disappear?
Thanks for the quick reply. Yes, I'm still seeing the distortion with that version loaded: https://yvqwqv.csb.app/
Here's the sandbox link if you want to check it over: https://codesandbox.io/p/sandbox/pmrem-threejs-forked-yvqwqv
Okay, so it seems it isn't a regression within r163
. I need a closer look for this one...
I can't edit the sandbox so I can't share a new link. But I suggest you remove the lines:
sphere.position.z -= 75;
cube.position.z -= 75;
torus.position.z -= 75;
You then have to move the camera away from the origin:
camera.position.z = 75;
The cube camera should be position at the location of the sphere like so:
cubeCamera.position.copy( sphere.position );
I was wondering why OrbitControls
is broken in your app and the root cause is positioning the camera at the origin. I believe the side effects we see in XR could be related to the same issue.
Besides, a XR scene should honor real world scale so it's better to position the like so:
camera.position.set( 0, 1.75, 2 );
This requires a different transformation of the sphere, torus and box as well.
If the issue still persists, please file a new issue. The issue we see is unrelated to the problem originally discussed here.
OK - thanks for helping. I'll investigate further.
Description
Ahoy!
We ran into what appears to be a bug with regards to
CubeCamera
in VR. Specifically, callingCubeCamera.update
and then pointingScene.environment
at thetexture
of the underlyingWebGLCubeRenderTarget
works fine while rendering regularly, but produces completely black reflections in VR.In the interest of quick reproducibility, the live example linked below was built around the WebXR API Emulator extension. However, we observed the same behavior testing with two actual headsets (Quest 2 and 3 using the Meta Quest Browser).
Reproduction steps
CubeCamera
which is located just in front of the metallic cube you're looking at.Code
The offending code appears to be in lines 73 through 75.
Here, we're first resetting the environment to the initial background. In the live example, this comes from a
RoomEnvironment
, but all of the above applies equally to a cube map loaded from individual images. Then, the cube camera renders the scene and the resulting cube texture is set as the scene's environment.We also tried pointing the
envMap
property of the cube's material tocubeRenderTarget.texture
and obtained the same result.It appears as though the cube map is still being rendered correctly in VR. This can be verified by changing line 75 to
and performing the first update in VR. Subsequent updates produce a feedback loop, but that is to be expected. This suggests that the problem lies in applying the texture to
Scene.environment
while VR is active.Live example
Screenshots
No response
Version
r162
Device
Headset
Browser
No response
OS
No response