Heightmap terrain editor should be built in Godot.

[MeshVoid]

Godot has one of the best an easy to use tile map editors for 2d games, but a lot of 3d tools like height-map terrain editor is lacking. There's already Godot proposal regarding the topic opened here: #445.

I've decided to open this discussion thread because there were none so far, and I would like to read opinions of developers and users regarding this proposal.

IMO, built-in, preferably optimized for general use height-map terrain editor can have a lot of uses not just for specific and niche games, levels for games of a lot of different genres, but also for 3d artists for architecture visualization and many other industrial applications. There are several plugins being maintained or written by the community for terrain creation both voxel-based and heightmap terrain. This topic is devoted only to the discussion of heightmap terrain editor not voxel terrain editors.

With that being said, as of now, there's Zyllan's heightmap terrain plugin for godot ready and available for users to be used with Godot 3.x versions.

This plugin is really helpful and supports a lot of formats for export, but is written entirely in GDScript and has certain functionality limitations. As we will witness the release of Godot 4.0 and further iterations of this wonderful engine, the question arises - Can we ever see in-engine implementation of a built-in height-map terrain editor in Godot with some basic functionalities?

Functionalities of a heightmap terrain nodes could include:

• Sculpting and making quick edits to heightmap terrain, changing it's size, resolution, sculpting holes
• Having the ability to create\export several terrain maps, not just one. Preferably have a functionality to extend the terrain by adding chunks to it and not dealing with the problem of "stitching" different parts of terrain upon editing. (This one is more complicated to make than the basic heightmap editing, I presume)
• Have the ability to add and quickly place foliage, or other nodes/mesh instances.
• Preferrably have a dedicated shader that would allow the user to stack multiple sets of texture maps to paint them on the terrain.
• Support as many export formats as possible to be compatible with loads of software packages devoted to terrain creation like Gaia, World Builder, World Creator etc.

Maybe in future such system could also have an inbuilt functionality that would make sure that engine preloads and unloads parts of the terrain and mesh-instances placed on it automatically based on the camera\specific node position without the necessity of every user to manually write it's own systems.

With that being said, I would like to open this discussion topic here and hear every opinion, feedback, thoughts on the matter.

[wareya]

Valve's Hammer editor has an interesting take on heightmaps called "displacements" that might be relevant here. In Hammer, heightmaps can be assigned to arbitrary quads, not just square or rectangular or axis-aligned ones, and vertices can be displaced in arbitrary directions, not just perpendicular from the quad, so you can (when necessary) model almost arbitrary terrain shapes purely in-editor without requiring special support for remeshing or overhangs or holes or anything. This is more powerful than naive up-axis-only heightmap systems, and can be used for arbitrary rapid art prototyping tasks, not just terrain.

