Monitor not working with Optifine

[ferreusveritas]

I'm pulling this into the proper area for action. The original issue was posted on the Optifine issue tracker at https://github.com/sp614x/optifine/issues/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.

[ferreusveritas]

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?

[ferreusveritas]

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.

[ferreusveritas]

@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.

[ferreusveritas]

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.

[ferreusveritas]

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.

[ferreusveritas]

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.

[ferreusveritas]

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.

[SquidDev]

Thanks for the explanation! That's pretty much what I'd assumed, but wasn't entirely sure of the layout - now it makes much more sense :).

The issues linked on the Optifine tracker are definitely similar (sp614x/optifine#631 especially), and don't offer much hope. That being said, they do seem to largely refer to Forge's rendering pipeline, which isn't utilised here - disableLightmap is vanilla code.

Anyway, that's rather outside the scope of this issue - I'll add the lightmap call to the PR :). Thank you so much for all your help and diagnosis/fixing of the problem!

[ferreusveritas]

Thank you for carrying the CC torch as far as you have! I'm very grateful for your efforts. So is Lignumn's rewrite the most up to date version?

Edit: Derp. How about SquidDev-CC/ComputerCraft. Yeah. That's probably the one I want. ;)

[Lignum]

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.

During the rewrite, I tried to minimise the amount of OpenGL state being set, as that usually leads to bugs. I found that a lot of the state changes ComputerCraft made were redundant (including depthMask). Since the rewrite isn't ready yet, I suggest we just extract the GL state code from the rewrite, and apply it here (might want to exclude depthMask from that), it should work the same, display lists or not. That still won't fix it, but if, as you say, it's less buggy, then that's a start.

So is Lignumn's rewrite the most up to date version?

Not really, it's far from ready. It's really a rewrite of the entire terminal rendering code, creating a shared code base for all terminal-like displays, instead of copy & pasting it in everywhere, like it's currently done. Currently, computer terminals don't render correctly (should be easy to fix, I'm just lazy), and they lag a bit (this is due to some weirdness with detecting terminal changes, that's more difficult), so I don't recommend using it, it's far from stable.

[SquidDev]

I had a bit of a fiddle with some other lighting options, trying to see what other mods did, but to no avail. It's not optimal, but seems like the lightmap solution will have to do.

So is Lignumn's rewrite the most up to date version?

Blughr, it's messy: I've got a branch (#507) which rewrites the monitors on the server and bundles some additional monitor fixes in order to avoid PR-dependency hell. Lignum's rewrites the client side handling of terminals (and so monitors).

That still won't fix it, but if, as you say, it's less buggy, then that's a start.

I think this is just my graphics card being one Yorkshire pudding short of a roast. It only appears to occur on monitors facing one direction and there's all sorts of similar artefacts on normal blocks. Adding the lightmap change appears to fix it, so I don't think it's worth worrying about.

[Injen]

ComputerCraft and Shaders

Hi to all. I was looking for a solution just like you in MC1.7.10 Im using SEUS v.11.

Here is: Options -> Graphic Settings -> Shaders -> Shaders Settings -> Lighting and Shadow Options -> Global Illumination -> set OFF. Done.