Describe the bug
When you have a cable that passes through a facade, and has a junction on the block after the facade, some Z-fighting occurs where the cable narrows down:

To Reproduce

This is without the facade, to get an idea of the setup:

Expected behavior
I'd expect either only the narrow part of the cable to show, or the wider part of cable to be consistently visible.

Additional context
(No relevant logs, as there aren't any errors or crashes)

Environment
MC 1.16.4
forge-1.16.5-geckolib-3.0.4a
appliedenergistics2-8.2.0-beta.3

I'm running the FTB Direwold20 1.16 modpack, version 1.5.1

would making the cable cores a pixel or two (not "MC pixel", but actual pixel) smaller solve the issue? the cable core plane would be inside the facade, so would never get rendered anyways. I know it seems like a lazy solution, but would work in absence of passing neighbor data. (also aware that would make the cores no longer perfect proportional squares, which may make it a no-go from an asthetic standpoint.)

Yes that is how these issues are generally fixed. :)

This specific issue cannot be reproduced in 1.19.4.

Cannot reproduce this. Please provide the requested details mentioned in the issue template when submitting it.

Also note that mods like optifine and similar can and most likely will cause these issues.

forge-1.16.5-geckolib-3.0.4a... what is this?

That's the rather bad file naming of geckolib, for some reason they put the loader in front of the mod name...

Here we go.

I've made a fresh forge install from forge-1.16.4-35.1.4-installer.jar and added appliedenergistics2-8.2.0-beta.3.jar in the mods folder of that installation, there are no other mods in there.

Tahakk, I don't know what your relation is to AE2, but you're not being very friendly.

It's general advice every time you need to find bad apple in bunch. Just start with one and add more until it goes wrong. So far trying to remove/add mods is the easiest way before you get to different software/hardware differences. So nothing against you.

As far as I can say I tried different versions of forge/AE2 and can confirm this issue (only AE, JEI installed).

//EDIT

happening on every rotation + dense cables also

I guess we got off on the wrong foot, let's forget about that :-)

I'm not using something as significant as optifine, I'm not sure what other details I can add, there are no crashes or anything of the sort, so I'm not sure logs can be relevant.

The z-fighting depends on the angle you're looking at the cable. some angles are fine, other show either the facade or that face of the cable, or a partial combination of the 2.

Here's a list of all the mods in the modpack, including some I added / updated:
https://pastebin.com/nGqrNwbw

I'm on Windows 10, GeForce RTX 2070 with updated drivers (457.09)

In regard to forge-1.16.5-geckolib-3.0.4a, I thought that was the forge version 😅

If there is anything else you need, please let me know!

Well at the end if it's not reproduceable you should start with AE loaded only and slowly add mods to see when the cable start's acting up. That is the case if you really want to figure it out.

This happens because the facades do not take the bounding boxes of the cable itself into account, only the ones by parts attached to it.

Currently there is no way to take them into account without introducing some other artifacts like a facade between two cable cores would render a bigger hole than the cable itself as in this case it will be a thinner cable. Changing this would require the cable to be aware of its surroundings on the serverside itself, which would require a pretty big change for a small visual glitch.

So for now I would consider as something we will not fix in the foreseeable future.

Thanks for the explanation. Yea, I can see how that'd be too much.

@Cerbrus yes, works in any case. And it would also only appear when 2 cores are directly adjacent and a facade is between them. Every other case won't have the too wide hole. Should we also ever fix how collision boxes are handled, it would automatically fix itself and don't render a hole.

@Tahakk Possible yes, feasible no. It would pretty much require a complete refactoring on how cables are handled serverside.

Currently they know nothing about their neighbours, except for "there is something else". That would need to be changed to also provide details about every adjacent cable/block, their cable type and so on. Clientside that's fine because it's limited to a pretty much fixed amount of chunks (render distance). But serverside that can easily add a bit additional memory requirement for a pretty minor glitch.

Or some other issues like this depends on/affects collision boxes and it would need all adjacent blocks to calculate them.
Leading to some funny behaviours like a zombie walking into a cable, which then loads the adjacent chunk to calculate the collision box and then start a cascade because in that chunk a sheep is trapped under a cable in a water block and is constantly jumping into the cable to load further chunks.

Alternatively this would be the easy fix

Hm, not bad, but would that work on the dense cables?

Wouldn't be also possible to make them size 4 (smaller) when they go trough the facade? Then you won't be able to see z-fighting