mojira.dev
MC-1794

White stitching on polygon edges / White lines or black dots between blocks

Reopened
603

Mod notice

This issue is often caused by settings within Nvidia graphics drivers. These can be edited through the NVIDIA Control Panel, which can be opened by right-clicking on your PC desktop, or by searching in the Windows start menu. The following settings can be changed:

  • Under Adjust image settings with preview, set the default to Let the 3D application decide

  • Under Manage 3D settings:

    • Disable Anisotropic Filtering

    • Disable Antialiasing

Some users have also reported this issue to be reduced when changing the level of Mipmap under the Minecraft Video Settings (lowering to 0).

Optifine has some advanced settings that might fix this issue. Note however that this might have performance penalties and Optifine is not supported by Mojang or this bug tracker.

Update: The cracks between 16x16x16 sections have existed for a long time, and still do. Crack theory has been, is, and will still be applicable. The lines that started to appear in between every block in the 1.5 snapshots and should be fixed in 1.5.1 were caused by texture coordinates overflowing their tile slightly in the rasterizer.

Crack theory

Cracks occur in rasterizers like OpenGL when edges that should align don't match exactly. This can happen if an inexact calculation is used, and vertices that should be the same end up in slightly different places. The errors may seem minuscule, but they invariably result in severe flickering along the cracks. The rasterizer will miss a few pixels and fill others twice. Using different OpenGL transformations to move different vertices to the same place counts as inexact:

glRectf(0, 0, 1, 1);
glRectf(1, 0, 2, 1);
glRectf(0, 0, 1, 1);
glTranslatef(0, 0, 1);
glRectf(0, 0, 1, 1);

The former will always, unquestionably align. The latter will have a crack. While associativity would tell us that both examples are the same, rounding error does not succumb to associativity. 32-bit floats are exact for integers in

[media]

, scaled by a power of two. 64-bit doubles reach a whopping 2^53. If both operands of an addition are round enough (in binary), the result will be exact. This would be typical for code like the first example. Rolling the same addition into a transformation matrix will almost certainly be inexact, because the matrix is polluted by everything else in it. Really the only way to get it right is to perform a separate addition before the matrix.

