jonathan2520

I saw the same Reddit post and decided to investigate. I skimmed MCP 1.12 because I still have it lying around and that version is affected.

In what it calls EntityBoat’s updateFallState, if the boat’s status is not ON_LAND, fall damage is nullified. That will be the case when falling from most heights, because the last time the boat’s status was updated was before it hit the ground. There is only a small exception because the boat checks blocks up to a thousandth of a block below it when updating its status. If it ends up just barely above the ground, its status becomes ON_LAND before hitting the ground, allowing fall damage to take effect.

This happens at the given heights because gravity subtracts 0.04F from the boat’s Y velocity. If it were exactly 0.04, the boat would have fallen an integral number of blocks every 2 ticks out of 25: 12, 13; 49, 51; 111, 114; 198, 202; and so on. The boat ends up falling very slightly less than that because 0.04F is rounded down as a 32-bit float, placing it just above the ground and allowing it to become ON_LAND before hitting it.

Speaking as the person who has contributed a lot to this report in the past and is still the ‘reporter’, I believe this has been largely fixed for a long time. The remaining problems are nothing compared to the problems we used to have. The description and early screenshots and comments are mostly obsolete.

Cases that reveal cracks are pretty contrived in 1.16.1, still on that GeForce GT 750M. (Haven’t tested others right now. It’s possible others still don’t get sufficient compensation for their imprecision.) Even things like snow layers join nicely now. You need a sub-block height difference (or some other imperfect alignment like a fencepost on grass) to get ill-defined geometry, but those differences aren’t all over your screen, and the seam is masked to a large extent by genuine geometry. Minor intra-block cracking still exists in complex blocks like hoppers and stairs. This is becoming technically harder to fix. If we didn’t have a precedent in this report making us look for cracks everywhere, I think few would report it or really notice at all.

3D extrusion of 2D cutouts (like a sword in your hand or on the ground) is still a big problem. That’s at the original level of this report. Fancy clouds are similar. Definitely worth keeping a report for those.

Other than that, the main cause with the most severe presentation seems to be forcing something like multisampling or anisotropic filtering on Minecraft. There’s little Minecraft can do about that without changing to less flexible and/or efficient rendering. Multisampling can work if you also force centroid sampling. Supersampling should be fine. Post-processing techniques should be fine. I don’t know what Optifine does. It’s possible anisotropic filtering without mipmaps (as if that would look so great) works if it’s like the way Minecraft implemented anisotropic filtering before abandoning it. But none of this is Minecraft’s problem.

What about this report? I guess I’m an expert but I’m not really involved anymore. It’s a mess with its long history of many incarnations of the problem as well as people overriding settings. To keep it manageable, at least mention your GPU and be specific about the problem when you say confirmed for xx. Don’t report if you’re using Optifine or graphical overrides, and the problem doesn’t also show up without those.

@unknown: This is a distinct problem. It’s a floating-point precision issue. Note that the chest is mostly centered in view, nowhere near the 30 degrees indicated there for a hard pan. Note that the save puts you out at 30 million blocks. This problem does not occur near the origin. 32-bit floats have a precision of 2 blocks at 30 million, which seems about right given the way it sounds and changes in distinct steps as you move around. With all the recent changes in this regard like particles getting proper precision, it’s only natural for audio to follow suit.

It seems silly to make a new report just because the manifestation has changed slightly. The corners are in fact not connected. It was never specifically about gaps, even though that can still happen due to rounding in the rasterizer (which you can prevent by supplying it with robust geometry) and those lines might as well be gaps from a distance.

Confirmed for 1.12.1.

I actually found this while looking around in MCP; I normally disable clouds. The issue is that different parts of the world use a different far plane for their projection matrix. That doesn't just move the clip plane: depth values are scaled to match! Changing this in the middle of a scene is a big no-no. It doesn't have too much of an effect because most depth values are concentrated near the camera, but with geometry at the far end you'll definitely see it. Decrease your render distance to make the effect more pronounced.

The far plane distance is the render distance multiplied by:

Just use 4 for everything if that's what you need. Move it to infinity or beyond. Really only the near plane matters for depth resolution. The nearest possible far plane in Minecraft at 32√2 provides only 0.11% more depth resolution than a far plane at infinity. There's really no benefit.

I've verified that the threesome routine still exists in 1.12's code. That will be all until it's clear this report isn't just a black hole where our combined efforts disappear.

Minecraft's rcon implementation is nothing but a quick hack. Every shortcut that doesn't prevent it from working at all was taken. You may remember MC-87863 as well. I say they should just rewrite it from scratch. They wouldn't be throwing much away anyway.

Yes, only while running commands. I guess if no players are on the server, entities aren't active, preventing a race condition there. Not that I've tried this recently or extensively. I ran into it when I was trying to load large structures into a live world programmatically. Using commands like setblock and fill in/around water causes a crash very quickly. Must be all the block updates of water trying to flow everywhere while blocks are simultaneously being replaced by rcon.

LWJGL has been implicated before. I think there's a mention out somewhere else that LWJGL 3 would fix it.

It certainly has nothing to do with the kernel. The kernels aren't even the same. What GNU/Linux and macOS share is a similar command line and POSIX-ish mid-level programming environment. Both higher and lower levels are fundamentally different. The relevant difference is in the UI APIs and how they're (ab)used by Minecraft and its libraries.

Actually, what I'm thinking of is MC-113931. I skimmed a little too fast. I don't mind empty saved hotbars, just how easy it is to have problems with any saved hotbars. That report isn't doing any better, though.

I agree this really is a problem. It's bad design that will be changed sooner or later. No way this will survive the backlash once 1.12 is released. So why not admit it right now?

