Per Face Materials for CSG

[ElfEars]

CSG is mostly intended to be a blocking tool and the ability to add different materials to each face helps keep track of what is intended to be on the final geometry without needing to create several separate brushes thus adding more overhead while playtesting.

It also makes it easier to add in a level editor for players and as with the CSG system as a whole I’m sure plenty of people would end up using it for final geometry.

[Calinou]

While this isn't currently possible with only a single brush, you can use a subtractive brush that overlaps with an additive brush. The faces that are being "dug" into will use the material of the subtractive brush.

[ElfEars]

While that would work I still think it's kind of a clunky and inefficient solution. Thanks for the suggestion though!

[NewNodeGames]

This feature and a paint mode is what CSG needs to be a very powerful tool.

[Byzantian]

I'm working on Hammer editor style easy CSG placement / manipulation. Implementing per face materials is on my bucket list (including UV offset mainpulation, etc). Creating 3D levels entirely in CSG would be great for indie developers like myself who aren't that good with blender.

[Wavesonics]

@Byzantian man that would be awesome, any progress to share?

[drequivalent]

@Byzantian I concur. Can we see anything of it yet? This is the single thing Godot needs, a lot.

[Calinou]

@drequivalent You're probably looking for Qodot at this point :slightly_smiling_face:

[drequivalent]

@Calinou I love Trenchbroom (and Sketch-Up, by which TB was clearly inspired), and Qodot is a nice idea, but it's still a crutch. I'd prefer the same fast and precise workflow directly inside Godot's main editor. Natively, if you will.

[drequivalent]

And by the way, Godot's CSG has one very important advantage - it's dynamic! No recompilation required! Make it quick and convenient to manipulate and work with by learning the lessons from other editors - and Godot's gonna be way ahead of everything leveldesign-wise.

That's my take on this, anyway.

[ElfEars]

It's also worth mentioning that Qodot had to re-implement all the CSG operations (or rather, link to libmap which was originally created for the qodot project) themselves as all the current CSG classes in godot only store a single material variable with no other material application data. It's one of those awkward DRY violations you gotta make when you want to "cleanly" mod a codebase like this.

There's also some bubblings about the CSG nodes being able to export a final static mesh which makes texturing all the more valuable seeing as the CSG maps will have far better performance when it's implemented.

As for @Byzantian . I should probably have mentioned this earlier but he discontinued development ages ago due to Godot not adopting C++ 17 (or possibly C++ 20) yet.

[Wavesonics]

@ElfEars well the good news is master is now on C++17 :P

[clayjohn]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!