False negatives during occlusion culling

Confirmed.
Some findings:

• Indenependent of the render chunk width

• when moving a few pixel to the right, the bottom of the chasm renders

This issue is still present in 1.9.4

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

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.

Can confirm for 1.11

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.

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.

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.

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

Affects 20w18a

Affects 20w19a

Affects 20w20a

Affects 20w21a

Affects 20w22a

Affects 1.16 Pre-1

Affects 1.16 pre release 2

Affects 1.16 Pre-3

Affects 1.16

Hi there!

This affects 20w27a.

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.

All version of Minecraft have it!

Affects 1.16.2

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

EDIT: FOV: 90

Affects 20w45a

My problem fixed after relogging

Affects 20w46a

Affects 20w49a

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?

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

Can confirm in 21w03a.

Can confirm in 21w05b.

Can confirm in 21w06a.

Can confirm in 21w07a.

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.