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 :slightly_smiling_face:

[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.

[jasperbrooks79]

Thanks, I am starting to realize how much cool one needs to be, to even contribute to the engine, like have knowledge . . . One needs lot more skill, than I have, with code, 3D, engine . .

Will try to take it elsewhere, I'm too noob, to help much, sry . .

<3 . . Again, thanks for this amazing engine, so much fun, will listen, not talk . .

[ghost]

Thanks, I am starting to realize how much cool one needs to be, to even contribute to the engine, like have knowledge . . . One needs lot more skill, than I have, with code, 3D, engine . .

Will try to take it elsewhere, I'm too noob, to help much, sry . .

<3 . . Again, thanks for this amazing engine, so much fun, will listen, not talk . .

ah that's too bad, i really wanted to see your feedback... it sucks that your comments were removed

[NHodgesVFX]

Built in terrain would be good. I have used Zylann's heightmap plugin in the past but kept running into issues that would require engine fixes. Its true there are alot of ways to implement this but I think a voxel based editor that supports both blocky and smooth terrain that can optionally use a height map for generation makes a lot of sense. This way 99% of use cases are supported. not only can you make a static terrain using a heightmap you can also modify it in game if you wish.

Maybe Zylanns voxel tools can be merged to core for this purpose. It seems like it has everything, maybe adding a more complex and integrated editor interface for editing terrain would be needed though.

Repurposing Zylans voxel module seems like the best way forward as it could support the majority of use cases and be done in a timely manner.

see https://www.youtube.com/watch?v=J8Ek3GpJ4L0 and https://www.youtube.com/watch?v=hqhHRdcakv4 for what can be be done using a system like described here

[mrjustaguy]

I agree, Voxel terrain is probably the most general, as it can be used as a Height map (if each point on the XY plane has only 1 Height (Z) value) which means Height map support arises from a very simple modification to the voxel terrain, so https://github.com/godotengine/godot-proposals/issues/1367#issuecomment-674290563 is as such very easy to support, as Height map would function as a subset of the Voxel terrain, as the only difference between Voxel and Height map is essentially the fact that Voxel can have multiple Z values per XY, as opposed to Height map that can have only 1 Z value.. Also note that the Height map and Voxel map could be converted both ways (albeit with the loss of data when converting voxel to height map due to lack of Z values)

I cannot think of a single thing that the Voxel terrain can't do that a Height map terrain can.

as far as what features should be available: 1) Dynamic Noise-based map generation (basically running OpenSimplexNoise get 2d/3d value on vectors that are within range to be considered active (or well generate chunks), and thus allowing for inf new terrain, both voxel and heightmap)

2) Construction/Deconstruction, fairly self explanatory, Voxel advantage, could store the changes made to work with 1) so that the Constructed and Deconstructed parts persist when the chunk is unloaded, while not having to save Every bit of the chunks. This could be done by having an array of "Flip" vector3s that would flip that position's voxel state (so if there is a voxel there in the noise, remove it, and if there is not, add it) and the array can be a part of the chunk. Unchanged chunks would thus have No memory usage or Save space usage, as all that would be needed is the Noise Settings (seed etc) to reproduce the same noise map when needed

3) Be compatible with Standard Godot Materials, instead of using it's own new formats

And a handful of really obvious ones...

4) Collisions based on how the terrain is set, so blocky for blocks, and smooth for smoothened voxels, to match rendering, so that smoothened voxels don't make the character moving on them go up and down them like they are blocks.

5) Texture Painting Tools, Mapping tools (for creating your own maps, if you don't want to use 1)) and the like

Everyone Feel free to add anything I might have missed, but I think This fills out almost all the needs one could have from a terrain system, and also isn't too difficult to efficiently implement (relative to a basic, much less flexible terrain editor)

Append: 6) Value of the noise should also be usable to set voxel type on a voxel, and have the ability for map generation to determine at which values voxels start spawning.. example: Noise 0 to 0.2 no voxel, 0.2 to 0.4 voxel with type 1, 0.4 to 0.6 voxel with type 2, and so on.

Clarification: Types would have Texture Property, and potentially usable for determining custom stuff, for example in some games they could be used to give different resources when destroyed, or make them indestructable, or what not, really would only be up to the game creators to determine what properties they want for each voxel type.

[Zylann]

I cannot think of a single thing that the Voxel terrain can't do that a Height map terrain can.

