Monitor not working with Optifine

I'm pulling this into the proper area for action. The original issue was posted on the Optifine issue tracker at sp614x/optifine#1237 Please refer to it since it contains good information.

Basically the CC Monitor renders as an empty box under Optifine. The cause is from having the Monitor
TileEntity and TESR keep track of the last animation frame so it only renders once per frame. I don't know why this is necessary. Optifine renders in two passes. The first is for volumes to create shadows and the second is for the actual surface rendering. The second pass never occurs due to this line.

[SquidDev]

So the above commit technically fixes this issue, but causes all sorts of other ones:

It also seems to have a fun swing from side-to-side as you walk. Rendering is really not my forte, so if anybody has ideas I'd love to hear them.

Thanks for the quick response. Looks like the character quads are Z fighting with the background. I'll see if I can reproduce it on my end.
I noticed that you didn't add any lighting code in that commit yet your screenshot shows a display that is clearly not black. That strikes me as strange. Did you do anything to fix that by chance?

[SquidDev]

I haven't touched the lighting code so was also rather surprised when it worked. Aside from a shaderpack I'm pretty sure I'm operating on default Optifine settings, so goodness knows what's going on. I don't know if it's specific to a particular set of shaders?

My "fix" was probably not the right way to go about it. I'll test with multiple shaderpacks and see what I come up with.
Fyi, I was using the SEUS shader pack during testing since I believe it is the most popular.

[SquidDev]

Ahhh, I was using Sildurs Vibrant. My laptop has an Intel graphics card, and so has a burning hatred of SEUS.

[Lignum]

From what i can tell, ComputerCraft renders the character quads and the background quads directly on top of each other, and tries to prevent z fighting with:

            GlStateManager.depthMask( false );

No idea why, but this hack may not work with shaders for whatever reason. There shouldn't be any harm in getting rid of that, and simply moving the character quads a tiny bit to the front.

@SquidDev Sildurs Vibrant Lite I presume? Since your hash brown of a video card can't really handle anything more?

[SquidDev]

Looks like the character quads are Z fighting with the background. I'll see if I can reproduce it on my end.

From what i can tell, ComputerCraft renders the character quads and the background quads directly on top of each other, and tries to prevent z fighting with: GlStateManager.depthMask( false );

I had a bit more of a play and it doesn't appear that this is an issue with character z fighting: it occurs even with a flat background. Removing the depth mask setter (and shifting characters) has no effect on the end result.

It's also worth noting that the player's shadow is substantially darker on monitors than any other block (you can see the change on the transition from border to monitor at the bottom).

Sildurs Vibrant Lite I presume? Since your hash brown of a video card can't really handle anything more?

Yep.

Edit: Using Lignumn's rewrite branch does prevent the black artifacts but still results in weird vertical warps. There's a download here if people want to experiment.

Using MC 1.12.2 Sildurs Vibrant Lite on NVidia GTX 970 LinuxMint:

For these results I simply commented out the return on line 56.

The following image is with
OpenGlHelper.setLightmapTextureCoords(OpenGlHelper.lightmapTexUnit, 0, 0xFF);
added before

// Draw the contents
GlStateManager.depthMask( false );

This is without the setLightmapTextureCoords(Presumably how yours is setup)

[SquidDev]

OK, if the artefacts are just due to my graphics card being awful then that's fine. Thanks for looking into it! Out of interest, how does this render in a night-time/darkened scene? Just want to check the monitor "glow" still works.

Edit: Testing on my computer results in the glow being dependent on daylight levels, even if the monitor is underground. I'm not too sure why this is, or if it's just my computer being silly. It's not the end of the world, but would be nice to fix.

I was going to ask about that. Are the monitor displays supposed to glow? The setLightmapTextureCoords code I suggested adding does make the monitor glow regardless of daylight with shaders. Even when underground in the dark. I turned shaders OFF entirely and then disabled the setLightmapTextureCoords I added and it still glows underground. So I figured that's just the way it's supposed to work since CRT/LCD/LED monitors are emissive devices IRL. I'm guessing that at some point it was an added feature to "glow".
I'm kinda new to 1.12.2 and I didn't remember them ever doing that so I went back to MC 1.7.10 CC and the monitors don't glow in the dark. So.. my mind.. it is boggled.

Edit: I see what you mean. The time of day affects the screen brightness. Even when underground.

[SquidDev]

I'm kinda new to 1.12.2 and I didn't remember them ever doing that so I went back to MC 1.7.10 CC and the monitors don't glow in the dark. So.. my mind.. it is boggled

Yeah, it was only added in 1.10.2. One of the first changes after being open sourced IIRC. Glad it's working though - I'll add that to the PR. I also need to check that rendering is correct when some monitors are outside the view frustrum - I'm not entirely sure my previous commit gets things entirety correct.

Edit: Yay, concurrent edits are confusing. I'm rather curious as to where the lightmap numbers you gave came from? I've had a prod through MC's code and it's rather like black magic.

Setting the second parameter to 255 can correct the day/night thing but with some shader packs the monitor turns more amber(or whatever torchy color the pack provides) at night because of the color map applied during that time of day.

OpenGlHelper.setLightmapTextureCoords(OpenGlHelper.lightmapTexUnit, 0xFF, 0xFF);

Using this function was the only way I could get the color mapping to work right(Edit: I mean at all). There's probably a better call to use that's not dependent on the time of day but I haven't found it yet.
mc.entityRenderer.disableLightmap(); does not seem to have an affect(under Optifine with shaders).

sp614x refers to 4 issues on the Optifine issue I referred to at the beginning of this issue where the lightmap problem is similar.

The lightmap texture coordinates problem may be related to these: #sp614x/optifine/issues/417, #sp614x/optifine/issues/1305, #sp614x/optifine/issues/631, #sp614x/optifine/issues/302

According to those issues the problem seems too complicated to be fixed any time soon. But the solution we came up with is at least better than nothing until the problem with Optifine's emmisive texture problem is properly resolved. The solution also doesn't seem to affect the rendering when Optifine is disabled or not installed.

Yay, concurrent edits are confusing. I'm rather curious as to where the lightmap numbers you gave came from? I've had a prod through MC's code and it's rather like black magic.

The 255 values are just the maximum TorchLight(Block) and Daylight(Sky). The values are used in a big lookup table in the form of a texture and can be changed via resourcepacks/shaders.

The resulting color is multiplied with the color of the texture itself. I know it says 0 - 15 but for some reason the function expects 0 - 255.