(Displacements were referenced in other proposals like #1367; I'm just bringing the note here as well, that there are heightmap-like terrain systems that are similarly powerful to smooth voxels.)

[MeshVoid]

Really cool info! Great to know how something similar is realized in other engines. Although, I think that height-maps and displacement maps are the same thing essentially? And I believe height-maps not just store information perpendicular from the quad, as you describe, they can store info in all axes as far as I know, I might be wrong though, but I thought they could hold info for all axes in several channels of information if stored in 32 bit format (But it makes the file super heavy).

I might be wrong, but I think heightmaps and displacement maps are essentially the same thing? Also, by looking at the image you have provided it looks like the heightmap applied to a mesh object so that the user could sculpt details in editor? This feature is different from the usual terrain editor though, IMO. It's a neat feature, but it's not the same thing as a usual heightmap terrain editor you would expect in game engines (at least the ones that start on U letter).

Also, I think UE4 has the same functionality for mesh objects, you can displace them, you can sculpt exported mesh and it will subdivide the topology of the model and alter it, there's a lot of modeling and sculpting tools realized as an official plugin in UE4, but they have nothing to do with it's integrated terrain editor (I think Unity follows the same paradigm, both sculpting\modeling and terrain tools are separate). Also, I am curious how it's implemented in Hammer, does it have an LOD system, how scalable it is? Does it decrease mesh detail resolution depending on camera position and etc?

IMO, the thing you are describing is more of an in-editor sculpting/modeling tool for level prototyping which is not a traditional heightmap terrain editor and I have doubts that it is used in large-scale terrain creation. I might be wrong but I think it is probably used to alter already exported mesh objects in engine. But those tools usually differ from terrain creation and I think they could be implemented as separate modeling\mesh editing tools in engine.

I guess it's a great tool, but for terrain editor, at initial stages, I think it would be wiser to replicate at some level or just natively rewrite Zyllan's plugin functionality and stick to it's workflow that many Godot users already acquainted with and then add more and more functionality, like seamless terrain stitching, separating it in chunks and etc.

[wareya]

And I believe height-maps not just store information perpendicular from the quad, as you describe, they can store info in all axes as far as I know, I might be wrong though

It's very common to pick up a particular random heightmap system and have it only support perpendicular displacement. There are heightmap systems that work as you describe, though, with three total channels of positional information.

Also, by looking at the image you have provided it looks like the heightmap applied to a mesh object so that the user could sculpt details in editor? This feature is different from the usual terrain editor though, IMO.

They're not mesh objects, they're "brushes". More similar to godot's CSG geometry nodes. But yes, they're created and applied and sculpted in-editor as well.

It's a neat feature, but it's not the same thing as a usual heightmap terrain editor you would expect in game engines (at least the ones that start on U letter).

In terms of functionality it's equivalent to a very advanced heightmap system. I'm bringing it up because a lot of people are only aware of very weak/simple heightmap systems.

Also, I am curious how it's implemented in Hammer, does it have an LOD system, how scalable it is? Does it decrease mesh detail resolution depending on camera position and etc?

Source 1 doesn't do LOD to displacements or other level geometry primitives, but there's nothing in theory stopping from an implementation from generating LODs for them. At least on a per-group basis. Source does have LODs for actual models though.

IMO, the thing you are describing is more of an in-editor sculpting/modeling tool for level prototyping which is not a traditional heightmap terrain editor and I have doubts that it is used in large-scale terrain creation.

This feature is used for level-final details in almost every source engine game, including non-terrain details like a lot of the building details in CSGO's version of dust2, but yes, also large swathes of flat mere terrain.

I might be wrong but I think it is probably used to alter already exported mesh objects in engine.

This is not the case. Everything is created entirely in the level editor. It looks like this if I disable displacement rendering. I am speaking from a place of experience with source engine level design and not leaving anything out or misrepresenting anything.

[MeshVoid]

Thank you for screenshots, they clarify a lot of things. It's a neat tool to have, IMO for level editing that could be probably integrated into Godot's existing CSG geometry nodes themselves. Personally, I would like to have it, but it's not a dedicated terrain editor, though. And I would argue that it's some sort of different approach on making things happen when it comes to terrain creation.

I just read a bit more about displacement and height-maps, again I might be wrong, but it seems to me that it's actually the same thing and the same method, the term height-maps is just more commonly used in the context of terrain creation, and the term displacement maps is more commonly used when we deal with the displacement of any type of mesh, hence the tool name in Hammer editor, I guess.

Also, I don't think it's a huge issue to create overhangs as separate mesh instances and have a separate height-map terrain, IMO that would look visually better and way more natural than geometry extruding from the ground, but that's just me though. And if the graphics are heavily stylized and overhangs like that are a must, then why not go with voxel terrain then, it would suit that kind of style way better?

When we talk about a heightmap terrain editor as a user, personally I would want to see in-engine tools that would help me quickly create huge terrains, not just a single square node, but allow me to add and substract parts of terrain in "chunks", have manageable performance, have some sort of basic automated "streaming" for parts of terrain, foliage, meshes placed on the terrain.

[wareya]

It's a neat tool to have, IMO for level editing that could be probably integrated into Godot's existing CSG geometry nodes themselves.

Actually, yeah, that's a pretty good point. Their purpose is already pretty similar. Maybe there could be some kind of CSGDeformed node or something, or a tool for sculpting CSGMesh nodes.

I just read a bit more about displacement and height-maps, again I might be wrong, but it seems to me that it's actually the same thing and the same method,

That is correct. Hammer's displacements are equivalent to an advanced heightmap system. I brought them up because a lot of people only know about very simple heightmap systems, and think that heightmap systems cannot do the things for terrain that voxels can do (e.g. overhangs, polygon-dense cliffs, etc).

Also, I don't think it's a huge issue to create overhangs as separate mesh instances and have a separate height-map terrain, IMO that would look visually better and way more natural than geometry extruding from the ground, but that's just me though.

The "normal" way to do overhangs and cliffs in Hammer is to have a horizontal displacement meet up with and stitch to a vertical displacement. This allows them to line up perfectly, not just stick out through the ground, and if you're using materials that support vertex attribute painting, you can make a graphically blended transition as well. Small bits of terrain like hoodoos sometimes just stick out though, same idea as mesh instances like you said.

And if the graphics are heavily stylized and overhangs like that are a must, then why not go with voxel terrain then, it would suit that kind of style way better?

Overhangs and cliffs are not a weird style thing, they're extremely common in terrain-heavy design across all kinds of genres. Like, cave entrances are both cliffs and overhangs, for example.

Smooth voxels are good, but they're a lot more painful to implement in a flexible way. You have to worry about memory usage, control over triplanar mapping, meshing bugs, being unable to micro-adjust individual vertices, where and whether you're able to create sharp seams instead of round edges, etc. The concept is simpler than being able to stitch arbitrarily-sized-and-placed heightmaps together willy nillly, yes, but there are a lot of drawbacks to smooth voxels that aren't immediately obvious until you sit down and use them for environment design.

Of course, doing large, sweeping edits to smooth voxel terrain is a lot easier than doing it to a bunch of random chopped-up heightmaps. I'm just posting because people often think that there are things you can do with smooth voxels that you can't do with heightmaps, when in reality it's the other way around: sufficiently powerful heightmap systems are strictly more powerful/flexible than smooth voxel terrain; you just pay a learning/complexity cost.

When we talk about a heightmap terrain editor as a user, personally I would want to see in-engine tools that would help me quickly create huge terrains, not just a single square node, but allow me to add and substract parts of terrain in "chunks", have manageable performance, have some sort of basic automated "streaming" for parts of terrain, foliage, meshes placed on the terrain.

These are good things to want. I agree 100%.

[Calinou]

I was thinking about allowing PlaneMesh to have per-vertex offsets. Could this exposed as two CurveTextureXYZ properties that are edited via a custom 3D editor gizmo? The CurveTextureXYZ properties would affect the position of each vertex axis over the plane's width and height respectively.

Using a CurveTextureXYZ resource allows for resizing the number of vertices on each plane's dimension without breaking the intended geometry's shape, effectively acting as a quality slider.

That said, for this to be usable as a basic terrain solution, we'd need a built-in splatmapping shader (and vertex color painting tools as well, working at least on this PlaneMesh).

[ultramarinebicycle]

I'm sorry I thought Zylann's plugin already supported loading chunks and subdividing them in real time?

[MeshVoid]

That depends on what you are calling chunks. Yes, Zyllan's plugin is subdividing the single terrain node you create in real time, it has certain levels of optimization, but what I am referring to by "chunks" is the separate parts\clusters of the terrain that you can add and subtract (Probably I'm not using the correct terminology here). As of now it's okay if you have a small level with one terrain node, but you will find it difficult to create big seamless levels when you will need to separate them into several parts.