• Consume less CPU
• Consume less memory (unless procedural sources are fully embraced, that's what No Man Sky runs on)
• Render faster for similar quality
• Have larger editable area

Be compatible with Standard Godot Materials, instead of using it's own new formats

It's always going to use specific formats as long as you need more than one texture on the same surface. In all plugins I make I often have to define a shader "API" where the plugin recognizes some uniform and assigns them, expecting them to be used in a particular way for the visuals to work best. Which is what Godot does already with "spatial" and "particles" and "canvas" shaders, they are just built-in and integrated with internal uber-shaders, while userland shaders have to do all that manually. And even for stuff like voxel terrain I still end up writing a bit of shader API to handle texturing, and seams (but mostly because Godot limits me a lot, like, I can't switch index buffers for example, have to reupload entire mesh whish is too expensive) and to fade LOD.

For heightmaps I think my plugin could be a good starting point, although it needs a better technique for LOD like GPU clipmaps and tessellation when available. Terrain stitching/streaming would be nice too as some people want to generate or import very large maps. If we still want GLES2 support with it, it might also have to encode the heightmap in RG8 instead of RH, unless vertex displacement is really not possible. And of course edition must be GPU-based :) I used CPU-based for a while but it's slower and harder to make brush features in.

Side note, I took a look at Unigine's terrain system, and while Godot might will take eons to even get there, it is quite inspiring https://www.youtube.com/watch?v=DhINNCo6Gg4

[mrjustaguy]

I cannot think of a single thing that the Voxel terrain can't do that a Height map terrain can.

• Consume less CPU
• Consume less memory (unless procedural sources are exploited)
• Render faster for similar quality
• Have larger editable area

Be compatible with Standard Godot Materials, instead of using it's own new formats

It's always going to use specific formats as long as you need more than one texture on the same surface.

Side note, I took a look at Unigine's terrain system, and although Godot might will take eons to even get there, it is quite inspiring https://www.youtube.com/watch?v=DhINNCo6Gg4

• Consume less CPU, A little bit yes probably even in the proposed Voxel heightmap emulation which would use the Voxel data to generate a Height map, by picking the highest value Z on a given point on the X,Y Plane

• Consume less memory, how? memory needed for a voxel based height map are the same. you need x,y,z in both, where X and Y are plane coords, and Z is height. Voxel can imitate Height maps by just storing the 3 coordinates (see previous point) like on would do with a height map.. Note: Voxels would inherently use more memory in voxel mode, however for the heightmap emulation is essentially all about finding the highest Z for a given X,Y point and you now have the same data as used by a Height map.

• Render faster for similar quality, simply not true, as you could bake out a mesh from the smoothened voxels if you need performance, resulting in the same thing the Height map gives you.

• Have larger editable area, What? how? both are ultimately able to go to "infinity" and beyond. only limits are how far X,Y,Z can go before issues, which is identical for the 2.

Specific Formats aren't needed, if you are using masks to determine what is going to have which material. For example encode Color 1 to texture 1, Color 2 to texture 2 and so on, and draw colors depending on which texture you want where you want it, and use that information to place the right textures.

[Zireael07]

Have larger editable area, What? how? both are ultimately able to go to "infinity" and beyond. only limits are how far X,Y,Z can go before issues, which is identical for the 2.

Editing many voxels at once is a performance hog. Try editing 20x20x20 voxels at once... While in a non-voxel terrain, all you edit is a couple of vertices, bam, done!

[mrjustaguy]

Ok, You misunderstood me then. For Heightmap, you are doing this: for X,Y -> set Height to Value For Voxel in Height map emulation mode you are doing this: for X,Y -> set Z to Value

Z==Height and you are only really making voxels that are on the Z/Height, and getting x+1,y+1,x-1,y-1 Z values to find the lowest of the 4, and drawing all the way down to That Z value +1 (to avoid an extra needless voxel), and ignore any of those 4 values if they are null (so out of bounds) instead looking at the ones that have an actual Z value and that part doesn't need to be fully real time, it can take a moment if it needs, but the data will be set at the exact same pace as height maps.

Note: Worst case scenario, checkerboard pattern between very low and very high points, say on a black and white checkerboard black is 0 and white is 100, then every white is going to draw 99 voxels (98 of which are filler for the gap), while blacks will draw only 1.

Actually, the more I think about it, the filler voxels might not even be needed to make a heightmap with voxels, totally negating even that scenario.

[NHodgesVFX]

Editing many voxels at once is a performance hog. Try editing 20x20x20 voxels at once... While in a non-voxel terrain, all you edit is a couple of

This is only true for editing if you baked the voxels so they can't be edited this isn't a problem. If you want to use voxels in game the developer needs to be aware of how many voxels they can transform and design around it. Although 20x20x20 is pretty low you can get much bigger editing areas with optimization

