Add a built-in terrain system

[MostafaMTH]

Describe the project you are working on: I am working on mini open World TPP Game. I want it to be built with a built in terrain system so i don't run into compatibility issues and i want features to be added to. It will be very useful for a built in or official terrain system made by the Godot Core Team.

Describe the problem or limitation you are having in your project: I don't have a built in terrain system so i can build my open world game.

Describe how this feature / enhancement will help you overcome this problem or limitation: This feature will help overcome this problem/limitation because it will help game Dev using Godot build open world or mini worlds easier and will enhance the workflow.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work: How should i do that?

Describe implementation detail for your proposal (in code), if possible: I dont know how to code in C++

If this enhancement will not be used often, can it be worked around with a few lines of script?: No.

Is there a reason why this should be core and not an add-on in the asset library?: Yes, because it is needed for a lot of game developers.

[DimitriyPS]

Yes, Godot lacks a tool for creating and editing terrain. This is really a serious problem.

If we talk about the plugin - no, I'm not ready to trust. Too many hours of level design to depend on a third party product.

Blender is not suitable for creating high-quality large terrain. Moreover, making simple changes to the terrain incurs enormous labor costs.

Godot without terrain editor is not 3D!

[Calinou]

@DimitriyPS Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

[MrDixioner]

Godot is valued for its minimalism and speed of work. It has built-in physics, a particle system, basic modules for working with 2D and 3D graphics, lighting, and other things that are the framework of your future game or application. Adding everything that is in other editors, including the terrain editor, will only exacerbate the problem, not improve it. I believe that the features that some users need should be implemented as separate plugins, and not built into the engine core itself. Godot 4 has almost doubled in size compared to version 3.5, and runs quite quickly and smoothly. I don't want the engine to grow to 1 gigabyte or more and run like a tortoise, especially on weaker systems.

[DimitriyPS]

Godot is valued for its minimalism and speed of work. It has built-in physics, a particle system, basic modules for working with 2D and 3D graphics, lighting, and other things that are the framework of your future game or application. Adding everything that is in other editors, including the terrain editor, will only exacerbate the problem, not improve it. I believe that the features that some users need should be implemented as separate plugins, and not built into the engine core itself. Godot 4 has almost doubled in size compared to version 3.5, and runs quite quickly and smoothly. I don't want the engine to grow to 1 gigabyte or more and run like a tortoise, especially on weaker systems.

Do you think size linearly determines performance?

However, you can appreciate any fetishes, I personally do not condemn this. Trends in the game development industry are not determined by the Godot development team. The availability, accessibility, and functionality of tools for game developers in the Godot engine will determine whether it can become a full-fledged game engine in the near future... or it will remain the engine for hyper-casual and demo scenes.

[mrjustaguy]

Yeah, size has absolutely nothing to do with performance, just loading and storage.. Unreal isn't slow because it's 40GB+ it's slow because of what it's doing.

[DimitriyPS]

Yeah, size has absolutely nothing to do with performance, just loading and storage.. Unreal isn't slow because it's 40GB+ it's slow because of what it's doing.

Unreal, one of the most technologically advanced engines for you slowest?... It even sounds crazy. Let's open Steam and compare the quantity in the totality of the quality / complexity of games developed on Unreal and Godot.

Although considering the entry threshold and the target audience, Godot is objectively closer to Unity... the comparison of the number / quality of games on Steam developed on Unity and Godot is sure to be even more contrasting.

With all the shortcomings of Godot, I like it, I really want it not to stand still for decades, but to develop, so that its development would be determined by the established trends industry and the needs of game developers, and not by the "superstitious beliefs" of a narrow circle of people.

[Zireael07]

