[MC-70850] False negatives during occlusion culling

The bug

The occlusion culling occasionally fails to identify chunks which should be visible.

How to reproduce

Test world

Download and open this world:

[media]

Natural generation

Create a normal 1.8 world with the seed -8057776351348801925
/tp -271 97 -1358
→ There will be a missing chunk in the chasm.

[media]

.
/tp -273 93 -1360
→ There will be a missing chunk directly beneath and slightly to the side of the player.

[media]

More examples:

Seed: -3040140397380042098
Coordinates:

/execute in minecraft:overworld run tp @s 83.90 79.00 69.69 -67.35 30.15

/execute in minecraft:overworld run tp @s 79.81 14.00 41.47 -859.83 7.65

Code analysis

See this comment.

Linked issues

relates to 1

MC-220541 Frustum culling doesn't take nausea's distortion effect into consideration, causing visible chunks on the edges of the screen to not be rendered Open

Attachments

MC-109862.zip

SectionCulling.zip

Comments 33

kumasasa 2014-09-04T10:17:50Z

Confirmed.
Some findings:

Indenependent of the render chunk width
when moving a few pixel to the right, the bottom of the chasm renders

Nathan Gilbert 2016-06-25T00:41:16Z

This issue is still present in 1.9.4

Panda4994 2016-11-08T21:27:23Z

With the information provided in MC-109862 I was able to track down the issue a little bit.
I attached a world download to reproduce this issue.
It does only appear if the one wall of a section is fully filled with blocks (iron blocks in the world download) and the wall of the next section has at least one gap in it (lapis blocks in the world download).

[media]

Also it should be noted that the facing of the player has an impact on it. E.g. in the seed and position provided in MC-109862 it only occurs if the vertical facing is less than -34.3.

I can confirm this issue for 16w44a and 1.11-pre1.

bob 2016-11-19T16:46:07Z

Can confirm for 1.11

Michael Kreitzer 2019-10-17T05:21:24Z

I found a cause and a fix for Panda's test world. However, it doesn't seem to cover all cases.

While walking the visibility graph it won't add a neighbor subchunk if there's no visibility path from the direction the algorithm entered the subchunk to the direction of the neighboring subchunk. When it got to the chunk with the iron blocks from the subchunk below the player (which is the 2nd subchunk processed) while there was no lapis block, it would end there. There's no path to any neighbor due to the solid wall of iron blocks at the direction the path "entered".

The only other paths to the disappearing subchunks are the subchunks to the right and left of the player. The problem is, the algorithm was setup in such a way that once a path moves in a certain direction, it could never go back in the opposite direction, ever. So, take e.g. the left. From the player it would go left (now it can never go right again), down (now it can never go up again), forward (now it can never go back again), forward, and forward. So, in this entire scene with all subchunks above the bottom two out of the Frustum, there's no valid path to those two subchunks that disappear.

When you placed a block to fill the lapis wall, it blocks the down, forward path. Now, the path is straightforward; forward, down, forward, foward, forward, and it spreads from there.
If you clear the inherited direction restriction, it clears up this test case nicely, and in some brief real world testing it seemed to cause no significant increase in subchunks rendered or any appreciable drops in FPS. I'm attaching a screenshot from MCP 9.42 (I know.. old.. sorry I do not have anything newer setup). I renamed a lot of the variables to help make things clearer.

Now, as for the test case that still fails:

-1288030513686422296
/tp -254 81 480

