godot
godot copied to clipboard
godotengine
Rendering problems: WebXR rendering only to left eye 4.3 dev 5
Tested versions
-Reproducible in 4.3 dev 4 and 5
System information
Godot v4.3.dev5 - Manjaro Linux #1 SMP PREEMPT_RT Fri Feb 16 16:51:44 CET 2024 - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3060 (nvidia; 550.54.14) - Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz (6 Threads) exported to Web on Quest 2
Issue description
When loading up a basic XR demo such as the one that comes with XR tools, and viewing the web export on the quest 2, the image appears to be doubled on the left eye: Video attached https://github.com/godotengine/godot/assets/15620900/ee6bcf4c-dc37-4252-816f-a34bddd4c0c2
Also, When attempting to load the export on a chromium based browser with an Developer XR Simulator, it spits an error:
Steps to reproduce
Open/create scene with XR setup in 4.3 dev 5, export for web and test with a WebXR compatible device (in my case a quest 2)
Minimal reproduction project (MRP)
Just use the XR Tools demo project if you're unable to replicate the issue I can export my project, which has the same issue.
I'm starting to have other strange issues with even the current stable version 4.2.1, which is odd. Things like exporting to quest 2 with an android build and the compatibility renderer and having messed up shaders (dark and purplish, like the colors are inverted) and exporting to web now results in all shaders except the sky being grey. Wondering if there's some sort of Godot config files or cache that carry between versions that are messing things up, since the web export on 4.2.2 WAS working for me just a few days ago.
How might I go about clearing ALL file related to Godot to see if my system is the issue?
So the problem is definitely not my system. I've now tested 4.3 dev5 with the same project on two other machines, (one arch linux, one windows 10) and the export when viewed from the quest 2 browser is identical (only renders to left eye, only renders the skybox and nothing else)
extremely odd, and I wonder if it has something to do with the export templates getting changed?
This currently makes XR unusable for me with godot so I'd love to find out what the issue is and contribute in any way I can.
Since it started not affecting 4.2.1 and then is affecting it, are you sure it's not the hardware? Are This doesn't affect other software?
as I don't have another quest to test with, I can''t completely rule that out as a possibility. The fact that I tried the same export from multiple systems makes me think It's not my system. I'll try some other webxr stuff on the quest and just double check to make sure that they work properly
I'd say yes to try on other programs, this sounds like a hardware issue
just tested the demos from https://immersiveweb.dev/ with absolutely no issue. It's a godot export issue.
I also just tested with snopek's webxr godot test from his website https://bit.ly/sgproto-2301-01
no issues there, seems to be a regression for 4.3
4.2.1 still gives me the issue of all shaders other than the skybox being a blank shadeless grey, but There's no issue with only rendering to the left eye, or objects completely disappearing as in 4.3. Probably 2 separate issues.
Also I didn't build the above demo from source, so I don't know which version of godot was being used for that. 4.something
I can reproduce the issue on a version compiled from master just two days ago (commit 86415f0). I am going to take a look to see if I can fix the issue.
Seeing some other things we ran into recently, can you check if "glow" is enabled on the environment being used (this often is enabled by default). The new logic may be using commands that do not work in webGL. Glow should be off for XR anyway as it has a way to big impact on performance, but if this indeed turns out to be the culprit we'll need to fix it :)
(also note that WebXR always uses the compatibility renderer, so you may want to make sure that is selected for your project, it's mention in the OP that Vulkan Mobile is being used but this won't be the case for WebXR)
Thanks for the bug report!
I am able to reproduce this using Godot 4.3-dev5 and the Godot XR Tools demo (on commit f2c6f41) using the Meta Quest 3.
However, when I build the web export templates from Godot master (on commit dd926b9), everything works fine for me (again on the Meta Quest 3).
I'm not sure what's the cause of the issue in 4.3-dev5, but I do get a bunch of WebGL errors in the browser console:
[.WebGL-0x2187d5c00]GL ERROR :GL_INVALID_OPERATION : glFramebufferTexture2D: Attachment textarget doesn't match texture target
192.168.0.159/:1 [.WebGL-0x2187d5c00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClear: framebuffer incomplete
192.168.0.159/:1 [.WebGL-0x2187d5c00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClearBufferfv: framebuffer incomplete
192.168.0.159/:1 [.WebGL-0x2187d5c00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
192.168.0.159/:1 [.WebGL-0x2187d5c00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete
So, I'm assuming there was some rendering change that broke it. (I personally tested WebXR on Godot master about a week before 4.3-dev5 was released, so it must have been a last minute change.) Thankfully, it does appear to be fixed in master, at least in my testing.
I've attached the Godot web export templates that I built from the commit mentioned above: godot.web.template_debug.dev.wasm32.zip
You can configure "Custom Template" on your export preset to point to the ZIP file in order to use them. I'd appreciate it if you could test and let me know if it's fixed for you as well, or if there's something specific in your project that needs to be debugged.
Otherwise, I suspect Godot v4.3-dev6 will be released in not too long :-)
So using your export template reverted to the behavior I was experiencing on 4.2 with my project: all materials being rendered as shade less grey (still rendering though, I assume as the fps was quite low, meaning it was rendering something)
I checked to see if it was due to the glow or other post process effects that might have been on by default like @BastiaanOlij mentioned. Nothing enabled in the world environment. After some digging around I found that the project had TXAA enabled, but disabling it made no change, still all grey (but now grey with a higher fps haha).
When trying it on the demo rather than my own project, the load screen now appears properly with rendering to both eyes, but after holding the trigger to load into the demo and the little circle filling up everything goes black and nothing else appears. I'll have to check if that was happening in 4.2 as well for me or not (EDIT: Demo project works properly from 4.2.1 with default export template without issue, just broken on 4.3 dev5 ) But as of now, both the demo and my personal project are unfortunately still broken in 4.3
after holding the trigger to load into the demo and the little circle filling up everything goes black and nothing else appears
I experienced something similar to this, which was the first time I ran the Godot XR Tools demo, it took a long time to go from black to showing the scene. Could be slowness in loading resources or compiling shaders? However, the main scene did load and seem to work fine after waiting a bit. All subsequent times I ran the demo, it didn't get stuck after the fade to black.
But as of now, both the demo and my personal project are unfortunately still broken in 4.3
Unfortunately, since the Godot XR Tools demo is working for me, I'm going to need more information in order to help.
Could you share your project? Or, any interesting messages from the browser console?
Remote debug console output from quest browser when loading the godot-xr-tools demo scene into 4.3 dev5 with your export template linked above:
192.168.1.126-1712690493875.log
For my own project the scene loads fine for normal webGL in the quest browser
but when clicking enter VR everything is grey (shader issue of some sort, since the sky is actually still rendered fine, at least with my other tests: namely a blank scene with xr origin camera and 2 controllers with a cube attached to them. sky renders fine, cubes are shadeless grey)
console output:
192.168.1.126-1712690859408.log
Regarding Godot XR Tools:
Remote debug console output from quest browser when loading the godot-xr-tools demo scene into 4.3 dev5 with your export template linked above.
Based on these errors, it looks like there was some issue with importing or exporting some of the resources in the project. Maybe try deleting the .godot directory and the opening it in the editor?
(Godot can sometimes be flaky when re-importing all resources in a project, and so in my experience I've sometimes had to close and re-open the editor multiple times before it manages to import everything in the project).
Anyway, if it can't load the scene (which is what it looks like from those errors) that would explain why you never get out of the fade to black. :-)
Regarding your project:
but when clicking enter VR everything is grey (shader issue of some sort, since the sky is actually still rendered fine, at least with my other tests: namely a blank scene with xr origin camera and 2 controllers with a cube attached to them. sky renders fine, cubes are shadeless grey)
The first mess of errors are just from it attempting to load the 'godot_openxr_vendors' GDExtension, which won't work in the web build. Those can be ignored.
The interesting bit is at the end:
WebGL: INVALID_OPERATION: texParameter: no texture bound to target
tmp_js_export.html:1 Not all layers have valid content; visual artifacts might occur.
[.WebGL-0x21690ff00]GL ERROR :GL_INVALID_OPERATION : glDrawElements: uniform buffers : buffer or buffer range at index 5 not large enough
This does look like it could be a shader issue as you suspected. For whatever reason, it's having an issue with uniform buffers. Shaders do work a little differently when rendering mono (like on a normal, flat web page) versus rendering in stereo (like in immersive VR). So, it sounds like there could be something in one of your materials that doesn't work right when rendering in stereo.
Are you using any custom shaders in your project? Or, is it all using StandardMaterial3D? It'd be interesting to try removing materials until you find which one is causing the issue. That would be super helpful in narrowing the bug down.
However, it does seems like these are both issues unrelated to the "only rendering to left eye" issue, which sounds like it may be fixed?
Rendering to only left eye is fixed with your export template, yes.
No custom shaders in my project, just default StandardMaterial3D
No custom shaders in my project, just default
StandardMaterial3D
If you have the time, it would be great if you could narrow it down to an individual material (probably by disabling materials until the one that's causing the problem is found) and then share it as a .tres file. Then we could try and figure out what about that material doesn't work when rendering in stereo.
currently every material in the scene is the flat gray, so I don't know if it's any specific material. the sky is the only thing that is rendered correctly. I'll mess around with it and see if that makes a difference though
here's a barebones scene that has the issue that you should be able to test and see if you can replicate test.zip
@dsnopek does that godot project export with the broken shading on your system as well?
@michaelharmonart I think that test project is missing some things. The main.tscn is mostly empty (it doesn't contain any meshes with materials, only the cubes to stand in for hands) and if I try to open any of the other scenes, the editor complains that it's missing all the material *.tres files (the Assets/Materials/ directory is missing).
@michaelharmonart Any chance you can fill in the missing pieces in the test project? Otherwise, I'm not sure there's much more we can do here to help. Thanks!
Thanks!
It looks like it's the OmniLight3D - if I switch it to DirectionalLight3D then the materials render correctly.
There's issue https://github.com/godotengine/godot/issues/82278 which is dedicated to this problem.
Given that the issue here is starting to get a little hard to follow (we started with one problem - WebXR only rendering to the left eye - and switched to another problem), I'd like to propose that we close this one, and continue tracking the OmniLight3D issue on https://github.com/godotengine/godot/issues/82278.