Tile semi-transparent preview overlay and shaders
sonicether opened this issue · 1 comments
So, I decided to look into what could be causing the glitched appearance of the overlay that is rendered for tiles (about to be placed, or using the chisel) in the world. Some shaders don't render it at all (SEUS PTGI is among those). The best I've seen is something that looks like this: https://i.imgur.com/zkpzcb5.png
I don't know if there are any out there that properly render this, but I've figured out why this happens, at least on the shader side. It seems that OptiFine thinks that these render features are "gbuffers_textured" and get rendered with that program, along with all other block particles in the game. For block particles to render properly, the texture in slot 0 (labeled "texture", see https://github.com/sp614x/optifine/blob/287e3d7c25dc3846be18d8ab7cf6704910605361/OptiFineDoc/doc/shaders.txt#L189) must be displayed in this program (gbuffers_textured.fsh). Upon removing this texture lookup so that only gl_Color determines the color to output, the rendering glitches are fixed and the tile previews render as intended.
So, this indicates that the texture that is bound to slot 0 is undefined, which explains the strange random behavior and noisy image. If I understand the situation correctly, shader developers cannot fundamentally fix this issue without also not rendering textures on block particles (like when mining). Sadly, I don't know enough about the inner workings of Forge/OptiFine/Minecraft modding to suggest a solution. Perhaps you could bind a simple 1x1 white pixel texture before the draw call to render the tile previews.
I did think of a workaround, which goes something like this, where "color" is the vertex color (gl_Color). I don't know if this workaround will break other things, though.
if (color.a < 0.99)
{
gl_FragData[0] = color;
}
else
{
gl_FragData[0] = texture2D(texture, texcoord.st) * color;
}
I hope this provides some information you didn't already know. Thanks for your amazing work!
