[TRACKER] Making terrains

[Zylann]

I found a number of issues about making terrains in Godot, be it heightmap, voxels, an engine module or a plugin, so I thought I would make a tracker to list them all:

Engine limitations:
(some might be "closed as fixed" but are still actually open in a different issue, or have been closed in favor of another issue that doesnt exactly match the problem; need to take the time to update this list)

• Need a way to set a custom AABB per visual instance #9544 : need to be able to set custom bounding box per mesh instances, to unlock the ability to do shader-displaced heightmaps and reuse mesh configurations ; the lack of this feature produces culling glitches

• Need to be able to upate a texture partially #9571 : need to be able to update a texture partially. Editing huge textures on the CPU makes terrain editing unbearable on huge sizes (although GPU painting can be investigated to some extent).

• Ability to do per-viewport, customizable LoD in 3D #7786 : needs ability to do custom LoD that works in multiple viewports (currently limited to _process on a single viewport), so that the renderer doesn't chugs on culling and drawing the whole landscape, especially on split-screen games. Custom, because LOD on a terrain is often different from LOD on a single model, mainly due to the constraint of keeping the terrain watertight with seams, and that quadtrees may be used instead of chunks of the same size.

• Scene without changes got saved (give some unexpected behaviors) #8994, Saving a tilemap also saves the tileset #5624 : scenes and resources saved even without changes, with a terrain it can freeze the editor for seconds and become very annoying. I disabled Ctrl+S saving the scene for that reason.

• Ability to access editor 3d camera in tool mode #6869 : LoD must update differently in editor because camera is not easily available. Current workaround is to use the camera provided in _forward_spatial_input. Ability to access editor 3d camera in tool mode #6869 was mentionned to solve this but it actually doesn't change the situation, so I'm still using the same workaround to make it work.

• HeightmapShape would be nice for efficient collisions, because mesh colliders are resource-hungry (althought they work decently if limited to a small region) --> would be solved by the HeightmapShape coming in the Bullet PR Bullet physics engine implementation #10013

• needs custom streamed resource so that a terrain doesn't have to be fully loaded in memory (only required lods around player), speeding loading times (the engine probably supports it already though, for sound). Custom loaders or custom resources will help to solve this.

• [tbd] : Editor: add an undo history memory limit, or use file caching, because terrain edition generates a lot of undo memory in general. It can be worked around by storing "handle objects" or IDs in the undo methods instead of the data directly, which map to data inside temporary archive files, effectively storing the action's data on disk rather than memory. But it has to be implemented for every feature.

• Texture arrays and 3D textures in shaders #9008 : needs texture arrays / 3D texture support in shaders, for efficient texture painting / terrain shaders. @karroffel worked on that for 3.1.

• A way to erase pixels or overwrite alpha channel of pixels using the draw_line method() and a new blend mode #10255 : need 2D blending mode(s) that treat alpha like a regular channel, so it can be used for more general purpose, such as GPU painting of splatmaps or other 4-channel data maps terrains can use. (which is way faster than doing it in C++ on the CPU)

