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.

[HectorCastelli]

@Zylann is already working on a terrain plugin that would add such functionalities to the editor.

This Reddit thread discusses a similar request to yours on a little more detail.

I understand that other engines like Unity and Unreal have tools for terrain building. Those are not exclusive features in the industry. You can always use other tools, like Blender, to make your terrain and import it into Godot.

[MostafaMTH]

@Zylann is already working on a terrain plugin that would add such functionalities to the editor.

This Reddit thread discusses a similar request to yours on a little more detail.

I understand that other engines like Unity and Unreal have tools for terrain building. Those are not exclusive features in the industry. You can always use other tools, like Blender, to make your terrain and import it into Godot.

I know but when its official and builtin you run into less limitations and it enhances the workflow

[Xrayez]

Another question is whether someone could give @Zylann authority over the features that he's been developing almost solo to be maintained directly in Godot. He's been pushing quite a bunch of changes to help him make the terrain module more useful over the years anyway (at least that's what I've noticed). I'm almost sure that it would be the "dream come true" moment for him, but I might be exaggerating a bit. 🙂

Given how certain ideology is being kept locked for Godot development, there's another possibility that @Zylann decides that he'd rather keep everything as-is, making his development decisions more independent.

I understand that other engines like Unity and Unreal have tools for terrain building. Those are not exclusive features in the industry. You can always use other tools, like Blender, to make your terrain and import it into Godot.

AFAIK most of the terrain stuff are actually modules which can be toggled off if someone doesn't need it. I suppose it also would create problems with bloated binary sizes for mobile platforms if the module is included by default (which is the point) but I believe the bloat is inevitable anyway even if Godot manages to merge only the smallest enhancements over the long time unless they completely stop accepting PRs.

We basically need to come up with an easy-to-use mechanism to dynamically include needed modules which would work on all platforms. I know we have GDNative for that, but recompiling the engine is still go-to option for me personally.

Imagine downloading a two separate Godot builds:

• Download "Godot: bare"
• Download "Godot: extended"

But if we had an easy ability to simply "copy-n-paste/drag-n-drop" needed modules, this proposal wouldn't be created in the first place. Imagine C++-like modules easily shared via AssetLib. I would also be fine downloading the source code via AssetLib, but then Godot would have to provide an easy way to compile the binaries for all supported platforms given the source code.

Say "No" to naysayers! 🙂

[YuriSizov]

@Xrayez
Maybe it should be one download, but optimizations are performed per project or per install, based on the type of project you are planning on creating? It may require some compile time, maybe, but ideally at that point it should just download necessary modules and plug them in. Would definitely require changes to module system and distribution, but can streamline the experience for a lot of newcomers. Think how IntelliJ IDEA or Visual Studio are set up during the first launch.

This is probably not feasible in the near future, though.

[MostafaMTH]

or maybe like unity offers multiple types of project like 3D and 3D with extras there can be an options like Project Minimal and Project

[HectorCastelli]

Not wanting to be a naysayer, but, instead of recompiling the engine, doesn't this fit much better as an editor plugin?

After all, it uses the existing engine, but changes the editor behavior. Plugins have the advantage of being enabled on a per-project basis.

I would imagine that it is more realistical to request the Godot community adopts @Zylann's plugin and maintains it with him than to incorporate this feature into the core editor.

[MostafaMTH]

Not wanting to be a naysayer, but, instead of recompiling the engine, doesn't this fit much better as an editor plugin?

After all, it uses the existing engine, but changes the editor behavior. Plugins have the advantage of being enabled on a per-project basis.

I would imagine that it is more realistical to request the Godot community adopts @Zylann's plugin and maintains it with him than to incorporate this feature into the core editor.

what do you mean by "incorporate this feature in the Core editor" but saying "doesn't this fit much better as an editor plugin" it does not make sense.

[Xrayez]

Performance is paramount so a simple GDScript editor plugin is not enough I suppose. Even if the editor is implemented in GDScript, the core functionality must be implemented via C++. One is mostly useless without the other If this becomes built-in, this leads to "C++ for everything" then.