For example, If you want to create a huge terrain which is separated into several chunks using Zyllan's plugin (say you have a huge terrain of 10x10 km and every "chunk" is 1x1 km), you will have to create a separate node for every part of the terrain, you cannot add or subtract seamlessly any at the moment, and sometimes you might experience problems with "seamlessly stitching" the said terrain as you might want to make edits to your terrain in editor.

As of now, when you are working with large terrains and using Zyllan's plugin in Godot your best strategy would be to use an external software like World Creator or Gaea or any other tool and export several height-maps and preferably splat-maps to quickly apply terrain texture sets, you will have to create Hterrain node for each exported height-map and then apply height-map for each node and manually place them in editor. Also you will have to write your own solution to load only the part of the terrain depending on the position of your player.

It seems that Zyllan's heightmap plugin author knows about this limitation and planned to implement the above mentioned functionality and called it "sector streaming". Also the problem of terrain stitching mentioned here.

[azur-wolve]

IMO what Godot needs right now is a built-in workflow solution for level design.
Such should cover the most fundamental/common operations while developing world levels in the Godot Editor.
It would need:

• various new Node types
• a couple of new Resource types (maybe)
• some kind of in-editor GUI designed for improve workflow

(the context of the whole post suggests me that it is focused on 3D, but keep in mind that 2D games can also benefit from height-maps; isometric and maybe others)

