Zylann/godot_heightmap_module

Terrain streaming

Opened this issue · 0 comments

Streaming terrains is very nice to have, considering that terrains take up a LOT more memory than tilemap or gridmap-based terrains. Supporting this allows to design large open-worlds, or even "infinitely" generated worlds. We should be able to choose any view distance, and any precision under player's feet.
Ideally it should allow the terrain system to scale gracefully for both small or huge worlds.
Geometry LOD is working good already, the bottleneck is the data itself (textures).

For external resources, see #15

Current state

  • Fully-loaded big texture(s) covering the whole terrain, used to displace vertices and perform shading
  • Geometry LOD using a quadtree-based implementation of clipmaps, tree depth is fully dynamic
  • Having fully-loaded data causes big CPU+GPU stall, consumes a lot of memory
  • Has borders, so the game area is relatively "small" if you want to hide that, unless you do a "crater" arena or islands
  • Physics may use btHeightField at lower res, covering all terrain, or as multiple patches around the player
  • Only uses features exposable by Godot VisualServer (which is itself built on top of GLES3), so fancy stuff like glDrawIndirect or tessellation are not an option (yet?)

Proposal P1: GoogleMap-ish

  • Many textures of 512x512 at multiple LOD levels covering parts of the full terrain, loaded as needed
  • Same geometry LOD, except chunks above a certain size will likely use different textures (which means multiple materials with same shader) and will wait for textures to load before merge/split.
  • Can be loaded progressively without stalls due to small size of textures. Chunks too far away from the far clip will be considered not loaded, so only a part of the quad tree will be in sight.

Proposal P2: Render buffer

  • Similar to P1, except 512x512 textures would be used to render the top-down heightmap to an offscreen buffer, which is in turn used as a texture when rendering the terrain, and re-rendered as the viewer moves.
  • Same geometry LOD, may still use multiple textures if we want to see very far away (atlased renderbuffer at 4 LOD levels? beware of the seams)
  • May use less materials than P1
  • Purely theoretical, I don't know how good this idea would be, I'm not a GPU expert :p