Add a mesh-based 3D level design tool

[MonkePleb]

Describe the project you are working on A 2D platformer although it's irrelevant to the feature I'm proposing.

Describe the problem or limitation you are having in your project It takes game devs longer to create levels since there isn't a tool like Unity's Pro Builder in Godot.

Describe the feature / enhancement and how it helps to overcome the problem or limitation Game devs trying to create levels for a 3D game would have a much easier time with a quick and easy to use tool that's like Pro Builder.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams I don't know as I am new to game dev. I'm currently working on my first ever game (it's a 2D game), but I noticed how there wasn't a tool like Pro Builder implemented into Godot yet.

If this enhancement will not be used often, can it be worked around with a few lines of script? Probably not.

Is there a reason why this should be core and not an add-on in the asset library? It should be core because it'll speed up development time for all devs working in 3D. It would especially be useful for FPS games because then levels could be created quicker. Overall, it would greatly enhance the engine and could make it a more appealing engine to new game devs who may otherwise automatically choose to use Unity.

[timothyqiu]

Maybe you can try the CSG* nodes for quick prototyping.

[Calinou]

See Prototyping levels with CSG in the documentation.

Maybe you can try the CSG* nodes for quick prototyping.

Unfortunately, CSG nodes have pretty bad usability when it comes to prototyping, and they're too limited to be usable in production (lack of texturing/UV layout tools).

My recommendation is to use Qodot instead of CSG nodes, but it requires using an external tool (TrenchBroom). It's good for production, but not as fast as CSG nodes could be (with better UX) during prototyping.

That said, creating a 3D level editing tool is a massive task which would likely have to be handled by someone working full-time on it. For reference, TrenchBroom has been in development for almost a decade now, and is only starting to see use outside of Quake since 2019 or so.

[gaudecker]

I agree with @Calinou that creating a full-blown level editing tool requires a lot of work, but I don't think we have to go that far (not yet anyway).

What we have now with the CSG nodes is pretty damn close. What we're missing are basic editing ergonomics, texturing options, and optimization.

Ergonomics

• Add gizmo for moving/resizing CSG node faces, similiar to what is described in proposal #452. This alone would massively improve UX.

Texturing

• Allow different materials for individual faces, as described in proposal #937
• Simple tools for adjusting UV translation, rotation, and scale of each face. (also discussed in proposal #937)

Optimization

• A CSGCombiner3D mode that won't perform any CSG operations on its children. Most of my grayboxing consists of making non-overlapping boxes that do not require any CSG operations (this is basically a Node3D with bunch of static bodies, but with added ergonomics of the CSG nodes, like easier resizing and collision).
• Add a "bake" button for generating single, or multiple mesh instances from a CSG tree.

---

With these relatively simple additions alone, Godot would have a formidable toolset for prototyping levels (and even making production levels).

[Zireael07]

https://github.com/jarneson/godot-ply wasn't around when this proposal was made and it seems to cover most of it.

"Bake from CSG" button functionality is still not a thing, but this simple script does the trick:

extends CSGShape

func _ready(): _update_shape() var msh = get_meshes() ResourceSaver.save("res://mesh.tres",msh[1])

[Calinou]

Another optimization that can be done is to use a debounce delay (e.g. 0.1 second) before updating the CSG mesh. This would ensure the editor always remains responsive while dragging CSG nodes around, even in complex CSG trees. This delay would be adjustable in the project settings if needed, but I think 0.1 second would be a sensible default.

A CSGCombiner3D mode that won't perform any CSG operations on its children. Most of my grayboxing consists of making non-overlapping boxes that do not require any CSG operations (this is basically a Node3D with bunch of static bodies, but with added ergonomics of the CSG nodes, like easier resizing and collision).

While this sounds interesting on paper, this might cause additional confusion in the already complex CSG node system (in my opinion).

Instead, shouldn't we enable collision generation by default on all CSG nodes? For level prototyping, you'll want most of your CSG nodes to have static collision.

Add a "bake" button for generating single, or multiple mesh instances from a CSG tree.

See https://github.com/godotengine/godot-proposals/issues/182.

[gaudecker]

Instead, shouldn't we enable collision generation by default on all CSG nodes? For level prototyping, you'll want most of your CSG nodes to have static collision.

Much better, then you can just dump the nodes inside a Node3D and call it a day!

[Calinou]

Sometimes, I wonder if we should do away with CSGBox and CSGCylinder and just make them pre-into configured CSGPolygons (which can be regenerated at any time when desired). This would require allowing for each face to have its own material, but faces that share the same material should not result in a material change to improve performance. One big upside of this approach is that you would no longer be constrained to a "perfect" box or cylinder: you could move vertices around as needed (within the limits of an extruded 2D polygon).

This could also be done for CSGSphere and CSGTorus by using the appropriate Spin modes in CSGPolygon. That said, it won't allow you to drag vertices individually – support for this would require allowing CSGPolygon to be used for proper 3D polygons, rather than just extruded 2D polygons.

[Zireael07]

@Calinou: Good idea, but maybe let's not keep piling new features/reworks to 4.0? :P