Vivecraft_112
Vivecraft_112 copied to clipboard
White screen on world load.
Whenever I try to load a world the screen goes white and stays that way. To be clear it is not a crash as I am able to punch blocks and the game does not close out. No issues in the menu's unless changing mirror mode in which case the visuals lock up on the headset. (Game still runs fine, going to submit a separate report for that.)
System is
- OS: Pop!_OS 19.10
- Linux Kernel: 5.3.0-22-generic
- SteamVR Beta 1.9.6
- Valve Index HMD
- AMD Ryzen 7 2700x
- NVIDIA RTX2080 TI
- NVIDIA Driver 440.31
- Minecraft 1.12.2
- Both Forge and Non-Forge
- Java: OpenJDK 8u232-b09
I don't know which logs would be relevant here, but if someone can tell me I can upload them.
Killing vivecraft and re-starting it will successfully load the menu. But loading the world just triggers the issue again.
Interm fix: Turn on internal shaders through optifine.
I think that this is a different issue then #128 since the controllers don't vibrate and I have not had any hard crashes, but I did want to mention it just in case it is relevant.
I've said it before, there's unfortunately nothing we can do about the Linux graphical issues. It's something wrong in SteamVR's OpenGL submission pipeline. From what I've heard other native Linux VR games have the same issues, but games running through Proton work fine since that uses Vulkan to emulate D3D.
I think I may be hitting the same issue. Menu is totally fine but once I load up a world I get white noise all over the eye framebuffers. The noise could easily mistaken as being all white (hence why I think this might be the same issue), I didn't even notice that it's just noise on top of the normally rendered world the first few tries.
Notably only the left and right eye framebuffers are affected and the noise is fixed (i.e. only changing when the framebuffer is re-allocated by pressing F5) and identical in the headset, steamvr mirror and vivecraft mirror. None of the other vivecraft render modes are affected, it's really just the eye framebuffers which sounds very much like the broken steamvr opengl submission pipeline.
System Info
(partly from memory because I'm dual-booting to get steamvr to work with my gpu) (iirc, all software was fully up-to-date (either self-updating or from debian repos) when I tried it last Saturday)
- OS: Debian Sid
- Linux Kernel: 5.3.9 (iirc)
- SteamVR Beta 1.9.5
- Valve Index HMD
- Intel Core i7-4790K
- Readeon RX 5700 XT (free amdgpu driver with navi10 firmware from linux-firmware git at 11bdc578)
- Minecraft 1.12.2 (both forge and non-forge) and 1.14.4
- Java: OpenJDK 8 (whichever was in debian sid repos at the time)
- Manually forcing the RADV vulkan driver (
/usr/share/vulkan/icd.d/radeon_icd.x86_64.json
and i386 equivalent) onto steam cause otherwise the vr compositor would try to use the integrated gpu for some reason. - Also had to launch MultiMC with the steam runtime as otherwise it'd fail to connect to steamvr.
How feasible / difficult would it be to work around the issue by using steamvr's vulkan pipeline? (assuming it is only its opengl pipeline which is broken and that there's a performant way to get framebuffers from opengl to vulkan) I'm barely familiar with vulkan and not at all with steamvr but I'd be willing to put some time into it (assuming I can get vivecraft to compile. I ran into a seemingly endless amount of issues last time I tried), I just don't know how strongly vivecraft is tied to steamvr's opengl interface.
Or maybe a quicker way to work around the issue: The main menu is consistently unaffected by the issue for me. Does Vivecraft handle the main menu rendering in a fundamentally different way than the ingame world? That is assuming it doesn't just break permanently because of something during world loading. I haven't actually tried to return to the main menu once stuff was broken, I always just closed the game.
I tried flicking through various graphics settings today and to my surprise when I enabled OF's <internal>
shader (haven't tried others) the issue disappeared (tried 1.14.4 and 1.12.2+Forge).
Disable it again and it reappears, works every time. Quitting back to the main menu also fixes it until one loads a world again.
@jcc10, would be interesting to know if that's just on my machine or in general. Also, when you look very carefully (and there's sufficient contrast in the world), can you see the world through the white screen?
So it's probably triggered by some detail in how the framebuffers are handled which differs between main menu world and ingame world without shaders but potentially is the same in main world and ingame with shaders.
FWIW I also tried throwing in BetterPortals since it also messes with framebuffers a bit but it had no apparent influence on the issue.
@Johni0702 That did indeed fix it. (Tired, just wanted to give some results immediately. I can do more testing in the morning.)
That is a weird workaround and I'm really not sure why that would work, but cool. The framebuffers created are slightly different with shaders enabled, but I'm not sure what effect that has.
As for rendering from OpenGL to Vulkan, copying via CPU would be rather unperformant so we don't want to do that, ~and there's no extension for OpenGL->Vulkan copy on GPU, only the other way around~ apparently EXT_memory_object_fd
allows this, but SteamVR is already doing that so it seems redundant for us to reimplement it.
Something about how EXT_memory_object_fd
works must not like the way our framebuffers are set up, or maybe it doesn't play nice with some fixed pipeline rendering functions Minecraft uses when shaders are disabled.