Have create + iris + sodium + indium + complimentary shaders while EMI is present.

Before:

After:

Well, I see the issue. You're tampering pretty heavily with the semantics of VertexConsumerProvider.Immediate, and that breaks Iris.

Basically, Iris knows that (excluding these changes made by EMI) VertexConsumerProvider.Immediate is generally drawn & flushed immediately and the content isn't held at all after flushing since it's encapsulated in private fields. So it figures out that it can safely disable vertex format extensions for things rendered to VertexConsumerProvider.Immediate outside of world rendering.

When EMI accesses the private fields of VertexConsumerProvider.Immediate, it breaks that expectation, resulting in data written with a non-extended vertex format being drawn to the screen with an extended vertex format in use.

EMI should instead just implement VertexConsumerProvider instead of hacking into VertexConsumerProvider.Immediate and changing how it fundamentally works.

While this optimization could be removed in Iris, it would result in a fairly substantial performance hit across the board, especially in F3. So I think that the best option would be for EMI to implement its own VertexConsumerProvider.

This route seems to have been successful, the next version of EMI will ship with a fix for this.

Lemma is right, Iris has some peculiar assumptions about vertex formats that has caused uv issues in other mods, and breaking here. You can disable EMI's batched rendering in the config which will be less performant, but should render correctly in the mean time. I don't believe this is something that can be fixed on EMI's end, but I'll keep the issue open for a while in case I discover something.

This is due to Iris breaking vertex formats and the fancy batched-render system EMI uses for performance.

I see, is this something thats been reported to iris already?

yep yep - we've been running into it with a few different things recently

Iris changes the vertex format of text because shader packs rely on having extra data about text being rendered in the world, but with the way Minecraft works that makes changing the vertex format of text even outside of the world unavoidable.

Iris 1.2.5 offers an IrisTextVertexSink API for writing text in an optimized way, if EMI wants to write text quickly without making assumptions about the text vertex format when Iris is installed it will need to use that.

Otherwise this isn't really fixable in Iris, other than by not giving shaders extended vertex attributes for text which would cause rendering issues with signs and maps in the world with some packs.

It looks like the broken things are the items, though, and I'm not really sure what would be going on with that other than EMI bypassing the vanilla BufferBuilder classes?

EMI's batched item rendering system doesn't use normal item rendering (which is slow and bad) and instead bakes items if it can, https://github.com/emilyploszaj/emi/blob/main/src/main/java/dev/emi/emi/screen/StackBatcher.java here's the file that does it, written by unascribed, it's a pretty reasonably sized thing

Well, I see the issue. You're tampering pretty heavily with the semantics of VertexConsumerProvider.Immediate, and that breaks Iris.

Basically, Iris knows that (excluding these changes made by EMI) VertexConsumerProvider.Immediate is generally drawn & flushed immediately and the content isn't held at all after flushing since it's encapsulated in private fields. So it figures out that it can safely disable vertex format extensions for things rendered to VertexConsumerProvider.Immediate outside of world rendering.

When EMI accesses the private fields of VertexConsumerProvider.Immediate, it breaks that expectation, resulting in data written with a non-extended vertex format being drawn to the screen with an extended vertex format in use.

EMI should instead just implement VertexConsumerProvider instead of hacking into VertexConsumerProvider.Immediate and changing how it fundamentally works.

While this optimization could be removed in Iris, it would result in a fairly substantial performance hit across the board, especially in F3. So I think that the best option would be for EMI to implement its own VertexConsumerProvider.

Fixed in 0.2.0, you can now use shaders with EMI's batched rendering mode.