Cloud corners not connected

I haven't checked the latest snapshot to see if it is still affected, but I'm sure it is. It doesn't say it's fixed in it.

Confirmed for 1.5.1

Confirmed for 14w04b

EDIT: Was able to reproduce in 14w06b

Confirmed for 1.7.5, 1.7.9 and 14w17/8a

Cannot Reproduce in 1.8, assuming it's Fixed.

Regressed in 1.8.1-pre4 (MC-74146).

Cannot Reproduce in 1.8.1-pre4

In addition to the corners being slightly offset, the planes tend to have frayed edges, sometimes projecting well outside the actual cloud. No change that I know of; I'm just documenting how it's been for me for a long time.

I just noticed my profile was still using Java 8u20. I verified that 7u72 and 8u25 exhibit the same issue. This is on OS X 10.9.5, with some further details in the screenshots (F3).

I see a slight overlap on some clouds, like the comment before this one stated, but only the top part overlaps the sides and I don't see unconnected corners. Can someone confirm that part for 1.10.2?

I had another look at it in 1.10.2. It looks like all the quads are translated toward the corner of the box with the smallest XYZ coordinates. So a single cloud has its own quads intersecting each other. All adjacent coplanar quads line up, however. Note that the eastern quad of one box is positioned slightly too far west so there are two distinct quads between two connected boxes. This goes for the other dimensions, too. If you get in that space in just the right way you can make the back face of a cloud disappear. There's some cracking because the mesh is full of T-intersections. The frayed edges are also still there if you get close. It's quite visible from a distance, probably because of the cracking or perhaps the depth buffer.

All quads are always drawn, even inside clouds and in clear sky. It results in this kind of intersection:

/\        two faces facing the camera,
camera ----- /  \ <---- overlapping from its perspective
            /    \      and meeting at a vertex/edge

That causes problems with the depth buffer, when fragments from different faces are quantized to the same depth value (which can easily happen because fragments can get arbitrarily close to the vertices and edges where the faces connect). It's just like the speckles on a snow layer grid. I think the draw order may have been tweaked at some point to disambiguate in favor of the face that happens to be correct most of the time. Nevertheless, because the mesh is full of cracks, you can still see funny lines between cloud boxes from a distance, even from the bottom where where things would line up given infinite precision.

The frayed edges depend on where exactly you are in the cloud grid. Even repetitions of the same bit of cloud texture are different. Every repetition (12 blocks per texel * 256 texels = 3072 blocks) in the positive direction gets progressively worse, until it instantly improves again every 8th repetition (24576 blocks). In fact, as you cross the z≡-3.96 (mod 24576) plane, there's a very jarring transition between the best and the worst. x is less predictable because the clouds are constantly moving on that axis.

Anyway, theoretical precision of 32-bit floating point drops down to about 683 units per block. You might expect problems if you got close, but not problems that are that bad. What really pushes it into crazy territory is the effect of perspective. The closer I get to the plane while looking at the horizon, the worse it gets. This applies even to parts that are far away horizontally and so don't get much closer at all as I move vertically. This is exactly the kind of thing that's really hard on rasterizers, when a polygon's depth ranges from very close to very far, all on screen. The line extends across multiple polygons including easier ones, however. I think my GPU sets up interpolation so that it works across the screen without considering the area covered by the polygon. That makes sense given NVIDIA's heritage of clipless rasterizers. Not sure what they do nowadays but vertices do snap to a 256th of a pixel as apparently mandated by D3D10. Not something you'd normally expect a clipless rasterizer to do.

Just for completeness, the flat "fast" clouds act similarly but to a much lesser extent. The texels are a bit smaller at 8 blocks which already helps. In addition, the texture coordinates are reset for every repetition. That makes it 12 times as good. Not great, but it's okay for what it is. "Fancy" clouds could easily have comparable precision without overhauling them in any way.

I got curious enough to check the decompiled source of MCP. The top and bottom faces are drawn in bunches of 8x8 texels per quad. Each of the other four kinds of face is then drawn as 8 8-wide strips in the sandwich. It's no surprise there are cracks, huh? Looking back on when I checked the polygon depth thing, what appeared to be multiple polygons is really one. Indeed, when I find the actual edge of the polygon, the screwy line doesn't extend to the next one. So the GPU really does take the covered area into account. Another thing cleared up.

Edit: To reply more directly, this looks very much like the original report and screenshots. Only the March 2013 screenshot is clearly different. Not that I care about a word-for-word match, but there is one.

Relates to / is a duplicate of MC-1794

Relates, not a duplicate by far, this issue is on way more easily noticable then MC-1794 is.

I tried it on the Intel Iris Pro 5200 in my laptop. Of course it doesn't fix the garbage in, garbage out of bad geometry. What it does fix relative to the GeForce 750M is the frayed edges. Interesting that NVIDIA is worse in this regard. It's generally best for Minecraft, at least in part because it's all Mojang seems to be using. I booted in Windows to verify the GeForce behaves the same there, which it does. Then again, it only shows when you get close to the plane of a cloud. It isn't unconditionally super-obvious. That might be why Mojang let it slip.

------ <Sky
____ <Ground
Above sky, you can't line clouds. Also overlapping through glass

Still an issue in 18w16a, the cloud corners still aren't connected, I added a screenshot showing it.

Still an Issue in 18w20a

Affects 18w22a

Even though there is a little bit of overlap where two sides of a cloud connect, it looks nothing like the issue described in this ticket.

Closing as Cannot Reproduce on 1.15 .1 pre-release 1.