This is so much worse now that command+digit saves hotbars in 17w06a. It was reported separately as MC-113915. It is really a duplicate of this one, but it alone is bigger than this used to be. Please expedite fixing.

This image that @unknown just uploaded is of a resource pack. Still, I think it's a fitting demonstration because Minecraft makes it difficult to model that sort of thing. You have to know what robust geometry entails and correct for the piston head problem to get good results.

I happen to have done it 'right' for ladders once. At the time I didn't know the proper corrections to apply, but what I did was good enough to work out. Still, the edges of the ladder don't line up with the dirt texture behind it. One more thing that's made worse by Minecraft's correction, but is also very difficult to solve entirely:

I think we'll have to accept that these interactions won't be solved. But at least individual parts can be made to work.

I did just try to make Minecraft use premultiplication. Turns out OpenGL is abstracted away enough to get away with a few hooks to adjust colors and blend functions. For the most part things look okay. But there's one major problem: fixed-function fog can't deal with premultiplication. Transparent stuff in the distance (water, clouds, stained glass, …) turns bright white. The general solution is to do the right calculation per fragment, which requires a fragment shader. So probably not going to happen for now.

An observation with my change to mipmap generation (and without the premultiplication stuff from above) is that leaves keep some holes in the distance even with mipmaps enabled. Normally they become darker and entirely opaque with mipmaps, for the same reason the uglier problems with mipmaps occur. Opacification is a side effect of gamma correction of the alpha channel, pushing it over the alpha test reference more easily. I explicitly took that out because it's nonsense.

Although the transparency introduced by my patch would be expected for transparent leaves, I must admit I liked the shimmer-free look of opaque leaves. I've never been able to decide what's better. If you want to, you can reintroduce the opacifying behavior on top of my mipmap generation by sRGB-decoding the reference alpha passed to glAlphaFunc. Where 0.5 is currently passed to render stuff like leaves, you'd pass ((0.5+0.055)/(1+0.055))^2.4 ≈ 0.214. The result will be virtually identical, except all the other problems like darkening and blend opacification will be gone.

I think this will be the final comment for now. Definitely enough analysis. The minimally invasive patch that I posted solves most of the problem with minimal regression potential. I'm putting my money on that.

Some more observations:

Minecraft uses interpolation between mipmaps (GL_NEAREST_MIPMAP_LINEAR). That's what I remembered but the hard transitions to darkness on the side of grass threw me for a loop. What even causes those? Anyway, that interpolation sans premultiplication can cause further artifacts. The hard pixel art edges in Minecraft's textures make that as bad as it can be. It's also a case where my preservation of invisible colors can reduce the ensuing artifacts, if source images are authored with sensible invisible colors which they generally aren't. I guess it may be better to process the mipmap pyramid in reverse afterward, using the color of the lower-res mipmap to replace invisible colors. That will catch the worst of it regardless of authoring. You could actually do it in the forward pass because you only need to propagate back one level.

I don't know the full pipeline that well. If I did I might've been able to experiment with some more stuff like premultiplication. (Very invasive, requiring adjustments to all blend functions and colors passed to OpenGL. Would also have to check for pure alpha testing without blending which doesn't play nicely with it.) Oh well. Not like it or the work I've done so far is going to accomplish much anyway until Mojang sees it, which could take a while.

The sRGB constant I called alpha is really called a. What's in a name?

Both water and stained glass now work on a block by block basis. It seems sections aren't really relevant anymore. Just gotta fix the title then.

Here's a proof of concept based on MCP 9.37/Minecraft 1.11.2. Put the Java files in example/jonathan2520 (next to Start.java) as indicated by the package. In net.minecraft.client.renderer.texture.TextureUtil, change the line

aint2[i1 + j1 * j] = blendColors(aint1[k1 + 0], aint1[k1 + 1], aint1[k1 + 0 + l], aint1[k1 + 1 + l], flag);

to

aint2[i1 + j1 * j] = example.jonathan2520.SRGBAverager.average(aint1[k1 + 0], aint1[k1 + 1], aint1[k1 + 0 + l], aint1[k1 + 1 + l]);

Full changes:

• Proper weighting by alpha channel, obviously.

• Proper sRGB.

• According to the new model, if all four inputs are entirely transparent, the color is undefined. (Kind of like the Invisible Pink Unicorn. No way to tell from its appearance that it's supposed to be pink.) I've defined it by using an unweighted average in that case. Minecraft originally made it black. Doesn't really matter, I think, but there it is.

• Removed the special case where if at least one texel in the entire texture/atlas was fully transparent, alpha values under 96 would be cut to 0. Might serve some purpose but I don't see sense in it and it's inconvenient. It can be re-added if necessary.

• Although I haven't benchmarked, it should be significantly faster. For starters, all 4 Math.pow calls are gone. I came up with a table-based sRGB encoding scheme that's simple, fast and exact.

Indeed, it fixes the black edges around fire as well.

@unknown: Yes, looks like it! Good catch. If I end up making a proof of concept mod, I'll include a burning mob in the screenshots which should demonstrate it nicely.

I agree it's fixed in 16w50a. Well, as good as it was before 1.8 when problems weren't so blatant. My remarks about further improvements still stand. But let's call it fixed for now. Thanks for sticking with it, Grum!

1.11-pre1 (and now the release) is mostly correct! I'm still marking it because disabled interpolation from a previous purported fix is still there. The thing where the selection box tends to lead you when you sprint. In MCP parlance, renderWorld needs getMouseOver(partialTicks), not getMouseOver(1.0F). As I mentioned before, interpolation conveniently doesn't do anything for angles updated by setAngles, so once you're using those it doesn't incur any mouse look delay.