What happened?

I'm not aware of the exact details which this bug produces, but I am absolutely certain that 1.2.4 functions correctly with the mod. Users can no longer use Iris for 1.19 as it does not currently function properly with MCXR and it appears to be something that could be potentially on your guys' end (but I'm not an expert!).

Screenshots

No response

Relevant log output

No response

Minecraft Version

Minecraft 1.18.2 / 1.19

Iris Version

Iris 1.2.5

Sodium Version

--

Operating System

--

What is your GPU?

--

Java Version

--

Additional context

All details that are required are irrelevant for the bug report as it affects all systems, every GPU, and all Java versions of the game (and it doesn't require the use of Sodium to reproduce).

There's not enough detail in this report to determine what "not functions" means. Iris 1.2.5 changed around 10k lines of code so we can't just guess what changed.

Iris 1.2.5 changed depth buffer handling and how Iris interacts with the Minecraft main render target, but I have no idea if that's related since I don't know what the symptoms of the issue are to begin with.

Unfortunately, I'm not super sure what the issue is. A user of the Discord described it like this:

i'm getting a black screen in the HMD while using MCXR. the window displays just fine however the HMD shows the screen for a couple frames then just quits with a black screen. i'm using a Rift S and XR is set to Oculus, steamvr is not running. i am also getting a spammed log line:
[19:34:05] [Render thread/INFO]: OpenGL debug message: id=1281, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_VALUE error generated. Size and/or offset out of range.'
[19:34:05] [Render thread/INFO]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'

There's a toggle to enable GL error debugging in iris.properties that could provide additional information on the issue. It prints stacktraces for GL errors but they might not show up in the log file so they might need to be copied from the console.

Unfortunately, I lack the hardware and software needed to debug this issue myself in the absence of stacktraces and such, so the MCXR developers might need to provide additional investigation and information.

Details that I can provide:

What happened?

With MCXR installed and VR mode is enabled, an upper section of the screen is black with what looks like the silhouettes of a frozen frame. In the lower section, the sky and sun/moon are the only things rendering correctly. If you turn the camera quickly enough, sometimes parts of the terrain pop up, but this behaviour is inconsistent and doesn't happen often.

Screenshots

Relevant log output

Apart from the same log warnings previously shown for the flatscreen test when iris.properties debug is enabled, a few new log entries stand out when the iris.properties debug is disabled while in vr:
...
[19:24:25] [Render thread/INFO]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'
[19:24:25] [Render thread/INFO]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'
[19:24:25] [Render thread/INFO]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'
[19:24:25] [Render thread/INFO]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'
[19:24:25] [Render thread/INFO]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'
[19:24:25] [Render thread/INFO]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_OPERATION error generated. Texture name does not refer to a texture object generated by OpenGL.'
...
[19:24:38] [Render thread/INFO]: OpenGL debug message: id=1281, source=API, type=ERROR, severity=HIGH, message='GL_INVALID_VALUE error generated. The y values exceeds the boundaries of the corresponding image object.'
^This error repeats, filling the rest of the log file until the game is closed. I'm guessing it was caused by the broken texture names in the previous six earlier errors.

Minecraft Version

Minecraft 1.19

Iris Version

Iris 1.2.5

Sodium Version

sodium 0.4.2+build.16

Operating System

Windows 10

What is your GPU?

RTX 3070

Java Version

java 17

I've enabled the debug option in iris.properties, but as you mentioned there isn't anything notable showing up in the log file. What console are you referring to that would display the stacktraces?

I assumed you were referring to the cmd terminal, but I couldn't find any guides on how to launch a minecraft installation in it using the new launcher.

Details that I can provide:

What happened?

With MCXR installed, but in flatscreen/non-vr mode, entities and particles are not rendered.

Screenshots

Relevant log output

Nothing stands out as relevant, so here's all reneder-related warnings
...
[18:54:07] [Render thread/WARN]: Method overwrite conflict for method_22920 in sodium.mixins.json:features.buffer_builder.intrinsics.MixinBufferBuilder from mod sodium, previously written by net.coderbot.iris.mixin.vertices.block_rendering.MixinBufferBuilder_SeparateAo. Skipping method.
...
[18:54:10] [Render thread/WARN]: @Inject(@at("INVOKE")) Shift.BY=2 on mixins.iris.json:texture.MixinAbstractTexture from mod iris::handler$zlm000$iris$afterGenerateId exceeds the maximum allowed value: 0. Increase the value of maxShiftBy to suppress this warning.
...
[18:54:15] [Render thread/WARN]: Static binding violation: PRIVATE @overwrite method method_23182 in sodium.mixins.json:features.item.MixinItemRenderer from mod sodium cannot reduce visibiliy of PUBLIC target method, visibility will be upgraded.
...
[18:54:20] [Render thread/WARN]: [Triforce Patcher] gl_FragColor is not supported yet, please use gl_FragData! Assuming that the shaderpack author intended to use gl_FragData[0]...
...
[18:54:24] [Render thread/WARN]: Shader rendertype_entity_translucent_emissive could not find sampler named Sampler2 in the specified shader program.

Minecraft Version

Minecraft 1.19

Iris Version

Iris 1.2.5

Sodium Version

sodium 0.4.2+build.16

Operating System

Windows 10

What is your GPU?

RTX 3070

Java Version

java 17

I have the same issue as xanthousm. I'm guessing it has something to do with the depth buffer considering blocks render in the lower screen, except they have their sides colored according to the depth buffer (closer is white, farther away is darker greys). I'll do some digging and see if I can find the issue.

I have almost completely solved this with a few small problems left.
These problems are caused by how Iris works internally and I'm guessing will require some changes to the codebase.

Issue 1

Everything is rendering correctly apart from the hotbar.
This occurs because when Minecraft draws the GUI it renders some opaque pixels with an alpha of zero.
To solve this in a generic way MCXR has a gui post process shader we use to set the alpha to 1 for every pixel with depth != -1.

However Iris renders these pixels without writing to the depth buffer, which makes sense since they are technically fully transparent but it breaks MCXR's compatibility.
Also half the time the game is booted the hotbar renders normally to make debugging harder.
This bug always disappears when shaders are disabled.

Issue 2

The second issue is how Iris interferes with MCXR's model rendering.
We use custom RenderTypes and a defined draw order to render the player's GUI and hands in front of everything else. Iris interferes with this by ignoring the draw order by what I'm assuming is batched rendering.
The effects of this can be seen in the image -> The player's hands and the white ray should always be drawn over the GUI.
This bug does not disappear when shaders are disabled.

I'm not sure I will be able to solve these issues on my own without spending hours learning the ins and outs of Iris's backend so any help would be appreciated!

Does Issue 2 happen with shaders disabled? If not, it could be related to the in-world hand rendering that shader packs use.

If it happens in both cases, the main way to restore your own draw order would be to use your own BufferSource / VertexConsumerProvider that won't have Iris's batched entity rendering present.

@coderbot16

This bug does not disappear when shaders are disabled.

I have the same issue as xanthousm. I'm guessing it has something to do with the depth buffer considering blocks render in the lower screen, except they have their sides colored according to the depth buffer (closer is white, farther away is darker greys). I'll do some digging and see if I can find the issue.

From what I am aware of MCXR does not even USE a depth buffer so that could be a problem :/

MCXR almost certainly still uses a depth buffer, it's fundamental to Minecraft's rendering.

Could it be possible that Fabulous graphics is forced enabled? That’ll break entities and such as you’re saying.

In Non-VR mode it appears the issue is that entities / particles are drawn to their own framebuffer with vanilla shaders.
However AO and shadows are still applied.

In VR mode it looks like the same thing is happening, but there is some other issue causing terrain to be invisible.

I'm going to spend a bit more time digging into this and try to fix Non-VR mode since it's not supposed to be interfering with rendering at all.

Hi lead dev of MCXR here sorry for only just showing up, this issue has flown under my radar since I've been busy with other projects. I don't have my headset with me ATM but I've been working on a virtual OpenXR runtime to allow MCXR to work without one.

More importantly this vitual runtime makes it easier to debug issues like this by not breaking RenderDoc so I can get started on this without wanting to put my head through a wall.

I'm afraid that was one of the first things I checked and other bugs have also started popping up. Framebuffer sizes are getting out of sync and it's possible to view the framebuffer non-terrain (non-terrain meaning entities, particles and the block outline) is rendered to by resizing the window but attempting to screenshot this causes a corrupted png.

I feel it is going to be faster to scrap my iris compat and rebuild it from scratch than to attempt to fix each of these bugs individually. I built it to be a one shot solution for both canvas and sodium + iris but the two codebases have diverged enough that its no longer ideal / possible, not to mention the numerous other rendering glitches it has picked up.

That's fantastic news, I had thought this might've been on Iris. Good to know it wasn't!

EDIT: Once the update is released, I'll close the issue.

EDIT: please ignore the issue closure, still not fixed.

I'm back home now so I can get back to effectively working on this.

Thanks to some 'Comment out the mixin and see' testing I've found that each bug can be traced back to two underlying conflicts. Both of these conflicts seem to be solvable without any needed changes to Iris.

Thanks for the tip coderbot it worked perfectly
I also tracked the hotbar issue back to a minor Iris bug which has now been fixed!

So I'll close the issue as it's been fixed now :)