Add a new rendering approach for far distance chunks to support very far rendering distances

[begla]

@KaiKratz and I discussed a new and very stylized rendering approach for supporting very, very far rendering and viewing distances.

Summary

• We'll create a new chunk tessellator based on the Marching Cubes algorithm for chunks in the distance
• Those chunks will be created using a grid which size we'll increase according to viewing distance
• The rendering of the vertices will be based on a baked vertex color which can be defined for each cube
• The shader for those chunks will be very simplistic and will only use vertex colors for rendering
• The meshes of those far distance chunks will be written to the HD and directly uploaded to the GPU if needed
• The meshes of the chunks will only be updated if anything changes within the chunk

Open questions

• Lighting?

This approach should reduce the overall vertex count and the overall memory usage drastically while using much larger viewing distances.

[Cervator]

Win! I can almost hear @KaiKratz grumbling about having to suffer with visible chunk loading ;-)

[emanuele3d]

Might be worth considering the proposal in issue #126 in relation to this.

[OvermindDL1]

You do not necessarily need to render the distance every frame either. If the video card has enough memory then create a cubemap of the screensize to the nearest power of two up, then draw the far chunks on it, that way you just need to render the RTT'd cubemap texture every frame, only updating it in parts as the far away areas change and/or the viewpoint moves a sufficient distance to warrant a redraw. If you draw blocks far enough away then you only need to draw them as a colored pixel instead of a cube (perhaps even scaling them down a bit to be a pixel so it looks even further than it is, giving a great sense of size), makes for very fast updating and looks decent.

[flo]

For those who want to do this ticket:

Be aware that distance rendering is more than just rendering. The world needs be generated/loaded first. Having everything in memory might not be possible. The world gets loaded chunk wise. Each chunk is 32x32x64 blocks large. The game loads and unloads chunks as the player moves through the world. Unloaded chunks remain in memory till they got saved to disk via a automatically occurring autosave.

Objects (called entities in terasology) in a chunk get currently loaded and saved together with the chunks. The entities do not just get loaded with the chunk but get also activated with the chunk. It is questionable if we need for example a deer to walk around in a chunk that got just loaded to render a chunk that is far far away. Changing the timing of how objects/entities get loaded/unloaded will propably not something done quickly. An alternative could be to generate an optimized render only structure for chunk that get loaded and save it for quick reuse once the chunk the player is on is far away. This isn't easy either since it also means that a new way to load/save this light weight chunk versions of the chunk is needed.

A chunk goes through multiple steps till it is fully loaded and gets rendered. For example before a chunk gets loaded, the game first calculates how light gets to it from the bordering chunks. In addition to that the game renders a chunk only once all adjacent chunks are also ready for rending in order to get border blocks correctly done. This means that currently 5x5x5 chunks need to be loaded before the first chunk can be rendered. See #1886 for more details about that issue. Even if you don't have a nice idea for fixing it, having a look at the code
might get you started in the area of chunk loading.

Another aspect to keep in mind is multiplayer. Transfering also chunks in great distances to all clients might be to much for the server. One possible solution could be to offer a "Render skybox/sphere for this chunk" option. The option could allow a player to render a skybox with the surroundings of a chunk in very very far distances. The rendering could be performed with the normal renderer. The final rendering could then be stored on the server and sent to other clients when the client enters the chunk. Sending other optimized far distance simplifications to clients might also be an option.

[OvermindDL1]

Could just be simple and only cache the data locally only when once
downloaded normally from the server (perhaps just a simple 3d array of
integer colors to render the 'far' blocks with or something, could even do
2d if it is truly far), so they will not see the far distance until
visited, but after that they will see it fine, the server could even send
such 'cached color data' on occasion too.

On Fri, Mar 4, 2016 at 4:26 PM, flo [email protected] wrote:

For those who want to do this ticket:

Be aware that distance rendering is more than just rendering. The world
needs be generated/loaded first. Having everything in memory might not be
possible. The world gets loaded chunk wise. Each chunk is 32x32x64 blocks
large. The game loads and unloads chunks as the player moves through the
world. Unloaded chunks remain in memory till they got saved to disk via a
automatically occurring autosave.

Objects (called entities in terasology) in a chunk get currently loaded
and saved together with the chunks. The entities do not just get loaded
with the chunk but get also activated with the chunk. It is questionable if
we need for example a deer to walk around in a chunk that got just loaded
to render a chunk that is far far away. Changing the timing of how
objects/entities get loaded/unloaded will propably not something done
quickly. An alternative could be to generate an optimized render only
structure for chunk that get loaded and save it for quick reuse once the
chunk the player is on is far away. This isn't easy either since it also
means that a new way to load/save this light weight chunk versions of the
chunk is needed.

A chunk goes through multiple steps till it is fully loaded and gets
rendered. For example before a chunk gets loaded, the game first calculates
how light gets to it from the bordering chunks. In addition to that the
game renders a chunk only once all adjacent chunks are also ready for
rending in order to get border blocks correctly done. This means that
currently 5x5x5 chunks need to be loaded before the first chunk can be
rendered. See #1886
#1886 for more details
about that issue. Even if you don't have a nice idea for fixing it, having
a look at the code
might get you started in the area of chunk loading.

Another aspect to keep in mind is multiplayer. Transfering also chunks in
great distances to all clients might be to much for the server. One
possible solution could be to offer a "Render skybox/sphere for this chunk"
option. The option could allow a player to render a skybox with the
surroundings of a chunk in very very far distances. The rendering could be
performed with the normal renderer. The final rendering could then be
stored on the server and sent to other clients when the client enters the
chunk. Sending other optimized far distance simplifications to clients
might also be an option.

—
Reply to this email directly or view it on GitHub
#319 (comment)
.