[skyace65]

As someone else who wants to use terrain for a project I'd like to throw in my two cents here.

For anyone who believes that having builtin terrain isn't justifiable because not every project uses terrain and it could work as a plugin, then the project needs to remove the tilemap editor, which is basically it's 2D counterpart and fits that description. Here's some other 2D nodes that fit that description. Path2D, Raycast2D, Bone2D, Joint2D.

I understand that we don't want the editor to get bloated with nodes and features. But there is no justifiable reason to keep terrain out of the editor given what's in there right now. It's a double standard.

And having that double standard makes it look like either 3D users are getting shafted, or the devs don't understand developer needs. Obviously the devs do care about 3D or we wouldn't be getting Vulkan, better lighting and the particle changes in 4.0. But that doesn't change how it looks.

I'm not expecting the devs to drop everything right now and make it immediately. But it should get added eventually.

[anunknowperson]

I recently started working on a terrain system for Godot 4. I try to get as many features as possible with the smallest size and complexity. Is it worth at least sending a PR to the core, or doing it right away as a GD Native plugin?

[YuriSizov]

@anunknowperson It would probably be better done as a GDExtensions plugin. It could later be adapted to core if there is a good reason for that.

[mrjustaguy]

I agree with creating this as a plugin, however I think Godot should eventually get a fully featured Terrain Editor built in to core, as it is a very common thing in 3D games

[clayjohn]

Is it worth at least sending a PR to the core, or doing it right away as a GD Native plugin?

I agree with pycbouh that for 4.0 you will need to target a GDExtensions plugin rather than GDNative.

I will also add that whether to use a plugin or build in to core will depend on what level of integration you need with the renderer. For a terrain system to be accepted into core, it will need to be fast, flexible, and capable of meeting the needs of most users who need 3D terrain. It may not be possible to check all of those boxes with a plugin, in which case you may need to add it to core.

If you are going to target core, then the terrain system will need to meet the needs of the majority of users interested in doing 3D terrains, which likely means you will need to provide an option to use a heightmap based terrain or a voxel-based terrain. This was discussed in great length in the contributor chat many months ago and no consensus was reached about exactly what features would be needed. But it was clear that we would need something flexible and robust.

[Zylann]

which likely means you will need to provide an option to use a heightmap based terrain or a voxel-based terrain

This is quite a big option you are referring to, since the two require wildly different approaches, each with their own pros and cons. At least it doesnt sound easy at all to expose as an "option", as opposed to different nodes altogether, and the two cannot be mixed without dropping niceties.

[clayjohn]

This is quite a big option you are referring to, since the two require wildly different approaches, each with their own pros and cons. At least it doesnt sound easy at all to expose as an "option", as opposed to different nodes altogether, and the two cannot be mixed without dropping niceties.

I hear your concerns. We are caught in a tough place because there is a huge amount of demand for a terrain node, but there is a clear lack of consensus on what users need. Many people only need a heightmap terrain, while others absolutely require a voxel-based terrain. My concern is that if we stick with one option or the other we will have just as many upset users as happy users.

In your opinion, what would a built in terrain node look like in core?

[Zylann]

I think a heightmap one would cover a lot of use cases already, and there are authoring tools dedicated to that, way more than voxel. Every other engine I know has a terrain system of that type, which can cover large landmasses with dedicated tools, rendering, physic and gameplay systems, and they don't need to have voxels. I think it's ok if Godot doesnt provide volumetric tech with it, at least not initially, because my feeling is if we want to shove in too much, it will never get available or will be too complex. It may be noted as well that voxel tech does not only span terrain use cases since it is versatile enough to make props and sometimes even characters, it has a lot to cover so it's easy to get lost. Though that's mostly my own opinion, when it comes to having terrain in Godot.

The difficulty is that a terrain system is like TileMap: it's something that spans your whole scene and touches lots of areas, rather than something ponctual that can be developped in isolation. So even if it's only heightmap-based, there is a lot to do. Many things in games are going to be built around it, because it's a base for the environment. Typical demands include import and sculpting, tearing holes that colliders take into account for plopping in cave/tunnel meshes, progressive level of detail without cracks and low popping to allow long view distances, painting ground materials that blend properly, scattering grass, foliage and trees, paths for rivers and roads (maybe also lakes or sea), supporting GI and pathfinding (these two being a pain point in existing plugins), and finally stitching/streaming for the largest ones. Sometimes all this also needs to be modified or generated in-game. (maybe the state of the art differs a bit nowadays but that's what I have in mind).

