_G.MYTHREE.scene.environment = _G.SCENES[_G.SID].hdrtex;
works fine in every other browser and device both mobile and desktop. i can set the scene.environment the first time in vr, but it will not update after the first time.
any ideas?
_G.MYTHREE.scene.environment = _G.SCENES[_G.SID].hdrtex;
works fine in every other browser and device both mobile and desktop. i can set the scene.environment the first time in vr, but it will not update after the first time.
any ideas?
The following demo applies a HDR environment map to Scene.environment
and everything works as expected: three.js vr - sandbox
You probably have to modify the above example to demonstrate the issue.
thanks.
I will add a dropdown for other hdrs and see if i can replicate the issue
Still stuck on this.
new THREE.RGBELoader().load(this.scene.hdr, ( _texture )=>{
_texture.mapping = THREE.EquirectangularReflectionMapping; //THREE.CubeReflectionMapping; //THREE.EquirectangularReflectionMapping;
this.hdrtex = _texture;
_G.MYTHREE.scene.environment = this.hdrtex;
_G.MYTHREE.scene.environment.needsUpdate = true;
});
Is there a reason why on XR when I add another model to the scene later, the hdr is lost? I can only seem to set scene.environment one time in XR, on the second attempt it doesn’t work.Works fine on desktop and mobile. Only an issue in XR.
I’m having the same issue if I change the scene.environment while the XR session is active the result it’s different. Did you manage to find a solution?
I use this code to update the env texture, working on mobile and desktop but not in VR
new EXRLoader(loadingManager)
.setDataType(FloatType)
.load(config.url, (texture, textureData) => {
texture.matrixAutoUpdate = false;
texture.mapping = EquirectangularReflectionMapping;
scene.environment = texture;
});
this is the result on desktop/mobile
this is the result on VR
using r145
Maybe this is indeed an issue in the engine. Any chances to demonstrate the issue with a live example?
Sorry you’re having this issue. But happy to know someone else has this issue. I did not find a solution. It’s been an ongoing bug I could not resolve. I can get the environment hdr to work the first time on VR, but not a second time. aka, if I try to reset scene.environment, the environmental hdr map then no longer appears.
Is there any update on this issue?
I am in the same situation. I am trying to change the scene.environment during runtime while XR session is active, but materials aren’t affected.
Its worth noting that this issue only happens with MeshStandardMaterial, other materials work as expected.
Still an issue for me too…
@FuzzyWobble Just curious to see if you know that this issue persists if an array of hdri’s are preloaded before runtime and updated at runtime or if its just the loading and updating during runtime that causes the issue? I’m sure you’ve likely tried this?
Let me check…
I’ve also just run into this… trying to update scene.environment while in an XR session doesn’t actually update the lighting on my .glb, works great outside of XR.
Even just using a regular jpg, no HDRI.
Edit: I’ll also mention that I’ve got 2 scenes which I toggle between which need their own .environment. The scene I start on loads fine, toggling to the next scene won’t correctly load the .environment when in XR, although it works perfectly outside of XR mode.
Hello. I’ve probably experienced the same issue and I’ve made a simple sample project using three.js r162. You can download the zipped project from here:
threejs_env_xr_bug.zip (3.5 MB)
To run it, just unzip the archive and point your webserver (apache, nginx, node.js based htttp-server… whatever you’re comfortable using) to public_html directory. There are already prebuilt and prepacked code bundles. You can simply access the page through a web browser either from your Android smartphone or you can use e.g. WebXR api emulator extension on the desktop. I’ve experienced this same issue in both cases.
If you wish to study the source code, you can find it in src folder. I hope it’s simple enough to understand what’s going on (of course, feel free to ask if something is unclear).
If you wish to make changes, you have to rebuild the project. It’s very simply structured, so you should be able to use any package manager which understands package.json, though the “official” way is to use corepack and yarn:
corepack enable
corepack install
yarn install
yarn build --watch
but you should also be fine with e.g. npm (don’t forget to run the “build” command at the end, so your package manager runs the Webpack bundler and creates packages in public_html/js directory).
Description of the issue with screenshots
You can find the pictures in issue_screenshots directory.
After you access index.html, you see a non-XR scene with “reflective balls” mesh and “christmas” jpg environment map. Everything appears alright.
You can switch env map to music hall HDR env map. Again, everything appears alright.
Switch to XR mode using the button in top left corner (visible only if the WebXR capability is detected). Scan your surroundings till a white ring appears, then tap the screen to place the balls mesh on the position of the ring (you may want look a bit up afterwards, since the balls are relatively big and high above the surface). Still, everything looks alright.
Now switch env map using the select-box in the top left corner. You’ll see the reflection on the balls gets mudded.
Switch back to non-XR mode using the Back button. The reflection stays mudded
Try again switching the env map, the reflection gets back to normal.
Try changing the mesh to shiny balls using the other select-box
Switch to the XR mode. The reflection should be alright. Cycle between the env maps. They’ll be less mudded than before, but the mapping will be quite odd
The 8th point might be somehow related to the issue, or at least it might help you figure out what is going on and whether the problem is in my code, in three.js or somewhere deep in WebGL.
@LubomirFedor Can you please try the latest dev
builds of three.js
which you can find here?
I have added a fix in context of environment maps and XR which solved a similar issue reported at GitHub. This will be available with r163
.
Thank you. This indeed seemed to fix the issue.