Short version:
I haven't much problems about how to save my data itself. The problem is when do I save and load it, because there is no "hook" to save that resource other than the ResourceSaver and ResourceLoader, which have no script API so far. I've been constrained to then load this in _ready, and save it with a special button from my plugin. I worked on a PR but still waiting for core dev decision godotengine/godot#19501

Detailed version:

In order to work, a HTerrain node need to know which terrain data to use.
Currently, this data is implemented as a small resource, and is only used to hold a path to where the big data is.
The big data is generated, and must be saved under a folder, not a resource, because there are multiple big files involved of variable sizes. Also, because a terrain is a big resource, it is desirable to support loading in a thread.

When a user hits Ctrl+S or saves a scene with a terrain inside, I need to:

• Know where to save the data, ideally create the folder next to the scene (or resource) is being saved. It is possible to embed the resource in the scene, but it is very discouraged to save the big data inside, which would bloat the file unnecessarily. So I need a path. I can solve this by simply forcing to choose a path in the inspector, and displaying a warning if the user forgets. In worst case, I can save in a default location like project root.
• Save asynchronously so it doesn't freeze the editor (reimport is another beast though). By default Godot seems to just freeze on the main thread to save everything. I guess it's fine if modification flags are handled properly so we don't keep saving it each time Ctrl+S is used?

Problems:

• Godot offers no API to know when a custom terrain resource gets saved. EditorPlugin has queue_save_layout and save_external_data, but they are not suitable when the terrain node is not selected. It would require the plugin to parse the whole scene to find all terrains, and there is no info where the scene gets saved anyways.
• Godot offers no API to integrate asynchronous terrain saving into the process of saving a scene, so it may freeze everything until done. This also prevents from waiting for any thread or GPU computations, the data MUST be ready anytime. If not, the user may end up closing the scene or even the editor before the task ended.

Note that so far I described a process involving a Resource. The reason I keep it is, the only thing Godot can save must be a Resource. But as you saw, what I want is not really a custom resource format, but a way to save many files, which are already supported in Godot, organized in a specific way, under a folder, as the user saves the scene.

The current workaround I have is to not save the terrain on Ctrl+S. Instead, I have a separate menu when the node is selected, on which you can "Save terrain" and "Load terrain", however this is not intuitive at all and can be a main blocker for people wanting to use this plugin.

Depends on godotengine/godot#19185

This https://github.com/vnen/godot-tiled-importer/pull/75/files

Copied from Zylann/godot_heightmap_module#13

I realized that the off-by-one required in terrain textures could become dreadful for VRAM usage, because it makes them non-power-of-two (NPOT). For example, the heightmap must be 1025x1025 instead of 1024.
On graphics card, NPOT textures may be upscaled to fit the next power of two, and big terrains could end up occupying 4 times more memory to fit that 1-pixel padding...
That's yet to be measured though.

Eventually a fix will be to clamp texture fetches so the terrain will have 1 stretched cell on its maximums. However, that could create seams for streamed terrain using multiple chunked textures.

Explanation about the 1-pixel padding: https://github.com/Zylann/godot_heightmap_module/blob/master/height_map_data.cpp#L22

Hi,

I'm very interested in having this plug-in feature complete and most likely enhanced further, so although I'm not a low-level coder any help you need for testing, documentation or similar, let me know, I might be able to help.

Do you have some kind of development roadmap?

Thanks and good job!

https://github.com/Zylann/godot_heightmap_native_plugin/blob/a3c01baafca23b0e7d5cd83e40684b5d91563323/addons/zylann.heightmap/src/util/pod_vector.h#L131

This function will have undefined behavior if doing vec.push_back(vec[index])

Fix it dude

Editor controls created by the plugin need to be freed when the plugin is disabled.
I overlooked this for a long time and didn't realize it was not done automatically. It's not really a leak since they are in the tree anyways, but subsequent enable/disables might cause hidden issues.

I don't know why. But grass disappears when looked from certain angles. I don't what those angles are in particular... It's hard to explain. You need more info, just comment :/ Again it's pretty hard to explain.

Map = texture used for terrain data

Calculating heightmap normals, painting or sculpting the terrain is basically down to processing images, in ways that extend a bit further than using the classic drawing functions.
This is utterly slow in GDScript (but relatively usable on small maps and currently works fine with undo/redo etc).

Using C++ would improve this, and is a reason why issue #14 exists, however it can't get around the fact it needs to reupload changes to the graphics card, which takes time and memory since there has to be a copy of the images in RAM.

