[1.14] How Minecraft renders blocks

[DavidM]

I am wondering how Minecraft renders its blocks.

Does the renderer iterate through every block in loaded chunks/camera view and determine whether each side should be rendered?

Does Minecraft have occlusion culling?

[DavidM]

Thanks.

However, why does every block change cause a render calculation to the whole render chunk? Shouldn't only blocks that are adjacent to the changed block be re-calculated?

[DavidM]

On 7/29/2019 at 1:52 PM, diesieben07 said:

these are 16x16x16 blocks (as opposed to the regular chunks)

How is the render chunks divided?

Are they aligned with the regular chunks on the x and z axis.

For example, if I have a block at x: 10, y: 20, z: 30, how does the game determine what render chunk it is in?

[Draco18s]

4 hours ago, diesieben07 said:

As far as I know they line up with the normal chunks on x and z and then that chunk gets divided into sections of 16 high blocks.

This is correct. I had a mod that adjusted biome temperature/rainfall over time (for seasonal variation) and there would be grass/leaf color discontinuities right along standard chunk boundaries where one side hadn't been re-rendered recently.

[Bero256]

I have an alternative suggestion for occlusion in Minecraft. Using some sort of beefed up ray casting just to check if a ray collides with a block. If I am not mistaken this should dramatically reduce overdraw and rendered polygons. I mean, when you're in a cave the visible polygon count is probably like in a PS1/N64 era 3D game. I always wondered why would a GPU that can render 10 million polygons a second struggle in Minecraft even on Tiny render distance. 
You also shouldn't need much precision due to the block nature of Minecraft, so there should be some computational savings as well. 

[Draco18s]

(1) this thread is fucking old

(2) "raycasting" is more expensive than overdraw