Some time ago my point of view was, that if we want core to remain compact as a single executable, it should only include features that can only be done there, which would be very hard to do only from plugin API. This is how today we have HeightmapCollider, partial texture updates, custom loaders, greyscale EXR, yet no terrain. But then looking at tilemap, there isn't that much hard stuff there. Just a lot of tooling and structure. It's here because it's used often. It's not Tiled or LdTk, but it's there, compact, and does the job. Now if we would like terrain to be in core due to high demand, while keeping this idea of being compact, such terrain system may need to be compact as well, so it would be a simple one, covering the most common needs. Which goes back to the idea I think it's ok to concentrate on a heightmap system, simple, but done well. A voxel-only system could be considered as another node, maybe something like Roblox has, but beware of the scope, it's a rabbit hole, and the limits are very different. And if Godot gets such terrain system in core, it's still ok for more heavy-duty systems to also exist as plugins due to their size and complexity, they may still draw some features from core.

[NHodgesVFX]

Thing is although its slightly less efficient a voxel terrain system could do everything a heightmap based one could do plus voxel stuff so its much more versatile.

[clayjohn]

@Zylann Thank you for your detailed comments.

Based on your concerns, I guess another option is to develop terrain as an addon and then make changes to core as necessary to ensure that the terrain can be optimized as an addon. That way we can keep the core lean and allow multiple plugins that will suit more specific use-cases.

[anunknowperson]

Is it possible to somehow release an addon from the official Godot account? It's just that plugins from the community usually do not inspire confidence, no matter what they are. Probably even if we take out a lot of the important parts of the engine into official plugins, we need to make a more user-friendly interface for managing them...

[Zireael07]

@anunknowperson: I know there are plans to move e.g. vehicle body to addons, I suspect those would be "official" too.

[anunknowperson]

As for the terrain system, I think it's worth deciding how to release it after it is ready - when its capabilities, performance and size are known. If it does not affect the core as a module, then it will be quite easy to transfer it to GD Extension.

[jordanlis]

Hello everyone. I just wanted to add some general comments to the conversation because I just find the subject very interesting. It's just my opinion, so it has to be taken with tweezers. According to me, it's obvious that a built-in terrain system should be developped one day But, as in many fields, the debate here is about how much time and developers do we have to work on such system vs how much it is asked and needed by the community.

Some things here are important to say in order understand the big picture :

• Godot cannot compete against other big game engines such as Unity or Unreal if it don't have such a feature. Professionnals and triple A companies particularly will continue to use these engines instead of godot until we have something similar or better than this for terrain mapping.
• Supporting such feature in core will assure maintainability because if it's not in the community, we will rely on only 1 developer working on that. We don't know if it will be maintained by him forever or what it will become. Particularly with the fast development of godot, there will be eventually some incompatibilities, etc. so it's a constant work that should be done by the Godot's community, not by only one developer and this should benefit from Godot's support
• In a technical and functional way, this feature should benefit from user's comments and their needs, which will be better adressed if it's directly built-in because we have a whole system here to report bugs, ask for feature, etc.
• A plugin system has no visibilty vs searching for a node called "terrain" directly in the editor. This implies that some people may not know that it's even possible to make a terrain with the plugin, this has not so much visibility and from the user point of view, this is one more reason not to use godot because he probably wants to go fast and use it in the most simple way. This should be considered. I mean, a game developer has so many tasks to accomplish, why should they bother on looking for a 3D terrain building system that they already have in another big game engine ? They won't just bother and use whatever is simpler for them. That's all, sadly.
• The more big features like this we have, the more development support we will have. I mean, MONEY in the patreon. We all wish it will work in the opposite : First, we have the money, then we spend it. But I think it's not in this way that this is working. I really think announcing big features like that will attract big companies and developers and it will attract thus more people financing the patreon.

I'm not arguing against people saying that we don't have enough developers available at this moment, that this is not the current focus, that this is an immense work or that this is hard to understand user's needs before even starting to develop the solution. I'm just saying that we should just accept the fact that this feature is probably a must-have and that we should try to move forward, step by step, in order to implement better this terrain system because it will greatly help the community in the ways that I described before.

Maybe we should just start by supporting officially the plugin, trying to port it in an alternative version like it's already done for the C# version, etc.

I hope that my comment is helping in some way, if not I'm sorry. Have a nice day everyone ;p

[txj-mssl]

That's right

[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:

• https://github.com/goostengine/goost/discussions/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. 👍