Emissive textures Z-fighting
antieksi opened this issue · 41 comments
The resourcepack containing emissive textures here is Glowing.
Hello, I think I found a type of solution to this z fighting problem, it turns out that the mushrooms generate a level 1 light and it occurred to me that if the blocks with shiny textures generate z fighting only in the dark, what would happen if the flowers or blocks with these properties will shine? and then I found this Glowing Ores mod https://modrinth.com/mod/glore which literally lets us do this, so I installed it and in the mods folder 2 files are generated that allow us to modify the brightness level of the blocks and blocks that will have these properties, for example if the diamond ore has a shiny texture we add it to the file and give it a brightness level of 1, this way it will NEVER AGAIN have the z Fighting error :)
(I'm using Google Translate so sorry for my English)
Do you propose just adding the emissive texture to a normal one and making only its pixels to glow?
¿Propone simplemente agregar la textura emisiva a una normal y hacer que solo brillen sus píxeles?
Not exactly, in reality the idea is that the block (such as a diamond ore) which has an emissive texture is added a complete block making the z fighting imperceptible to the naked eye so instead of just making the pixels with the shiny property the point is for the entire block to shine
I guess it can be seen better on a video.
+1
I thought I was going insane and it was there the whole time. Seems its new!
The issue may be worsened by Sodium's compact vertex format. Regardless, it cannot really be fixed.
As a workaround, is possible to fix manually by removing pixels from the base texture that appear in the emissive texture, but this will cause those textures to look completely incorrect if emissive textures are disabled.
I just tried turning off smooth lighting and all Z-fighting stopped (including corner fighting), is that related to the vertex format?
Smooth Lighting is the weird cause of this, It seems. Turning it off makes it work fine, But the rest of the lighting then looks worse.
As a workaround, is possible to fix manually by removing pixels from the base texture that appear in the emissive texture, but this will cause those textures to look completely incorrect if emissive textures are disabled.
adding to this for anyone doing such;
blocks that naturally give off light seem to be unaffected (enchanting tables, crying obsidian, etc)
it's strictly non-light blocks that cause the z-fighting, which helps to slightly reduce the load for editing bigger emissive packs
this can be best seen with redstone ore; when unlit z-fighting is present, though when lit it's as expected (no z-fighting)
As a workaround, is possible to fix manually by removing pixels from the base texture that appear in the emissive texture, but this will cause those textures to look completely incorrect if emissive textures are disabled.
Is it possible to not render those pixels that are covered with emissive texture? AND to do it only when emissive textures are enabled.
Until this situation gets resolved, 3D ore packs using emissives may be unuseable.
I found a way to keep the emissives without the 3d textures.
This issue used to not exist. It seems a sudden affliction.
if i had to guess the recent sodium (& related (indium, iris)) updates caused it since downgrading back to previous versions leads to it being normal again
which isn't surprising given the sodium update broke a lot of mods, even some that you wouldn't expect like mod menu at least with what i've run into
Hoping this gets fixed. . .
Im still having issues, And dont feel like having to use shaders constantly for ores. For now I'll just use Reimagined, But F for my FPS.
Hopefully this can get a resolve. This is getting more annoying each time I have to deal with it. Sadge. . .
Do we have any ideas as to what is causing the issue?
It appears to be related to smooth shading as the z-fighting stops when you disable it
This bug has been bugging me for quite some time. Any new information on this bug?
emissive-plugin seems to have fixed this by offsetting all the vertices of the overlay by a tiny amount.
The underlying cause of the issue has been found. It is explained below. This issue only happens with Sodium and Indium.
Sodium changes the vertex order on certain quads based on their AO and lightmap values to fix a vanilla bug where smooth lighting looks different in different directions (https://bugs.mojang.com/browse/MC-136302). Indium inherits this fix by using logic similar to Sodium's in its own pipeline. The emissive z-fighting happens when the base quad and the emissive quad have different orientations; that is, one has a normal vertex order and the other has a flipped vertex order.
There is no simple fix to this issue. Any currently known fix is imperfect and may require adding a configuration option and may impact visuals (but not performance). A future release of Continuity may include a solution.
Even though this is a pretty tough bug, you continue working on this mod, and you do it for nothing. Just wanted to thank you for your work. Huge respect
MoreMcmeta seems to have fixed this same issue in their emissive plugin. Might be worth checking how they worked around the issue.
MoreMcmeta/emissive-plugin#10
No, it is not fixed in vanilla. The issue I linked may have been a duplicate. Here is a report of the same issue that is not closed.
https://bugs.mojang.com/browse/MC-138211
The underlying cause of the issue has been found. It is explained below. This issue only happens with Sodium and Indium.
Sodium changes the vertex order on certain quads based on their AO and lightmap values to fix a vanilla bug where smooth lighting looks different in different directions (https://bugs.mojang.com/browse/MC-136302). Indium inherits this fix by using logic similar to Sodium's in its own pipeline. The emissive z-fighting happens when the base quad and the emissive quad have different orientations; that is, one has a normal vertex order and the other has a flipped vertex order.
There is no simple fix to this issue. Any currently known fix is imperfect and may require adding a configuration option and may impact visuals (but not performance). A future release of Continuity may include a solution.
It seems like this but has been resolved in vanilla, so Sodium and Indium shouldn't have to implement their own fix. Correct me if I'm wrong.
Any updates on this? I can also confirm that this happens on Neoforge 47.1.79
with the Sinytra Connector mod.
Note: a fix was added in Embeddium, but is impossible to port in Sodium "the approach only works when all the quads are known up front (i.e. the way Forge works)".