(edit: this seed came from a 1.12.2 test world.. if somebody with a more current dev environment can confirm any of this it'd be much appreciated)

I'm going to try to find a synthetic/controlled case for this one. I suspect that "bidirectional" path requirement is related, and possibly unnecessary. I'll play with the idea of neighbors only caring if they can see each other.

[media]

23 more comments

Michael Kreitzer 2019-10-17T22:13:59Z

In the second test case the problem is caused because the chunk above and to the south of the one that disappears are the only neighbor chunks that can "see" it. With the visibility check checking the path from the source face to the destination face, then:

If the southern chunk is the one doing the neighbor scanning then it'll only add the target chunk if the south chunk itself was traversed from above.
If the upper chunk is the one doing the neighbor scanning then it'll only add the target chunk if the upper chunk itself was traversed from the south.

All other possible paths will fail the visibility check.

Removing the sticky reverse path and replacing the source to target visibility check essentially means you end up with every chunk in the frustum that is in some way connected to the camera chunk being rendered. This does mean any cave with an entrance in the view frustum will be rendered and the scanner ends up scanning a lot more neighbors in some situations. However, the typical situation of looking out to the horizon doesn't really change and is always the most expensive.

All in all, this algorithm just doesn't work. It's results were always haphazard and it's lucky it hasn't caused any more problems than it has. It's trying to do visibility checking without taking the camera into account. At best you exclude a few caves that have no entrances or paths to anything in the frustum or a few chunks behind a mountain that occupies the entire width of the frustum.. maybe.

I hope this is intended to be replaced by Blaze3D.

Michael Kreitzer 2019-10-18T02:02:29Z

Last comment.. hopefully. 🙂 Keeping the "sticky reverse path" works if you only check if any path exists to the target face. That helps bring the checks down a bit. The performance hit isn't nearly as bad as I feared.

violine1101 2020-04-28T15:08:02Z

Transferred all information from MC-63021 (which now has been resolved as a duplicate of this ticket) here.

Nightwind8887 2020-04-29T17:36:50Z

Affects 20w18a

Nightwind8887 2020-05-06T17:16:30Z

Affects 20w19a

Nightwind8887 2020-05-13T17:53:37Z

Affects 20w20a

Nightwind8887 2020-05-20T17:29:15Z

Affects 20w21a

Nightwind8887 2020-05-29T19:36:30Z

Affects 20w22a

Nightwind8887 2020-06-04T21:00:50Z

Affects 1.16 Pre-1

Iosiv Visokogorskiy 2020-06-08T16:55:31Z

Affects 1.16 pre release 2

Nightwind8887 2020-06-10T18:51:23Z

Affects 1.16 Pre-3

Tristan 2020-06-26T22:19:49Z

Affects 1.16

[Mod] markderickson 2020-07-02T16:09:46Z

Hi there!

This affects 20w27a.

Tencryn 2020-07-08T21:58:31Z

Hopefully that can be fixed. I have an area in my world that is plagued by this. So many chunks don't render in certain angles. I'm using an Optifine preview for 1.16 in this image, but I can confirm that it occurs in vanilla too. It's actually weird because it isn't quite the entire chunk... you can see there is part of the wall still visible despite being in the same chunk, but that it appears as a 2D texture.

[media]

What is my name? 2020-08-01T09:25:24Z

All version of Minecraft have it!

Nightwind8887 2020-08-11T22:24:47Z

Affects 1.16.2

Markus 2020-11-03T12:05:03Z

Affects 1.16.4. The best way it can be noticed it while running in caves.

[media]

EDIT: FOV: 90

Nightwind8887 2020-11-04T21:51:29Z

Affects 20w45a

Mateus Pereira Milbradt 2020-11-06T12:34:39Z

My problem fixed after relogging

Nightwind8887 2020-11-11T19:19:30Z

Affects 20w46a

Nightwind8887 2020-12-02T18:52:37Z

Affects 20w49a

mxblue28 2020-12-20T15:23:14Z

I had one specific place in my world where this happened consistently, and it seems to no longer occur as of 20w51a. Can anyone still confirm it for this snapshot?

Avoma 2020-12-20T17:12:38Z

Can confirm that this is still an issue in 20w51a. I've attached a screenshot with the F3 Debug Screen enabled.

Avoma 2021-01-22T19:58:45Z

Can confirm in 21w03a.

Avoma 2021-02-06T15:08:04Z

Can confirm in 21w05b.

Avoma 2021-02-12T14:30:53Z

Can confirm in 21w06a.

Avoma 2021-02-18T13:08:54Z

Can confirm in 21w07a.

Avoma 2022-09-05T11:57:00Z

This issue seems to have reappeared in 1.19.2 or may have never been properly fixed, so I've created a new ticket regarding this which can be found at MC-255750.