If you perform the addition in a vertex shader, keep it separate and it should be okay, save for the hypothetical implementation that optimizes both into a matrix (if they're still technically allowed to optimize willy-nilly nowadays):
Edit: Uniform state is slow to change, so an attribute used like a uniform would likely be faster than a uniform.

uniform vec3 translation;
void main() {
    vec4 vertex = gl_Vertex;
    vertex.xyz += translation;
    gl_Position = gl_ModelViewProjectionMatrix * vertex;
}

What's cool about this is that even if you're very far from the world origin, you can still keep everything that matters exact. It also doesn't have a stepping or distortion problem in the Far Lands. The CPU code should do something like this:

dvec3 camera;
dvec3 roundedCamera = camera.roundToMultipleOf(16); // Assuming your world transformations are normally a multiple of 16. Can be demoted to float if you stay within 16 * 2^24 blocks. This is half of the magic, by reducing the translation fed into OpenGL to almost nothing.
dvec3 difference = offset - rounded; // Not critical and rather small; can be demoted to float, and will be when fed to OpenGL.
// Substitute difference for camera when calculating the camera transformation.

Then, before drawing each batch:

dvec3 translationOfBatch; // Can be float if roundedCamera can be.
dvec3 translation = translationOfBatch - roundedCamera; // This is the other half of the magic. Two potentially huge numbers are reduced to a small, exact multiple of 16. Can certainly be demoted to float, and will be.
// Load the uniform.

I hope this is enough theory to help you understand and fix cracks. Now, on to the actual problem description:

Description

Previously, cracks would only appear in between 16x16x16 sections. Not as it should be either, but hardly worth reporting. In the latest snapshots, however, they appear in between every single block. That is too much.

The screenshot shows a superflat world with preset "2;7,62x0,49;2", viewed from below. It should be viewed at its full 1920x1200 size to see the speckles. Incidentally, Minecraft thinks it should light the underside of the obsidian when I get close to it.

Addendum: textures?

After noticing the directionality of the cracks, I realized it's crossing over into adjacent tiles on the texture. That could explain some or all of this bug. I will upload a second screenshot demonstrating that. It's of a similar superflat world, but using purple wool (35:10) instead of obsidian.

What you see is a close-up of the vertex joining four blocks. You can see some yellow seeping through one edge, and blue through the other. Indeed, those are wool blocks adjacent to the right and below, respectively, in stitched_terrain.png generated by an older snapshot. There is also some sky showing through next to the blue wool (I know it's the sky because it becomes black at night). I'd expect it to be orange wool as that is located above it in stitched_terrain.png, but then that file is probably outdated. It may well be that the adjacent texture is transparent. Indeed, green wool doesn't have this 'crack'. Texture coordinates should be the only difference between wool colors, therefore this should be responsible.

Older versions of Minecraft used to move their texture coordinates inward just a tiny amount to avoid this issue. Was that tweak removed when the rendering engine was overhauled?

Linked issues

is duplicated by 375

MC-2203 Textures / Model of anvil not properly aligned - transparent edges Resolved MC-3044 Bad texture swords Resolved MC-3338 Dots in sideways logs Resolved MC-6791 White lines between blocks Resolved MC-6821 Lines between nether bricks Resolved
370 more links

relates to 7

Attachments

2013-01-27_17.17.01.png 2013-01-28_15.19.37.png 2013-02-18_18.31.49.png 2013-03-03_16.10.04.png 2013-03-03_16.16.17.png 2013-03-03_16.17.47.png 2013-03-06_14.50.13.png 2013-03-07_15.56.58 - Lines Thru Blocks Tranceparencey - Zoomed.png 2013-03-07_15.56.58 - Lines Thru Blocks Transpencey.png 2013-03-15_17.07.57.png 2013-03-15_17.13.41.png 2013-04-12_13.00.35.png 2014-02-20_14.07.16.png 2014-05-01_17.01.17(2).png 2014-07-27_18.51.47.png 2014-09-06_18.39.00.png 2016-04-27_09.33.59.png 2016-12-31_09.48.28.png 2016-12-31_09.48.37.png 2016-12-31_09.48.42.png 2017-03-07_12.41.09.png 2018-08-08_16.26.51.png dark cave.jpg MC1_14Bug.jpg
MC-1794 RGB and Black Lines - 7.97mb.mp4
 newsnap.png newsnap2.png
RST (2).zip

Comments 469

This is strictly a graphics card/driver issue. Try changing your graphics settings to correct this. This can also be influenced by optifine, should you have it installed

Ville Selkämaa

I have this problem too.I have tried changing my GPU settings but no luck so far...I am using Amd HD6850

Sergio Carlos Roman Lopez Jr

Does anyone know how to fix this problem. I tried changing graphics settings and not happened its still the same.

I used to have this issue, and to fix it, I reset several of my graphics settings to defaults, or "use application settings" options. I've found that anti-aliasing and anisotropic filtering have had influence on this.

MisterSanderson

I saw this problem in my game today.

459 more comments

Can confirm in 23w05a

Can confirm in 23w06a

I have just experienced this issue between two blocks in 1.20 Pre-Release 6. I rarely experience this personally but I changed monitors and now I see it. I play with mipmaps off.

Affects 1.20.

When opening beta 1.7.3 my game would have this weird purple boarder for every single block(including liquid blocks like water, or lava) from a 7 block gap from my player. When first downloading I made sure to put it to have 3 GBs of ram allocated to Minecraft for that version. Once I was annoyed enough I switched it to 2gb, this has as of 5/14/2024 at 11:30PM EST fixed this problem. I experimented by putting it to 4gbs, and the problem wasn't present, I then switched it back to 3gbs, and the problem has just vanished.

 

my pc specs:

I5-11400F

RTX 2060(6gb, 2 fan, GIGABYTE model)

8gbx2 RAM

with a B560M-A motherboard

 

I know that its a super old version, and you have probably alrighty known that this version had this bug, but I just wish to write it down as a possible fix to anyone experiencing this on that version. This could be a possible fix for other versions too so please give it a try.

minecrafter

jonathan2520

(Unassigned)

Confirmed

Platform

Low

Rendering

Minecraft 1.4.1, Minecraft 1.4.2, Minecraft 1.4.3, Minecraft 1.4.5, Minecraft 1.4.6, ..., 24w04a, 24w10a, 1.21, 24w40a, 1.21.3

Retrieved