Fix rendering bug for mesh index exceeding uint16 range (which is fairly common)

[KokeCacao]

Related Issues:

• Render partially fails on large amount of blocks #14
• Missing Rendering of Non-full Blocks vscode-nbt#78

Purpose: Mainly, this PR ensures all renderings are correct regardless of what chunkSize is used for rendering.

How it's done:

• When a mesh is too large to render in one batch, it will break into multiple meshes.
• Implement dirty bits for all buffers so that there is minimum rebuild overhead.
• Also moved all rebuild to right before render, as with dirty bits, there is no overhead.

The rendered image is now correct even with chunkSize=16.

Side note: this commit assumes #55

[jacobsjo]

What is the benefit of this over just decreasing the chunkSize? The customizable chunkSize exists specifically to solve this problem.

Also, have you configured culling properly? With culling enabled, it seems unlikely that you would run into the uint16 limit with chunkSize=16

[KokeCacao]

What is the benefit of this over just decreasing the chunkSize? The customizable chunkSize exists specifically to solve this problem.

Also, have you configured culling properly? With culling enabled, it seems unlikely that you would run into the uint16 limit with chunkSize=16

Decreasing chunkSize to 1 is probably very safe but makes rendering take more time due to multiple rendering passes. I don't want to manually inspect whether my rendering is correct and adjust chunkSize to trade off rendering speed and accuracy.

I do have culling enabled (you can see evidence in image #14 (comment)). It is true that with a normal player-built schematic, it will most likely render correctly. But somehow there will be strange people like me who for some reason, must render a 16^3 region with random blocks, which uses more than 2 times of the available uint16 range with chunkSize = 16 (even with culling). Another example would be something like rendering of 16^3 Scaffolding, since they have 28 faces, giving 114688 total number of quads and therefore 688128 vertices. But we only have 9.5% (65536) vertices avaliable.

[KokeCacao]

I will maintain this feature on my own repo for offline rendering.