An alternative to using C++ would be to use render target Viewports. The GPU is many orders of magnitude faster at this than C++, and it would dispense the need for the plugin to have a GDNative library to maintain and ship with.

However there are limitations in the engine that prevent this to be used more widely in this plugin:

• Blending modes treating alpha channel like regular channel (godotengine/godot#10255)
• A way to upload AND download partial textures sub-rects, which would be useful for undo/redo and bandwidth optimization (godotengine/godot#9571). Current workaround would be to use multiple viewports rendering sub-regions.
• A way to render on viewports having a custom amount of channel and bit depth, which would optimize bandwidth when sculpting heightmaps that need only 1 channel out of 4
• 32-bit support. That would be really nice to not constantly get artifacts due to progressive precision loss of 16-bit.
• Have a way to disregard sRGB conversion, since apparently custom blending modes would only be available in 2D, while the output textures are used in 3D
• Have a way to do broader kinds of operations that do not solely involve individual pixels, such as computing the min and max of an area of pixels. This is required for the culling system.
• Nice to have: a way to render a viewport immediately, forced to wait for 1 update loop, which makes computing slower and forces an entirely different code design (note: Unity has this feature).

The collision does not seem to work. I tried it in the demo and it didn't work their either.

In Godot 3.0.3 I get the error:

 res://addons/zylann.hterrain/tools/plugin.gd:274 - Assertion failed.

Installed from AssertLib. Heightmap Terrain Version: 0.6

Is this plugin intended to be a complete vegetation plugin, in that case it must have a good support for grass and foliage.
One of the best implementations for grass painting in Godot( you might have known already) is : https://github.com/marcosbitetti/grass_plugin_4_godot
But this doesn't work with Godot 3.x, I thought a few changes here and there would fix this issue, but a lot has changed from 2.x to 3.x, so a complete rewrite is necessary.
I am currently working on it, hope one day we can integrate these.

Does the grass system you have is based on sprites or mesh?
If mesh(or multimesh) is used, it can have wind shader, etc as material.

The collision not working for me, or still under process?

Here is the issue: https://i.redd.it/vwwv0ajghml11.png

Note to self:
I found it would be more intuitive if the tool switched automatically to texture paint mode when a texture is selected in the bottom panel, or grass paint if a grass item is selected.

As said in issue #50 the game I exported was this https://onemanstudios.itch.io/ouroboros-island.

In a terrain with only land, the changes made to terrain by LOD system at different LODs aren't obvious. But when I used a plane for water, they became more visible. For eg, while editing EditorCamera was close to the terrain, I sculpted in that view, when running the game the camera is far away, so some parts of the terrain which should be under water pops up. If you want some visuals or demo project, I can provide that.

Can I minimize these issues by using higher resolution?

The plugin isn't entirely functional if downloaded from Github into an empty project, or cloned into a fresh repo. This gives a bad impression, which isn't great because the plugin is actually working well.

This is because Godot runs the plugin before its assets were imported (icons mostly).
The current workaround is to restart the editor.

It needs an engine fix to the following issue: godotengine/godot#17483
And potentially this: godotengine/godot#23937

The current installation instructions say to copy the plugin to a folder in the project. However, it might be easier if the plugin could be installed via AssetLib. What are the plans to publish this plugin on AssetLib?

This was supported in the module version of the plugin, it should be re-added so we can import 16-bit heightmaps, for example from WorldMachine.

Large terrains (2048x2048 or more) are nicely supported and run fine at 60 fps in the editor.

However, saving a large terrain can cause your computer to freeze and slowdown very badly, as soon as the generated textures get written as PNGs in the data folder.

The reason why it happens is because Godot is reimporting those textures in two steps:

• Godot detects changes and reimport all images, which takes some time
• Then Godot detects they are used for 3D, which in turn allocates huge batches of memory, often hitting the ceiling of your computer's RAM.

The memory Godot allocates exceed more than 20 times the memory such textures would normally take in memory if they weren't compressed.

Fixing this depends on godotengine/godot#17683

Godot Image resizing functions are really bad when it comes to 16-bit. When the terrain's resolution is changed, they seem to create artifacts on the whole terrain.

It's not a problem if you don't care about the contents, since you can sculpt it afterwards, or scale the terrain instead to get a better result with less effort... but not if you want higher precision.
So I wonder if it would be worth to simply resize maps using a viewport?
What this implies is, changing resolution will no longer be immediate, will take more memory and a few frames before completing... quite far-fetched^^"

Tri-Planar mapping can eliminate these, but performance may be disturbed.
https://gamedevelopment.tutsplus.com/articles/use-tri-planar-texture-mapping-for-better-terrain--gamedev-13821
This post explains how to use tri-planar mapping, but it is for jMonkey engine, but the shader code looks almost similar to godot's shader language.
Putting an option to enable or disable this one would be cool.

When a scene with HTerrain is run, debugger shows the following error:
Invalid call. Nonexistent function 'set_shader_param' in base 'Nil'.
(In stack)
0 - res://addons/zylann.hterrain/detail/detail_renderer.gd:247
1 - res://addons/zylann.hterrain/detail/hterrain.gd:648

To me, the terrain worked fine in the editor, but in exported game terrain didn't show up. I tried to peek into the .pck file to find any missing files, but no PCK viewer/extractor is compatible with Godot's PCK format.
Then I opened the PCK file in notepad++ and searched for files in terrain folder, then I found that "height.bin" is not there, so I tried adding a filter to include *.bin files in export options in Godot, and it worked.

I know that this is not an issue in the plugin, but I thought it would be a good point to mention.
Perhaps an easy workaround here is to use ".res" instead of ".bin", as Godot exports .res files, so users need not have to remember adding filters to all export configurations for all projects that use this plugin.

By the way, Godot 3.1 alpha has been released, have you tested the new features that you have been waiting for, is saving automatic now.

Also, I like to contribute to documentation, do you think it's the right time for documentation or wait for some more time.

If possible I will try to make some cool screenshots of terrains with trees, river, waterfall, rocks, grass....etc, to showcase.

Yesterday it seemed fine, but now when I paint, it's not accurate to where I aim the mouse.
Video attached:

https://streamable.com/wm5so

the gizmo for HTerrain node is not responding, has to be edited manually in inspector.

Nodes must be able to collide with the terrain.
For this, the terrain has to generate a collider based on its heightmap.

It can be entirely generated, or streamed around a limited region around a defined interest point (the player's position).

There is a HeightmapShape we can use from PhysicsServer (provided by Bullet), but the integration is currently broken.
Needs this PR to be merged to the engine (and officially released): godotengine/godot#17806

Operations that run through the whole terrain (import from image, resize, format change...) are very expensive and freeze the editor. Terrains deal with large data sets, so there is sometimes no way for an operation to be instantaneous.

The plugin should use threads or time slicing when possible and show a modal progress bar.

The former is possible, but not the latter. It needs to be exposed.
Depends on godotengine/godot#17763 and godotengine/godot#19185

We should be able to import a splatmap, just like we can import a heightmap. This should be quite straightforward since there is less processing to do.
This is also required when importing a terrain from WorldMachine (note to self: which format is WM using? probably just an image format. If RAW, will need a bit more work)

Current workaround is to modify the splatmap in the terrain data folder and reopen the scene, however this is the work-format for the plugin so it might not be suitable for direct edition (especially the alpha channel, which is not used for transparency here).

Need to write some documentation to help people getting started with the plugin.
This is low priority for now because the plugin is still in pre-alpha stage.

Hei,
I am having a bit of difficulty even figuring out how to start with this plugin. Would you consider publishing a brief tutorial video, showing how to create a simple terrain with this plugin and maybe a few modifiers?

BR,
Brylie

Repro:

1. Open an existing terrain
2. Open the terrain generator and apply: old normals are still present even if the terrain is flat.
3. Editing the heightmap doesn't fix it
4. Changing the shader does fix it

I think it's due to recent changes in master related to custom shaders, they are not grabbing the newly generated texture (because Godot separates StreamTextures and ImageTextures and sometimes the plugin swaps one for the other...)

Raise and Lower tools are quite primitive nowadays, and mostly used for blocking out a terrain or quickly adjust it.
A new kind of brush is needed, which would add details to a roughly sculpted terrain.
It should be based on fractal noise, so that will require a noise library such as OpenSimplex. Given how small such libraries are, it's possible to embed OpenSimplex within the GDNative C++ code...

Textures generated by the plugin are saved as PNG. However, Godot automatically import/re-import them as lossy compressed textures (because it's the default), which reduces their quality (regardless of them being normal maps, albedo etc).
When saved over and over, the plugin sometimes has to grab the texture data and save it (because the image data might not necessarily be in RAM), which compresses it even more and destroys quality.

This is not something the user has to setup, those textures must have the correct settings from the start because they are generated...

Edit: I think the terrain should never grab the texture from VRAM in order to save it, it should be the other way around. Using the texture from VRAM only makes sense if the terrain is configured with non-compressed textures.

This would be mostly to make pathfinding navmesh generator work, because Godot is unable to use the heightmap or even the meshes because they dynamically change for LOD.
Before having a go, it should be discussed shortly with core devs, maybe the technique Godot uses to generate navmeshes has an optional parameter taking heightmaps or something, to be sure we are not missing a simple alternative.

When seen as an editor popup, the ChannelPacker tool has wrong layout, but it's fine in edition and ingame (although it's not going to appear ingame because it's a tool).

For now the minimum size of the popup is expanded as a workaround.

Depends on godotengine/godot#17626

Note to myself:
The brush decal makes it hard to see what we paint, I think it should be changed to a circle rather than a full disk. Also, change it to reddish color.

This shader formula seems to work fine:
g = clamp(1.0 - 15.0 * abs(0.9 - len), 0.0, 1.0);

When you load textures with the terrain texture editor, their color space is changing due to the fact they also get rendered in the GUI. This causes the terrain aspect to change badly.
When they don't do that, they are displayed darker, which isn't good either.

How can I display textures in the GUI without interfering with the user's texture options?

Depends on godotengine/godot#8155
Also godotengine/godot#18941

We could spare 2 texture fetches by calculating the blends weights in the vertex shader, and then sample the two most significant detail normals only in the fragment shader, and the others in the vertex shader.
This requires a bunch of ifs, but according to a graphics wizard friend it's worth it to spare texture fetches.

The reason why we would sample only 2 is that in most cases, only two detail textures will be blended. It's very rare that 3 or more are visible on the same pixel, so this optimization should have very little impact on overall quality.

Currently the plugin is limited to 4, or maybe up to 8 different textures. Adding more would drop performance significantly.

In order to support more, we could use texture arrays in a new shader, but Godot doesn't support them yet.

Writing an atlas-based shader could help emulating texture arrays, however it has annoying limitations such as pixel bleeding with mipmaps and filter.

Eventually there should be a more flexible API so shaders can be switched and the editor can adapt to which features it supports.

Depends on godotengine/godot#9008

Because the plugin has no way to update only the part of the terrain that changed on the GPU, the whole terrain is updated every frame while painting. It is worsened by the fact the plugin already handles chunking of the data during edition, but the function that was made to update partially the texture has to default on a full update, so each chunk gets to upload the whole data (see the skull in HTerrainData).

What the plugin expects is to be able to update partial regions of a texture to the graphics card using Godot API.

Depends on godotengine/godot#9571

Copied from Zylann/godot_heightmap_module#15
I'm making this thread to reference useful info about other terrain systems. May not always be doable in Godot 3.0 (GLES3) while keeping the tool simple, but it's a good source of inspiration.
Note that spherical/voxel terrains aren't the target for this plugin, they work very differently.

Just Cause 2:
https://www.gamasutra.com/view/feature/192007/sponsored_the_world_of_just_cause_.php
Megaterrain, 32km across, layer types, streaming from CD, geomorphing, clipmaps

Witcher 3:
http://www.gdcvault.com/play/1020197/Landscape-Creation-and-Rendering-in
Megaterrain, more than 16km across, two splat layers (background and overlay), clipmaps, many twists, avoids discard to make holes

Lumix Engine:
https://github.com/nem0/LumixEngine
Classic heightmap, one splat layer using texture arrays, satellite map for far away terrain, uses CLOD

Texture blending trick:
https://www.gamasutra.com/blogs/AndreyMishkinis/20130716/196339/Advanced_Terrain_Texture_Splatting.php
Use alpha as depth to blend detail textures, looks similar to Witcher 3 overlay technique
--> currently implemented

Farcry 5 terrain system:
https://drive.google.com/file/d/1H6ouhi96pLg8WDlwXSGHFupPyZDv2MF6/view
10x10km, similar to what the module does, but also implements streaming to handle such a large size and most of it happens on GPU instead. The more I see those techniques the more I think Godot should support compute + scriptable rendering pipeline, it's frustrating :p
Also outputs NaNs in vertex positions to create holes instead of fragment discard!
Uses ID+weight splatmaps, and optimize amount of texture fetches and do displacement decals by using... virtual textures?? Guess that's another candidate for partial texture streaming.
Also use the heightmap to bend tree roots and clutter placed on the ground

Horizon Zero Dawn
Multiple GDC videos on YouTube when searching for "Horizon Zero Dawn Terrain" on YouTube. Example of one https://www.youtube.com/watch?v=ToCozpl1sYY
The devs made a conference where they explain how all their terrain stuff is generated at runtime almost entirely from the GPU. They graph multiple maps to compose the landscape with rules, which they paint using brushes (paint forest, paint rocks, paint road...) and everything updates procedurally. Grass and trees are placed using dithered textures where 1 pixel is 1 object, and displaced with some noise.

Terrain in Urho3D:
https://github.com/JTippetts/U3DTerrainEditor

Erosion techniques

• http://codeflow.org/entries/2011/nov/10/webgl-gpu-landscaping-and-erosion/
  Also mentions Lithosphere, an open source node-based terrain generator similar to World Machine
• https://github.com/karhu/terrain-erosion: MIT code for hydraulic and thermal erosion
• Hydraulic erosion shader: https://www.shadertoy.com/view/XsKGWG

The terrain is black on my laptop... after playing with the shader and stripping it back to the basic albedo splatmap it works, so I think there must be something not quite right in the shader.

It seems like the grass brush uses opacity for two things at once.
Opacity is supposed to control how fast and strong the brush is applied.
But the grass brush also uses it to control grass density, which means it's impossible to erase grass by setting it to zero, because zero opacity means painting with zero strength = not painting.
Perhaps we could have another slider controlling that instead of the unused color picker?

This is currently hardcoded, it should be specified at import time.

The plugin currently works fine using a full GDScript implementation, but suffers from performance limitation in some areas. These areas can be optimized a lot using either GPU or C++ implementations.

The C++ implementation exists, but is currently not enabled and slightly getting out of date.
It uses GDNative and C++ bindings: https://github.com/GodotNativeTools/godot-cpp
It is already 99% the same as the GDScript one, though recently the GDScript implemention kinda became the reference since I worked on it a bit more and helped finding more areas to work on.
Eventually I should come up with an API reference that both implementation should mirror, so that people can use one or the other without hassle.
Note that the C++ implementation is intented to only contains core features + things that need performance.

The reason why the C++ implementation is not the default is because it's not stable, mainly due to the C++ bindings not being stable in the first place. Also, there is a lack of validation layers which would prevent unexpected crashes if users make mistakes in calling functions etc.
Working on this part requires to also work on the C++ bindings to provide all this.

Also, I only have a Windows computer so I can only work on libraries I can compile and test from there.

Selecting an item in the bottom panel should also select the tool associated to them, however this doesn't happen when creating a detail item (grass), that's misleading.

Paired with #4.

When creating a HTerrain node from scratch it causes errors in the console. Maybe they are harmless though (a terrain without data cannot have shader params because the material cannot be initialized properly).

Also, the current expected flow is to create a HTerrainData resource, save it and assign it to the HTerrain node. While this appears to work, the terrain doesn't appear in view, so there is something to fix here.

In general, the flow for creating a terrain from scratch should be improved, especially since I separated the demo in another repo, people who don't know/don't want to download it should be able to create a default terrain in a few clicks.

The terrain could be created with a default data assigned, however there MUST be a place to save this data (it's made of multiple files!), and Godot offers no API to warn the user on save. Such resource is too heavy to be embedded in the scene, so in case there is no resource path specified, it could be generated with a random name maybe... and then have the ability to change the folder name/path later on?

Edit:
Actually, I think people don't see anything because the default terrain has the same color as the default background, if the scene has no directional light:

Godot master ff01fd57bc19d9f4cb3929dbee87cdd9eda578e1
Windows 10 64 bits
Powershell

In Godot 3.0.4, I used to debug my plugin by using the command line debugger (-e -d command line options), and using Ctrl+C (keyboard interrupt) to break out of a script error and close Godot. This left the terminal open, allowing me to keep track of the logs and easily restart the session without retyping commands.

Now I wanted to debug it using a build I made from master, but I noticed keyboard interruption no longer stops the process. Instead, the debugger just repeats the error. I tried using q for quitting, but it didn't quit and stayed blocked on the last script error, so the only way I could close was to close the terminal...

Currenlty, the heightmap is saved internally as a binary blob, because Godot doesn't support saving an Image using a 16-bit color depth format. The downside is, it occupies more memory and cannot be inspected with an image editor.
Ideally, I would need a 16-bit UNORM format.
PNG and EXR would be good candidates.

Depends on godotengine/godot#17450

Godot 4 update: #34 (comment)