Sector streaming

[Zylann]

Summary

Sometime after 3.1 is released (but didnt get time to do it so far), I would like to approach this by using sectors, which would unlock the ability to:

• Stream the terrain
• Create much larger worlds
• Create terrains that are not necessarily square.

It may be a big refactoring of the plugin, however I believe it should be relatively simple to adress.

Limitations of the existing system

Currently, the terrain is made of a several big square textures covering it all (heightmap, normals, splatmap, grass etc). This is fine for small games, arenas, islands or level-based games. This however doesn't scale well for games that need an even bigger area, want to eliminate loading screens, or even generate their own map. Think about RPGs, MMOs, exploration or survival games.

Note that it is already possible to do this if you generate your terrain on the fly procedurally. This issue targets authored terrains that you can import or modify in the editor.

How sectors would work

The idea is well known: to take the current terrain, split it into many smaller sectors of a fixed size, and load them on demand in the background, using asynchronous loading of textures*. Each sector would be about 513x513 and have the same features as the current system, there would be just many of them instead, stitched together internally (note that they still need an off-by-one resolution to keep LOD working, and will share max edge pixels to prevent seams between sectors).
Each sector would also have its own LOD quad tree, which means if the loaded area is made of 5x5 sectors, there won't be less than 25 meshes to render minimum (unless the technique changes, with tessellation for example).
And of course, it means the data will be saved differently, most probably the same as it is now but divided in folders for each sector.

Edit: sectors would actually use a different size system, see #12

Impact in the editor

This streaming system would likely run in the editor as well, so it's expected to not be able to see the entire world at once. You will have to move first next to the place to edit, in order for it to be loaded. That also means some edge cases will appear, like undoing a chunk of work done in a now-unloaded sector. I think it's not to bad to consider loading/modify/save/unload in the worst case, it may me slow to run but it shouldn't be a blocker. Also, streaming will litterally mean the terrain will constantly save itself to disk as you move around, and saving a scene will simply force that process to complete for all loaded sectors as well. To preserve the expectation of "Save = persist in the project", modified sectors could be stored to a temporary folder until saved.

Forward-compatibility

This system would also be forward-compatible, functionality-wise, because it is able to represent the current features by considering that there is only a single big sector, with streaming turned off. It mostly generalizes the current system. That also means if you don't need streaming at all, you can still opt out.

*About asynchronous loading of textures:
Currently Godot's GLES2 and GLES3 backends don't really support to load big textures truly asynchronously without causing stalls. The plan would be to use a thread to load images, and then upload them at a slow pace with partial texture updates. Textures have to fully be allocated first, but we can use pooling once enough are in memory, so unused ones from unloaded sectors will receive data of the next.
However, Godot 4.0 is advertised to come with Vulkan support: that means the range of techniques used by the plugin might be upgraded to more modern ones, so we'll see what will be doable then.

[NewNodeGames]

Wow this can be really nice. In this project the terrain is procedurally generated and is infinite https://github.com/TassuP/Niceland

[Cyrus-Harding]

I really hope this is possible.

I have thought about having multiple heightmaps and just loading them in when close to the edge of one. But then I'd have to match the edges of the heightmaps.

[Buri]

Hi, is there a point implementing chunk loading now, since work on 4.0 already started or is it better to wait and see what new version brings in?

[Zylann]

4.0 is not that much of a big waiting factor in this, it's mostly depending on my time and design considerations, because it's quite a big task. I'm still thinking about some of it, it might not be done exactly like I originally wrote in the first post though.

Also just added reference to #12 because it has relevant info about the chosen sector sizes

[MJacred]

While manual terrain stitching sounds really nice, I'd prefer this feature first.

If you could look over the design and update it, then I'd try implementing this. Would also love some pointers and if I could ask you questions, in case I run into difficulties.

[RonanZe]

Hello Zylann, do you still plan to work on sector streaming at some point?
I'm thinking to take a look at the code of the plugin to understand how it should be implemented. And maybe try some hack to prototype a solution... But it's seem to be a bing refactoring that change a lots of thing everywhere.

[Zylann]

It would be one thing to do in a 2.0 version but I have no ETA at the moment.