[MostafaMTH]

Why dont they just add it built in with the editor, it will only cost like 5 - 10 Megbytes

[MostafaMTH]

Either way godot will eventually grow in size(in like 5 years it will be aroud 800MB

[clayjohn]

The editor vs built-in is obviously the major issue here. Everyone agrees that a terrain system is useful for many 3D games. So I would like to lay out some of the considerations the devs consider when deciding whether to make something "core"/built-in, and whether to leave it as an addon.

1. Does this feature work as an addon?
Certain things (like batching) have to be implemented in core and cannot possibly be an addon. However, a terrain system can work as an addon (see Zylann's incredible terrain addon).

2. Is this feature needed in all projects, or just some?
Similarly, certain features are needed in all 3D projects (e.g. camera). Others are only needed for certain game types. Terrain is only needed for certain 3D games.

3. Can we easily implement the feature in a way that benefits all use cases?
If we implement a terrain node, can we make it general purpose enough that it would work for every user who needs a terrain? The answer here is likely no. Even if we have a great general-purpose implementation, many users will likely need something more catered to their use case and will be unable to use the feature as is.

4. How much demand is there for this feature?
A lot :)

5. What is the benefit to being in core rather than as an addon?
This is a rephrasal of the last question in the template. It is not enough to say that it is easier for your game to have the feature. Similarly, discoverability is not an adequate response. If something can be an addon (as terrain already is), the only reasons to bring it into core is that the cost of being an addon makes the feature prohibitively slow, or that the feature cannot be fully implemented and is limited as an addon. Zylann has said before, he could make his terrain faster by moving it into core, however, at this time, it looks like his addon is fast enough. And would likely see the same speed benefits by moving to GDNative.

In consideration of all the above, it doesn't make sense to make terrain a core node. If you need a prebuilt terrain node, use the one that Zylann makes. It is extremely well made and should have all the features you need.

Further, Juan has explained in the past that he has no intentions of adding a terrain node for 4.0. So don't get your hopes up for that. However, in my opinion, once 4.0 is out, if we can show that a general purpose terrain node could be made sufficiently fast and user friendly, I think we can make a convincing argument to make one for 4.1 or 4.2.

[MostafaMTH]

That seems like a good plan, lets hope that Juan is convinced and releases it with 4.xx

[Calinou]

One reason to let the community handle modules like terrain is that it lets the Godot team better focus on core tasks. If we add too many modules into core, they can end up being poorly maintained as none of the core developers would have the time or skills to dedicate to it. The CSG module is one such example: Qodot has been largely exceeding its feature set and usability by now.

I think this is especially valid as there's not "one true way" to make terrain: heightmaps, marching cubes, chunking/LOD mechanisms, … This only adds up to the implementation complexity. This is why one of Godot 4.0's goals is to be more extensible (e.g. overrideable rendering pipeline, new plugin system).

@Xrayez I can see value in providing an official minimal build variant, but I get a feeling some people will be confused as to why some features aren't working when they're running a minimal build. The minimal feature set would also be a subject of hearthy debate 🙂

[Zylann]

As far as I understand, this proposal is actually asking for consideration of a terrain system, and does not actually propose any. There are indeed several "main" ways to create 3D terrains, and there is a most common one, so I suppose we are talking about heightmaps here.

a terrain system can work as an addon (see Zylann's incredible terrain addon).

After a long series of PR-ing features between 2.1.5 and 3.1, yes it does, by using a 10-years old technique in a pretty bold way (and more features are still needed :p), but...

he could make his terrain faster by moving it into core

This is where the problem is at the moment^^ It's an old technique, and the editor brushes don't scale well. Lots of operations to do, and not just painting images. Such system doesn't only render a terrain, but also supports undo/redo, calculates bounding boxes for Godot's culling to not go crazy, updates LOD at runtime in 3D using those boxes by showing/hiding meshes (so only one player), bakes normals in a custom way to avoid bias, copies heights around to build colliders, updates grass chunks around the camera etc... and I didn't get to layers, trees, rivers and roads yet. All this multiplies quickly because terrains are often really big continuous objects.

And would likely see the same speed benefits by moving to GDNative.

I would like to, but right now GDNative isn't very attractive. It is technically a very good solution, but currently it's lacking (stability, availability, maintainers, docs).
C# is a compromise, but is everyone happy to depend on Mono for this? Careful, it's contagious :p

If we add too many modules into core, they can end up being poorly maintained as none of the core developers would have enough time to dedicate to it.

True. I fix bugs in mine when they are reported, but lately I worked on other things and I'm not even fulltime, so I couldn't improve it or add new features. There will be improvements, but at the current pace it's just going to take a long time (as in months, years).

there's not "one true way" to make terrain: heightmaps, marching cubes, chunking/LOD mechanisms

Actually you described two common groups of terrain: voxel, and heightmap. First one is marginal and so complex that it makes sense to not be in core. Blocky version of voxels is actually in the engine already: it's called GridMap and is built-in, although it doesn't scale well when going big.
Heightmaps however are very common, and in both cases they are chunked/LODed in some way or another (otherwise we'd continue using mega meshes :p).
I'd say the main bugger for implementation choices is GLES2 vs Vulkan. Completely different constraints, enough to justify entirely different systems (or not even bother doing GLES2).

Overall... I just feel a lot of time will pass before we get more terrain stuff, but Godot 4.x series have lots of features incoming which may allow a few steps forward.
There can be a lot to dig into when making terrains, and I may have repeated a few things I expressed already in my repo's issue tracker (which you can also look into if you want to see techniques/problems/good/bad ideas).
Community is what makes things advance in this case. People who want, can, or even need this, AND want to do it in Godot. Apart from me and Bastiaan, I wonder if someone else made one, when I type "terrain" on the assetlib I feel lonely^^"

[Xrayez]

One reason to let the community handle modules like terrain is that it lets the Godot team better focus on core tasks. If we add too many modules into core, they can end up being poorly maintained as none of the core developers would have the time or skills to dedicate to it.

If a feature is at least 30% useful and Godot has enough userbase, I feel like there would be a high chance for someone to chime in and contribute to the development, not mentioning that including something in core already makes the features popular without investing much into advertisement. One example is how visual shader got a complete overhaul by @Chaosus as if out of nowhere. I'm not sure whether visual shader was developed by someone outside of the core team, but the shader code just got commented out when we moved to 3.0 despite of it being developed by core devs if that's the case.

Sure, you wouldn't see such people as one of the "core developers" at first, but it's a matter of delegating just enough of decision making without having to worry what other core contributors would say as their expertise might not even cover the feature set, but otherwise useful for many other people who don't see their development needs as specific. Because when you use something for a long time, it's difficult to call something "specific" in terms of a project, and not in terms of everyone's needs. Most people don't really care whether their desired feature would be used by many people or not, they just express the need which is quite real to them.

[MostafaMTH]

I think that if the terrain system was merged to core but as a plugin then it will be faster and not everyone will have to have it installed or maybe just have it merged to core and there by default in the node tree, it will only cost a couple of MB.It will be more user friendly if its there by default because they wont have to go look for it in the plugins

[akien-mga]

@jasperbrooks79 This repository is for technical discussion between developers about specific feature proposals, how and why they should be implemented.

Your enthusiasm is good to see but it's not constructive and it's all over the place, so by commenting here you actually divert contributors away from furthering a fruitful discussion on the technical details of implementing specific features. Please only comment if you have actual technical feedback to provide about use cases that you have experimented with and are familiar with.

I removed your above three comments are they are not constructive for this proposal's discussion and are generally off-topic.

[realkotob]

It's worth also considering implementing vector fields as an addition to the basic height fields.

https://youtu.be/In1wzUDopLM?t=470 (relevant content from 7:50 to 14:00)

This is backwards compatible with height fields, so users can still effectively import height fields and basically use them as vector fields that have 2 out of their 3 channels zeroed out.

So users can still make use of whatever height fields they have from external software, but they have added editing flexibility when treating them as vector fields inside the engine.

[Zylann]

users can still effectively import height fields and basically use them as vector fields that have 2 out of their 3 channels zeroed out

Users have to be well aware of using the feature or not, because 2 unused 16-bit channels (or 32-bit) is a big waste to avoid.

[realkotob]

There can definitely be an explicit toggle to enabling vector fields, with a warning so that users know it will add an extra overhead.

As for the second point of using a separate texture for the other channels, I think we can delay this optimization for now until we have some test-case numbers to study.

[Lexpartizan]

I would just like to remind you that the landscape is needed for a reason. There are many editors that allow you to generate a beautiful heightmap. But there are very few editors with which to plan the landscape. For example, specify that it is necessary to generate mountains here, here it is necessary to generate a valley for the city, and here a smooth road is needed. Yes, we need roads that won't stick out like rocks. This is a problem, yes. I've only seen this in L3DT with its design maps, but I'm not very happy with the results it gives and the time it works.

[Xrayez]

Hello!

As you may know, I'm maintaining Goost: a general-purpose Godot Engine extension that I and other contributors have been developing. Goost aims to be as a sort of "staging area" for Godot: most wanted features can be implemented in Goost, and if Godot core developers find that those features are needed and battle-tested by the community, they can be eventually ported and integrated directly into Godot!

Therefore, I've created a discussion at Goost for possibility of distributing Godot + Goost builds with terrain stuff integrated:

• Terrain: heightmap and voxels goostengine/goost#144

Perhaps @Zylann would be interested in this, but of course I impose no obligation whatsoever!

Thanks!

[ghost]

Hello 😀
I would like to register my vote here on the necessity of Godot having an official full feature terrain editor.

The 2D tilemap editor is much more than just painting tiles, it's about workflow, performance, efficient rendering, etc.

Well, the same is true for a terrain editor.
It’s much more than just sculpting a Height Map, it is an integral part of the 3D workflow, performance, blocking, iteration, world division, foliage, texturing, etc.

On twitter, Juan asked: What “...Godot needs the most to become more mainstream in the game industry”.

Well, I'm NOT asking to compete with Unreal Engine, but it's important to have at least basic tools in an official way, so people and studios can be confident enough to use Godot for 3D, without having to worry if the extension will be updated to a new version and the workflow is consistent.

Fun historical fact: Morrowind was released 20 years ago, but it had a really cool editor, with world partitioning, sculpting, texturing and more. Check out Todd Howard presenting it 👀https://www.youtube.com/watch?v=mHdOYw27GOM

[PrecisionRender]

Godot needs more tools for non-technical artists like this one built into the engine. People who have both the technical knowledge needed to make a terrain system and the artistic skill needed to design good-looking worlds with it are extremely rare. Plugins are nice, but they are a band-aid solution more than a fix. They lack the support, trust, performance, stability, and ease-of-use that core systems have. I think a heightmap terrain system being built-in would go a long way to improve Godot's 3D reputation.

[YuriSizov]

@PrecisionRender Due to the nature of development in open projects like Godot support always comes from the community first, be it a feature integrated in the engine or a third-party tool. Either way you need contributors who are going to maintain it, and they need to come first. Even with paid contributors, Godot as a project doesn't hire people from the outside of the community, even if they may be knowledgeable about some specific area. So any perceived support from the officially provided package is just a testament to the work done by contributors who stick around long enough 🙃

Also official tools can be provided as plugins and extensions as well, this has no bearing on their quality or the amount of trust you can put in. Godot is specific people, not a company, and those people are as trustworthy, or not, as any other contributor or creator in the Godot community. We are considering more advanced tools in future versions of Godot, but they will likely come as official extensions. This is not a measure of quality for us. Just means to provide a slim distribution that can be customized to your needs.

But this also means an extension can be made by anyone. Zylann is already porting his work to Godot 4 and reporting various issues to help stabilize the systems and polish the process, as one example.

[PrecisionRender]

@YuriSizov I understand. Thank you for all your hard work on this project. 👍

[Calinou]

@DimitriyPS Please don't bump issues without contributing significant new information. Use the 👍 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 🙂

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.