[Bug] Z-Fighting in Segment Displays When Using Embeddium

[puncrafter]

Minecraft version

1.20.x

CodeChickenLib version

4.4.0.512

CBMultipart version

3.3.0.146

ProjectRed version

4.19.0

What happened?

Normally, the segment display works just fine. However, something about the way Embeddium changes rendering causes Z-fighting on the numbers in the segment display. I'm not too sure if this should be written as an Embeddium issue or a ProjectRed one, but I figured it was worth mentioning.

Crash log

Didn't Crash

How do you make it happen again?

Hook up a segment display to a bus input panel, toggle as many or as few of the buttons as you wish, and notice the difference between the numbers with and without embeddium running. Attached are screenshots. Without embeddium: With embeddium:

[MrTJP]

Hmm. I can try to slightly increase the layer separation but no idea why it happens. Embeddium has several features that can be turned on/off. If you can find the exact one that causes this, I may be able to dig further.

[embeddedt]

This is probably caused by Embeddium's compact vertex format, which uses (scaled) 16-bit floats for vertex positions instead of 32-bit floats. Embeddium has logic to mitigate issues this causes with JSON models by trying to increase separation automatically, but this doesn't apply to any custom models/CCL rendering because guessing the correct behavior in general is hard.

The CVF can be easily disabled in video settings in case of mod conflicts like this.

[MrTJP]

Ok cool, so I can just increase separation. I used some arbitrarily tiny value to avoid z-fighting with the background on which the segments sit. Do you know what the minimum separation has to be?

[embeddedt]

In a JSON model (where valid coordinates for elements within a one-block space range from 0 to 16), it's 0.008. However, the actual baked quad rendering uses coordinates divided by 16, so I think the minimum separation would need to be divided as well, meaning 0.0005 should be enough.