Entities using wrong texture when using gaux as atlas texture in gbuffers
GeForceLegend opened this issue ยท 4 comments
What happened?
When setting gaux to atlas textures (like texture.gbuffers.gaux1 = minecraft:textures/atlas/blocks.png), and then using it in gbuffers_entities, gtexture (or tex) will become atlas texture. As far as I know it only affect Iris for NeoForge 1.21.1.
This is an example pack, edited from shaderLABS/Base-330, using gaux1 in gbuffers_entities for a dummy float that will not affect anything.
Screenshots
Log output
No response
Minecraft Version
Minecraft 1.21.1
Iris Version
iris-neoforge-1.8.6+mc1.21.1.jar
Operating System
Windows10
What is your GPU?
RTX 4070
Additional context
Renderdoc capture reference, showing there is a strage glBindTexture() (E11276) call wich changes texture 0 from pig texture into block atals texture, after E11260 set it to correct one.
The issue is related to the rendering position of NeoForge's particle engine.
Since Iris 1.8.1, when performing batched rendering of entities, the CustomTextureManager will use the setFilter operation on TextureAtlas. The AbstractTexture in version 1.21.1 does not verify the old filtering mode, but directly binds the texture and sets the filter.
The core problem lies in NeoForge's rendering process: before rendering translucent elements, there's an additional solid_particles phase. NeoForge's ParticleEngine will assign RenderSystem's activeTexture to texture unit 0 during the render method.
This causes the CustomTextureManager's setFilter operation to directly bind "minecraft:textures /atlas/blocks.png" to sampler 0 without checking the filtering mode, thereby overwriting the texture that should have been rendered.
The AbstractTexture in version 1.21.1 does not verify the old filtering mode, but directly binds the texture and sets the filter.
So will there be possibility, this call actually changes filtering mode, and then causes the same appearance as Iris 1.8.1+ for 1.21.1 NeoForge?