Continuity

Continuity

9M Downloads

Emissive textures Z-fighting

antieksi opened this issue · 41 comments

commented

изображение

The resourcepack containing emissive textures here is Glowing.

commented

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)
Captura de pantalla 2024-05-31 011559

commented

Do you propose just adding the emissive texture to a normal one and making only its pixels to glow?

commented

2024-05-31_10 17 45
2024-05-31_10 19 11

¿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

commented

I guess it can be seen better on a video.

https://i.imgur.com/v23d4HL.mp4

commented

I am also having the same issue, and with some testing I've found the z-fighting seems to occur on certain corners. The behaviour occurs on multiple packs with emissive textures.

A flat 5x5 plane:
image

The same plane with a block placed in the center (z-fighting highlighted):
image

commented

I have the same problem no other mods than Sodium Indium and Continuity

commented

+1

I thought I was going insane and it was there the whole time. Seems its new!

commented

i think the newest indium update fixed the issue

commented

I'll check!

commented

Doesnt seem like it. . .

commented

The issue is worse now, and different faces are affected. Up to three faces per corner can be affected.
Emissive issue 2

It also interacts with light levels strangely (non-fighting blocks removed for clarity)
Emissive issue 3

commented

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.

commented

I just tried turning off smooth lighting and all Z-fighting stopped (including corner fighting), is that related to the vertex format?

commented

No.

commented

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.

commented

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)

commented

This issue used to not exist. It seems a sudden affliction.

commented

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.

commented

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.

commented

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

commented

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.

commented

Hopefully this can get a resolve. This is getting more annoying each time I have to deal with it. Sadge. . .

commented

Still could use an update on how to resolve this. . .

commented

Do we have any ideas as to what is causing the issue?

commented

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

commented

Confirmed. Smooth Lighting is the seeming cause

commented

Any updates?

commented

No

commented

Yeesh. This may never get fixed. Depressing too. . .

commented

A video from a previous test.

2023-07-12_14-35-29_h265.mp4
commented

This bug has been bugging me for quite some time. Any new information on this bug?

commented

emissive-plugin seems to have fixed this by offsetting all the vertices of the overlay by a tiny amount.

commented

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.

commented

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

commented

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

commented

I tried patching it by just removing the textures under the emissive layer manually and, uh... that didn't work lol

image

I hope to see an eventual real fix to this bug!

commented

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

commented

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.

commented

Any updates on this? I can also confirm that this happens on Neoforge 47.1.79 with the Sinytra Connector mod.

commented

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)".

commented

any updates on this?