The world renderer drew nothing; make it draw the world - #128
Merged
Conversation
#119 shipped a world renderer that produced no output at all on a real world, and every test was green because none of them read a real chunk. **The palette was unwrapped once and needed twice.** prismarine-nbt represents an NBT list as `{type:'list', value:{type:'compound', value:[...]}}` — the outer wrapper says "list", the inner says what the elements are. `sections` happened to work because that code unwrapped twice; `palette` did not, so `Array.isArray(palette)` was false for every section of every chunk, every section was skipped, and every tile came back null. Silently: no error, no exception, just a map with nothing on it. Verified against a real Paper 1.21.6 world rather than argued about — 339 chunks of one region decoded, rendered to an image and looked at. The bit-level work from #119 turned out to be right: DataVersion 4435, padded packing, and the long counts match `bitsPerIndex` exactly (a 26-entry palette is 5 bits and 342 longs, which is what the file holds). **And then it looked wrong, so this fixes that too.** The topmost block of a column is usually the plant standing on the ground rather than the ground: on that world the commonest surface blocks after grass were `short_grass`, `vine`, `fern` and `bamboo`, none of them in the colour table, all falling through to the stable-hash fallback. A bamboo jungle rendered as a maroon smear and every meadow as blue-grey. A map looks *through* foliage. `seeThrough` skips grass, ferns, vines, flowers, bamboo, crops, carpets, signs and the rest — by name and by suffix family, so a flower added in a future version needs no release — while leaves stay, because a forest canopy is exactly what you see from above. After it, every drawn surface block is one the table names. The common colours are Minecraft's own map-item palette now instead of eyeballed values, since that is the palette a player recognises. Mine were darker and redder, which is the other half of why podzol read as maroon. Asserted with a real NBT chunk built in the test and read by the real function: air above and stone below renders as stone at the right height, grass with `short_grass` on it renders as *grass*, and an all-air chunk produces no tile. Proved failable — restoring the single unwrap gives `FAIL - a valid chunk produced no tile — the reader found no sections`, which is precisely what was shipping.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The world renderer drew nothing; make it draw the world
#119 shipped a world renderer that produced no output at all on a real world,
and every test was green because none of them read a real chunk.
The palette was unwrapped once and needed twice. prismarine-nbt represents
an NBT list as
{type:'list', value:{type:'compound', value:[...]}}— the outerwrapper says "list", the inner says what the elements are.
sectionshappenedto work because that code unwrapped twice;
palettedid not, soArray.isArray(palette)was false for every section of every chunk, everysection was skipped, and every tile came back null. Silently: no error, no
exception, just a map with nothing on it.
Verified against a real Paper 1.21.6 world rather than argued about — 339 chunks
of one region decoded, rendered to an image and looked at. The bit-level work
from #119 turned out to be right: DataVersion 4435, padded packing, and the
long counts match
bitsPerIndexexactly (a 26-entry palette is 5 bits and 342longs, which is what the file holds).
And then it looked wrong, so this fixes that too. The topmost block of a
column is usually the plant standing on the ground rather than the ground: on
that world the commonest surface blocks after grass were
short_grass,vine,fernandbamboo, none of them in the colour table, all falling through tothe stable-hash fallback. A bamboo jungle rendered as a maroon smear and every
meadow as blue-grey.
A map looks through foliage.
seeThroughskips grass, ferns, vines, flowers,bamboo, crops, carpets, signs and the rest — by name and by suffix family, so a
flower added in a future version needs no release — while leaves stay, because a
forest canopy is exactly what you see from above. After it, every drawn surface
block is one the table names.
The common colours are Minecraft's own map-item palette now instead of eyeballed
values, since that is the palette a player recognises. Mine were darker and
redder, which is the other half of why podzol read as maroon.
Asserted with a real NBT chunk built in the test and read by the real function:
air above and stone below renders as stone at the right height, grass with
short_grasson it renders as grass, and an all-air chunk produces no tile.Proved failable — restoring the single unwrap gives
FAIL - a valid chunk produced no tile — the reader found no sections, which isprecisely what was shipping.