Fix dark chunks - addresses #2029 and #1899, prepares for fix of #2002, #2024, and #2035

[ralokt]

The Problem

It is possible for chunks to have no sky light data whatsoever.

This can happen for a number of reasons (see also: #2029, #1899), but in particular, all worlds that have been optimized with --forceUpgrade in 1.19 will be completely dark until chunks are loaded ingame.

Also, Minecraft sometimes saves chunks with incomplete light data. These chunks only contain "spillover" light from neighboring chunks, but the sky light from the chunk itself is not taken into account. It is common for these chunks to appear on "version borders", and they are almost completely dark. Screenshots of an example at two different zoom levels:

Overview of contents

This PR addresses this issue in two steps:

• d521770 checks all chunks for a section with sky light data. If no such section exists, the chunk will be fully brightened.
• 57727ae additionally checks chunks that do have sky light for a block with full sky light. If no such block exists, it will assume that the chunk is mostly dark and fully brighten it (detailed explanation below).

Also, in order to cleanly implement this change, I did a bit of refactoring.

Detailed reasoning for the decision to check chunks for a block with full skylight

Two observations:

• A chunk without "own" skylight that only has skylight data from neighboring chunks "pour in" will never have skylight 15 anywhere.
• Most chunks with skylight will have full skylight at the top.

These observations together mean that:

• The heuristic we chose is very good - there are edge cases like a leaf roof at the build limit that would break, but I'd argue that these edge cases are less important than the ugly borders pictured above
• It is also very fast if we go from top to bottom.

In practice, on my test world of slightly over 5000 tiles, a pure python PoC implementation of this heuristic bumped the runtime from 8:35 to 8:50, and the numpy implementation somehow managed to finish rendering faster, in 8:06. While that is based on only one run per implementation, I think it's safe to say that this change does not significantly affect performance.

And in any case, if it is deemed preferable not to do that, we can just yeet the second commit.

Reverse dependency to rendering 1.18+ chunks properly again

This issue came up in #2051, my first attempt at fixing the rendering of pre-1.18 worlds that were loaded in Minecraft 1.18 or higher. Since these chunks turn out completely dark if they were optimized but not loaded in 1.19 (see above), it makes sense to first fix this lighting issue before making these chunks render.

@cliffmeyers and I agreed to split the change into two PRs to avoid scope creep, so I'd like to get this merged first.

[cbs228]

I have tested this on a large 1.19.3 world that has been around since before 1.16. An overviewer.py --forcerender completed without issues and fixed #1899 for me. As expected, chunks without lighting info render at full brightness. This is vastly preferable to full darkness.

I did a brief code review and didn't find anything major, but someone with more experience with this codebase than me should probably look at it.

It is my understanding that Minecraft-Overviewer is no longer maintained, so it is unlikely that this PR will be merged. I recommend that any future maintainers and/or forks should merge this.

[cliffmeyers]

@cbs228 thanks for sharing this. I'm going to pull this branch and test it against my ~8 GB world when I get a chance. I would love to get a decent full render of my 1.19 world before bumping to 1.20.