@DimitriyPS Unreal 4 (I haven't tried 5) is slow to install and slow to launch and slow to bake lights, and slow to do quite a lot of things. That's why I jumped ship to Unity, and then to Godot.

[mrjustaguy]

UE5 has improved things a little over UE4, but not by much...

As far as performance goes, just because UE is technologically very advanced, doesn't mean it doesn't perform like hot garbage, but it does so because it's hyper focused on getting the best visuals, which ironically makes it not have the best visuals for most users as they have to significantly turn things down to get good performance. EA's Star Wars entries prove my point rather well, with Fallen Order being the most demanding (even on medium which is the lowest it'll let you go) even when comparing to their 2 Battlefronts and Squadrons on ultra, and that's ignoring the horrible stuttering that UE (4 atleast) is well known for

For me, I'm using Godot because I find it very intuitive and easy to use (when the features are not missing ☹️ ), unlike UE, or worse, Unity which is a UX nightmare in my opinion, and the license is also far better.

[Zireael07]

but it does so because it's hyper focused on getting the best visuals, which ironically makes it not have the best visuals for most users as they have to significantly turn things down to get good performance.

I think you hit the nail on the head (but lets not continue the ue4 derail :P )

[Valeryn4]

None of the plugins work in Godot 4. The Asset Library is full of broken junk. When will they make at least some kind of terrain that will not break the entire project between versions?

Flatten an area, fix terrain, etc. very difficult. It's incredibly long and tedious to do the following:

• Open Blender
• Fix map
• Export map
• Import to Godot
• test
• Repeat 100500 times.

In UE or Unity, this procedure takes me seconds. In Godot, this takes tens of minutes, or even hours.

[Zireael07]

The Asset Library is full of broken junk. When will they make at least some kind of terrain that will not break the entire project between versions?

Godot 4 released like two weeks ago. You can't expect a huge asset like terrain to be updated AND tested in two weeks.

EDIT: Also, there's ZERO expectation that ALL assets will be 4.x compatible as they're, well, third-party except some engine demos

[celticintuition]

In UE or Unity, this procedure takes me seconds. In Godot, this takes tens of minutes, or even hours.

I think you have answered your own question there. Godot and Godot plugins are made by folks out of the goodness of their hearts and a desire to contribute to a community which has delivered amazing functionality over the past few years. Allow them time to update their contributions. There is also nothing preventing you contributing your own plugins to the community to fix the particular workflow problems you are facing.

[robbertzzz]

There is also nothing preventing you contributing your own plugins to the community to fix the particular workflow problems you are facing.

I don't disagree that this should be a plugin, but comments like these are very out of touch with the majority of Godot's user base: hobbyists and beginner developers. Someone with little experience building games won't have a clue how to work on an advanced plugin like a terrain system. They need stuff that works well out of the box, which is very rare for Godot plugins.

I would love it if Godot would start to support official plugins that separate teams work on (we don't need Rémi working on even more stuff) rather than individual enthusiasts with little time on their hands to update their plugins - unfortunately that's an experience I've had multiple times when opening feature requests for such plugins.

[daniklad]

I just wanted to add that I have also been working on a solution for the terrain problem. I think I may have a novel solution that could fit the Godot userbase. My solution uses GDScript + shader and has 0% CPU overhead because the shader does everything. It is fast enough that a less detailed version should work fine on mobile as well.

It is developed in Godot 3.5 but will work fine for Godot 4+. It has continuos smooth LOD and splatmap texturing. It is still in early stages but seems like a promising technique.

I have been inspired by Zylann's work and his engagement on this topic and the solutions that have resulted have been very valuable so a big thanks for that!

One of the early problems was loading of 16-bit heightmaps. Most tools can export a 16-bit grayscale PNG for the heightmap but Godot seems unable to import that. It gets converted to 8-bit which according to Reduz is to save texture memory for unaware users. That is fine and I managed to figure out that GIMP can convert that PNG to a PGM which is easy to create a GDScript loader for. A simple PGM loader looks something like this:

func loadHeightmapPGM(filename : String):
    var data = null
    var hfile = File.new()
    var bytecount = 0
    var width = 0
    hfile.open(filename, File.READ)
    hfile.seek(65)
    bytecount = hfile.get_len()
    data = hfile.get_buffer(hfile.get_len() - 65)
    hfile.close()
    width = sqrt(bytecount / 2)
    var himg = Image.new()
    himg.create_from_data(width, width, false, Image.FORMAT_RG8, data)
    var texture = ImageTexture.new()
    texture.storage = ImageTexture.STORAGE_RAW
    texture.set_flags(Texture.FLAG_FILTER || Texture.FLAG_CONVERT_TO_LINEAR)
    texture.create_from_image(himg)
    return texture

The plan was to use Image.FORMAT_RG8 for a total of 16-bit of integer precision with no waste and assemble the final value in the shader.

vec2 hmap = texture(heightmap, terrain_uv).rg;
float height = (hmap.r * 255.0 + hmap.g) / 256.0;

This does not work though so I must have messed something up along the way. The screenshot below shows 8-bit integer precision for the heightfield for now.

The terrain above was created in Terresculptor as my terrain solution has no painting or simulation at all for now. I have been playing around with Compute Shaders in Godot 4 though which seems to work so a future version may include some painting tools as well as erosion simulation.

I have made a few simple editor plugins already and it seems doable. I have only made painting solutions in 2D so far so I have some research to do to get that working. But as far as I can tell others in the community have already solved that.

[HydrogenC]

Terrian3D looks like another feature-complete solution for this, which takes as little as ~35MB of space. IMO this sort of basic functionalities should be integrated into the engine itself instead of being a plugin. Plugins sometimes cannot keep up with the iteration of Godot (which is particularly fatal for GDExtensions for it has a strict demand on version) asap. There may be multiple plugins implementing a similar functionality, which might cause a division of community.

[Calinou]

which takes as little as ~35MB of space.

This isn't little for a feature that would be included in every editor and export template binary, including 2D-only projects :slightly_smiling_face:

While a core implementation or even this extension could be made smaller in several ways (such as procedurally generating default brush textures then caching them), I doubt it's possible to shrink it below 2-3 MB in an optimized binary, which is still significant. Keep in mind binary size is very important when it comes to mobile and web platforms. It's already grown significantly since 4.0 – let's not make it worse.

Having terrain as an official extension would alleviate this binary size concern, but it won't resolve the issue that maintainers can stretch themselves too thin and become unavailable – just like a community-developed extension. This is probably the largest challenge, as the work that goes into a full-fledged terrain system and editor is easily something that can keep one occupied full-time.

(which is particularly fatal for GDExtensions for it has a strict demand on version)

GDExtension is currently marked as experimental, but it will eventually have better forwards compatibility thanks to the compatibility method system that was implemented in 4.1 to avoid breaking the ABI on every minor release.

[HydrogenC]

Having terrain as an official extension would alleviate this binary size concern, but it won't resolve the issue that maintainers can stretch themselves too thin and become unavailable – just like a community-developed extension.

Official extension sounds like a nice idea!

[CsloudX]

I'm download the latest Terrain3D, and found it dll file size only 3M. so much wish it can integrate to core. for this time, 3M was not big size, but it is so much useful feature for a game engine.

[starry-abyss]

If it's a DLL and not inside the Godot binary then size doesn't matter much. I would even say if half of Godot was DLLs instead of modules, the binary size of Godot for mobile and web could be much much less.

[LowLvlGod]

Maybe you should consider being more pragmatic rather than overly idealistic about disk space concerns. Essential features, including terrain, are more valuable to developers than saving a few megabytes.