Here some ideas:

1. World Organization

A) grid-based → a Node that hold a Tree of 3D matrices, it would be handy to handle large worlds.

i.e: the highest level being 3x3 organizing the whole world, global stuff, etc;
an intermediate level that subdivides every previous cell into another 3x3 that can be used to divide certain "region specific stuff";
then the "immediate grid level" that splits the world where the player moves, the surrounding cells could be LODs. Such would be the CellNode.
It also could include another level with 32x32 used for things like calculate NPC movement and things like that;
the core idea here is a hierarchy tree of 3D matrices, where the user would specify where the amount hierarchy-levels and cells.
The matrices are the containers; the chunks are the actual terrain, on the most lower level of the hierarchy; the previous matrix levels would be to handle logic and organize the world.
Such kind of structure allows for the use of acceleration data structures. Also allows to load Nodes and Resources on-demand.

[notice that the way the world splits also involves game-logic, it could enforce good practices and well tested solutions]

B) sector-based → a Node that would hold an irregular set of SectorNodes, ideal for non-openworld games, or games that happen in interiors/"non-open spaces".
Those would be basically connected blocks of varied sizes, those could be quadrangular or other non-complex shapes, like the areas and (portal)rooms.
It would allow too to combine with grid-based stuff to include parts of the world that are more open, without loading screens.

Problems with world chunks:

• being the whole world visible at one in the editor could hit performance during development (being optimizations and such not yet implemented) Solution: A property in the Node that organizes the whole world to toggle visibility of all chunks, so you could be able to enable/disable all at once, without hide-show 1-by-1 manually in the Node panel, only using it to see specific chunks or groups of chunks.

• the aforementioned problem of terrain stitching; when subtract a chunk, the vertices that where connected with the vertices of the subtracted chunk (on the seam boundaries) will break, creating mesh artifacts.

• the current coordinate system (due to optimization reasons) uses 32-bit floats. This means that reached certain distance from the origin, inaccuracy problems can start.
  [After you go past ±4096 units, you only have 0.001 of precision, meaning that increments smaller than 0.001 unit cannot be represented anymore. This is why it's recommended to keep gameplay in a 8192×8192×8192 area centered around the world origin. Background scenery can go outside this limit.]

Other capabilities:

• ability to subtract, insert/add, copy-paste, duplicate world chunks

• support for both: voxels (cube-based) & height-maps (vertex-based)

• automated load-unload of chunks following a certain config

• supporting a LOD workflow for neighbor chunks

• a tool for fast level prototyping based on face extrusion (combined with grid snap)

• automatic generation of collision shapes + a good tool to create them manually and easily

• ability to generate meshes based on a specific collision shape

[Zireael07]

How does B) differ from Rooms and Portals?

EDIT: For face extrusion, look up this: https://github.com/jarneson/godot-ply

[azur-wolve]

B) would be a node that arranges/organizes child nodes that are basically "map_chunks"

Rooms & Portals are only for culling, they've not map geometry and other entities attached to them (afaik)