• tbd: need more control over offscreen rendering, mainly custom image formats when making viewports and ability to make them render on demand (Render to texture functionality on demand #16828), so they can be used more efficiently for GPU-accelerated terrain edition (example: erosion needs to use directional blur over multiple passes, for which you currently have to wait for every frame instead of telling the renderer to do them all at once). Using current viewport forces usage of nodes, waiting frames, and using RGBA16, which eats a lot of memory and bandwidth in some cases, or terribly lack of precision in other cases. Using texture channels differently is an alternative, however it complexifies code a bit, and forces copying the entire shaders just to change a few lines of lookup because Godot doesn't have Preprocessor support for Godot shader language #17303

• Godot consumes an absurd amount of CPU and memory when assigning a big texture to a model #17683 : improve resource usage when drawing big textures for the first time, as saving a terrain writes them all to the project, which causes re-import AND reconversion on draw, which can cause computer to freeze.

• tbd: integrate with navmesh generation. Currently navmeshes are generated using meshes, but a heightmap using a quad tree or streaming for LOD will never have them all present at full precision. My plugin recently made its generated collider available in the editor, but the navmesh generator is not using it, and probably can't because it's still a grid instead of a mesh.

• tbd: integrate with lightmap baking. Currently Godot only takes static meshes into account but a large heightmap using a quad tree or streaming for LOD will never have them all present at full precision, and they are displaced in shaders anyways. This one could be very hard to solve without either deeply integrate the terrain, rewriting a plugin lightmap baker from scratch, or change the baker so that it uses a GPU technique taking unshaded rendering result into account (but streaming would still come in the way).

User requests:

• Terrain Node and Terrain Engine #3616, [3.0] - Ideas #8124, Ideas for future #8254, Simple mesh editing tools #4304
  In several occurences my GDScript plugin was mentionned. I once switched it to C++, then back to GDScript because it seemed to work well enough and it allowed people to use it more easily. Unfortunately it still is a bit slow in some areas, and mostly suffers from not being easy to integrate with the engine.
  A 3D terrain is quite a beast to have in game engines because very often (if not always), other components of the engine might need to interact with the terrain in many different ways.

Issue tracker on my terrain plugin:
https://github.com/Zylann/godot_heightmap_native_plugin/issues

Won't do for now but to consider for Vulkan:

• Need more vertex attributes (for terrain shading) #9134 : needs 2 additional Vector4 vertex attributes for texturing (weights and indices), in order to exploit texture arrays. The current workaround is to use UV2, COLOR or BONE WEIGHT attributes, but it limits available attributes a lot.
• [tbd] : indirect drawing of meshes (glDrawIndirect on renderer side, also supported in GLES3) to draw multiple subsets of mesh arrays so that we can swap LoDs really fast and reduce the amount of draw calls for all chunks of the terrain. This also gives the opportunity to bake chunks for good, to a point they don't need any remeshing as lods update (current method has an exploding number of remeshing) (not in GLES3 core... https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDrawElementsIndirect.xhtml)
• Add Support for Geometry Shaders #10817 Tessellation shaders, so that we reduce mesh data while being able to dynamically increase resolution to smooth near ground

[LikeLakers2]

Someone should turn this list into some checkboxes. And if someone does, #5624 #6869 and #9134 are all fixed. #8124 and #8254 are closed as well, for not being an actual issue.

[Zylann]

Even though it's what I do currently, I wasn't really convinced by #6869 because it makes a hack easier to do rather than solving the problem of terrain LoD cleanly, because:

1. camera is needed all the time, not only when input is received
2. stealing it in a variable for reuse in _process is dangerous because it's not the only one (multi-viewports) and you don't know what can happen to this camera outside of _input (I believe there was a reason for it to be a parameter).
3. there is an ifdef in my module just to get the camera from somewhere else if in game or editor...

Although it's not nice, I'll tick it anyways because it makes the thing mostly work, the real problem is the inability to have LoD that works on multiple viewports :p

#9134 was discarded, but it was mostly a nice to have, we'll see in the future if there is a real need for it

I updated the list

[mhilbrunner]

Would also be interested in this for voxel stuff.

[reduz]

Will work on this for 3.1, getting a terrain engine going would be great.

…

On Sun, Dec 3, 2017 at 7:48 AM, Max Hilbrunner ***@***.***> wrote: Would also be interested in this for voxel stuff. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9046 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z25UrnGLplD5KGmez6OnE3Pizqa3Uks5s8nyJgaJpZM4NvYUB> .

[Zylann]

@reduz are you going to work on this or should I continue on my heightmap module with technical directions for 3.1? I have a handful of open issues on my repo already, but I'm not sure what you would expect to land in Godot among things we would like to do (especially large terrains).

[MirceaKitsune]

Thank you for the info, this will be a good issue to follow. I'm myself waiting for heightmap terrain support, and also very interested in the possibility of voxel objects being supported eventually (blocky and smooth alike). I hope the next 3.x releases will offer at least basic heightmap terrain.

[mhilbrunner]

Moved to 3.2 for now.

[MirceaKitsune]

A shame it couldn't make it in 3.1. At least 3.2 isn't too far away... I really hope it happens this time!

[Zylann]

Just added mention of navmeshes and lightmap baking.

[mindinsomnia]

What are the chances of getting this in 3.2? =)

[mhilbrunner]

If by "this", you mean built-in terrain, then slim to none. This is about providing the prerequisites so third-party terrain addons can work (and maybe eventually built-in Terrain) :)

[MeshVoid]

The inability to create terrains in Godot and lack of time and expertise on my part to write coherent tools of my own or edit the ones that already being developed by community made me switch engine for a project I'm working on, although I wanted to be able to do it solely with Godot. I can not reiterate how important it is to have a solid terrain system in 2020 for a 3d game engine. Scalable in-built terrain systems are being utilized in so many games now and other various industries like filmmaking, architecture visualization etc. IMO, having these features would attract so many more users and companies to Godot and propel it forward even faster. I do understand that there are multiple other more pressing issues that are probably more important to solve first, but I hope one day we can see an awesome built-in and performant terrain system in Godot.

[Calinou]

@MeshVoid Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

(Also, did you check out https://github.com/Zylann/godot_heightmap_plugin?)

[MeshVoid]

@MeshVoid Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

(Also, did you check out https://github.com/Zylann/godot_heightmap_plugin?)

Hi! Sorry, I did, yeah, awesome work by Zylann, still really hard to control scalability and changes and needs a lot of further improvements and stabilization. I also tried implementing my own chunk system with relative success. But chose to stick with world composition and level streaming system in other engine though.