Improved 3D map creation tools (similar to the Hammer++ editor)

[Gamepro5]

Here's a video explaining why Godot needs a better editor workflow for creating maps. Something similar to the Hammer++ editor (an improved version Valve's original Source 2013 hammer editor, which is an upgraded version of trenchroom) would be nice, with a built in terrain editor. 2D could also use something similar, because right now the best thing both can do is gridmaps or tilemaps. These are good for modular levels or dungeon crawlers, but not great if you want to make a complex 3d level.

Hammer++ features include:

• Foliage painting
• Mesh extruder (also called a vertex tool)
• Collision shapes built in
• "baked" physics simulations
• Displacements
• Terrain editing
• Slicing and merging (merging helps performance, so you don't have random faces that can't be seen)
• Way more listed on their website that godot can't really come close to doing as cleanly.

Here's a proposal for a built in terrain editor, which would be part of this theoretical improved "godot hammer editor" tool

Proposal created at the request of @rburing

[rburing]

Let me try to summarize the problems related to map creation identified in your video(s), apart from the missing features you listed:

1. Having a static body + mesh instance + collision shape(s) is a lot of nodes for (what is often) one task, making iteration tedious.
2. When you edit a primitive mesh (not imported), collision shapes have to be manually re-generated to fit the mesh.
3. The editing of primitive collision shapes is inconvenient, especially extruding from the center in two directions at once.
4. The CSG nodes avoid problems (1) and (2), but their other limitations make them mainly suitable for prototyping only.
5. To scale an imported mesh and generate proper collision shapes for it, the scale currently has to be applied on import.
6. The editor allows scaling of bodies and collision shapes in (non-uniform) ways which are not supported by the physics engine.
7. When importing a model consisting of multiple meshes, collision shapes have to be generated for all parts, or one for all.

Some thoughts on what could/can be done:

• We could imagine a custom node that inherits from MeshInstance3D and generates appropriate collision shapes at runtime (for prototyping), and allows "baking" the collision when prototyping is done. (This should already be easily doable with a plugin.)
• Primitive collision shapes (and CSG) could allow more convenient editing like Improve editing of box collision shapes godot#71092 (but also allow the previous behavior).
• We could imagine a workflow of prototyping with CSG, and then exporting CSG and later importing, or staying in the editor and "baking" the CSG to meshes and/or collision shapes (not necessarily only trimesh collision shapes).
• Warn against using non-uniform scale for 3D physics (in the editor and class reference) godot#67847 could be added.
• We could imagine a node-based advanced importer, allowing merging of meshes and generating collision shapes.
• Mesh editing in the editor can currently be done with a plugin like godot-ply.
• Decorating a map with assets can currently be done with a plugin like Scatter.
• For terrain editing, adding basic tools to edit the current heightmap shape would already go a long way, for many use cases.

[Calinou]

For terrain editing, adding basic tools to edit the current heightmap shape would already go a long way, for many use cases.

There would also need to be an associated HeightmapMesh primitive mesh, so that the heightmap shape can have a visual representation. But then, you'd also need vertex painting tools and a built-in splatmap shader material…

[9Ginseng]

I think this is a very important discussion! good mapping tools always seem to be overlooked, having a good mapping tool is what made the old school engines such as QuakeEngine, GoldSrc and Source Engine so popular and lead to the great, still active communities surrounding games created in those engines.

To get some more insight, I think this is a great video about this topic from a pro level designer:
https://youtu.be/-T73pq9YcOE

This is also a great thread about the tools that Source 2 comes with:
https://twitter.com/joewintergreen/status/1262662025903128576

TrenchBroom 2 trailer: (something like this within Godot would be a godsent)
https://youtu.be/shcAvnYp9ow

I really think that Godot could attract a very large audience of level designers if this gets more focus, level designers are starving!
I keep seeing people who are interested level design trying out Unreal Engine and Unity only to return to GoldSrc/Source Engine simply because of the ease of use, being able to load up a tool with simple yet effective mapping tools where you can quickly put something together and then drop that map file in to a game folder, then load it up in-game should not be underestimated!

[Calinou]

TrenchBroom 2 trailer: (something like this within Godot would be a godsent)

Qodot (for Godot 3.x) or godot-tbloader (for Godot 4.x) might be just what you need 🙂

There are surely ways to improve TrenchBroom to be more usable from a Godot user's perspective. Things like real-time lighting feedback are a long way away, but technically not impossible. The hardest part would likely be convincing Quake mappers¹ to try it, as real-time lighting will look quite different from actual baked lightmaps (at least when using modern map compiling tools).

Footnotes

1. TrenchBroom's intended audience – using it for non-Quake engine-based games is considered a byproduct, not its focus of development. ↩

[9Ginseng]

Those are great plugins to use for now! TrenchBroom 2 is obviously very limited as a result of it being made for quake engine games, I think that trailer is a good show of what mapping tools should be capable of and ease of use, having similar tools directly within Godot would be really good for 3d game development, something that Godot 4 seems to be a lot more focused on with all of its graphical improvements.

There are quite a few plugins for Godot that focus on importing maps from Quake, GoldSrc, Source Engine and their different mapping tools, such plugins exist for Unity and Unreal as well. These plugins exist, not because these tools in particular are great, but because modern game engines do not have ANY built in tools for easy level design at all, but they are desperately needed.

That's why I'm saying that Godot should really consider implementing such tools directly in to the engine, as that would give a very strong reason to choose Godot for game dev over Unity or Unreal, as for both of those engines I see constant complaints about the lack of quick and easy level design tools.

TL;DR: using plugins to import maps from ancient game engines is not a solution to the problem.

I appreciate it Calinou! Reading this now kind of make it seem like I'm upset with your reply when really you just gave me a good excuse to add some thoughts as well as clarify my stance on the matter. Godot-tbloader is probably what I will use for now, so thank you for pointing that out to me! 😃

[Calinou]

There's a Godot 4 add-on for level design, but I haven't tested it: https://github.com/jarneson/godot-ply

[9Ginseng]

Thanks again! That seems very nice, will definitely try it out!

[Sugarteeth]

This really ought to have been a main feature from the beginning, it's like putting the cart before the horse. As someone who's come from an environment that mainly used Hammer++, it's been a struggle adapting to Godot's alarmingly barren & lackluster in-engine 3D level/world creation options. I rewrote this post several times to be more polite and less emotionally charged, as it's been quite a recent discovery for me.

2D mapping gets all the love & attention, and that's made Godot one of the best options for 2D games right now. Tilemapping has gotten way better, there's great support for in-engine level/world creation for 2D. But the 3D side... yikes. This might sound mean, but I legitimately think any 3D game made in godot is only good in spite of the engine, not because of it.

[Calinou]

@TrainzMarcel Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.