Landscape in Godot?

Are there any plans to add landscaping to Godot? I’ve been in Godot for a long time, but I’ve always been surprised by the lack of landscape, this is present in any 3D game engine, why is this important question not raised, what are the problems with this?
I’m scared that if it’s not so soon, such an update will bypass Godot 3.6

1 Like

The “problem” so far is that terrain/landscapes tend to be a bit specific to the game you’re making, as far as I know there is not one official terrain design for Godot yet. However, there’s multiple plugins being developed by different people. I’m not up to speed with them, but I think there’s some from Zylann and some from Tokisan Games.

3 Likes

I know the plugins, but I want some formality. Maybe we should hire the developers of all the landscape plugins and do it officially? If there is no serious problem in this development.

1 Like

I don’t think we should, the project has a lot of things that are way more critical than an official terrain for now.

There is a proposal here Implement Terrain · Issue #6121 · godotengine/godot-proposals · GitHub
You can follow there for the state of terrain

2 Likes

when searching the Godot Proposals issues on GitHub for “terrain”
i found this issue by Logan Preshaw, suggesting that a dogfooding initiative should be started so the core Godot team finds obvious issues like the lack of Landscape (it’s professionally named “Terrain”) and many other issues:

long quote (4 paragraphs)

Blender is a very successful FOSS project in large part due to dogfooding (the act of using your own product to develop finalized projects, aka “eat your own dogfood”).
This has been a priority for the foundation since 2006. Discoveries and developments in these short film projects have provided incredible benefit to Blender as a whole and directed the team towards better prioritization of features that artists will actually use.

Godot as of now has a profound lack of dogfooding.
Lead devs do sometimes embark on their own game development projects, but small-scale personal projects that may never see completion by a single dev is not dogfooding.
Your users making their own games and then reporting bugs or proposing features is also not dogfooding, since they have no control over the project at large and their suggestions or discoveries may be (and commonly are) lost in the Github deluge.

This lack of dogfooding is evident in my own testing; nearly every time I’ve pushed the engine to do something that wasn’t trivial, it has either been impossible or was met with great friction.
Many of Godot’s most basic systems (such as the asset workflow and lightmapping) are cumbersome beyond surface-level use cases, with very little meaningful control offered to users with no ability to simply implement the missing parts themselves.
Highly-demanded core aspects of the engine such as a terrain editor have been asked for time and time again without any implementation or prioritization, regardless of the fact that they are well-established crucial features in other engines.

These issues would become startlingly obvious and then quickly prioritized by the core dev team if projects were developed in-house with the explicit purpose of building games with Godot.
Many times I’ve used a particular feature and found it startlingly obvious that it was developed and implemented by an engineer who seemed unaware of how those features are already implemented to perfection in other engines, or simply unaware of how a game dev or artist would use that tool. Prioritized feedback based on undertaking real projects would make a world of difference.

this issue is closed because passivestar pointed out that Godot is already being dogfooded:

I thought it was already taken care of?

Huh, indeed it might be.
I thought I saw something like that around but wasn’t sure. Colour me uninformed in this case :sweat_smile:

the issue is closed as completed, which means that it’s resolved.