
Painted Dimensional Transciever Rendering Error
forrester-marc opened this issue ยท 6 comments
Issue Description:
Painted dimensional transcievers render the transport field in front of the block geometry when active. Installing Optifine actually fixes this, which is not a sentence I ever expected to type.
Affected Versions (Do not use "latest"):
- EnderIO: 1.10.2-3.1.179
- EnderCore: 1.10.2-0.4.1.65-beta
- Minecraft: 1.10.2
- Forge: 1.10.2-12.18.3.2202-universal
The order and location in which TESRs are rendered is determined by vanilla/and or Forge code, we do not have any say in it.
I doubt Mojang can be convinced that this represents a bug, I guess the solution is to install Optifine.
I had a look at the code, I'm quite sure we can blame Forge---vanilla doesn't have transparent TESRs at all.
So here's what happens:
- The game draws all solid blocks.
- The game renders all solid TESRs.
- The game renders all translucent blocks.
- The game renders all translucent TESRs.
That means a TESR can either render behind all translucent blocks, or in front of them... :(
If I'm understanding that correctly, it is a minor bug in Forge, then. 3 and 4 should render the other way around, no?
It's a bit hard to wrap my brain around it, so I may be wrong: All translucent things should render ordered by distance from the camera. For solid pixels the GPU can track the distance from the camera per pixel, so painting something solid behind some pixels they came from something else will just do nothing. But for translucent things that won't work, as those have to be painted in the correct order for it to look right. You can see the effect e.g. by placing Hootch in front of a transceiver.
Since our last modpack update, Optifine no longer solves this issue. Apparently I had a bad config that was subtly glitching the display of all EnderIO blocks in a way that accidentally worked around this specific problem with TESRs. Looking through my backups in search of the exact version numbers and config.