Agreed! I used it to build the maps for my 13kb Quake demake[1]. Compared to q3radiant that I used back in the day, Trenchbroom is just so much more pleasant to work with. In hindsight it seems totally obvious that _this_ is the way a map editor should work.
func_godot works better than I expected it to the first time I used it, properly imports and compiles triggers, lights, materials, sounds, etc straight from trenchbroom so you really can do 90% of your work in trenchbroom. It's awesome for prototyping!
It's great when you have it set up but there's so a fairly gnarly amount of ritual magic needed to set it up. I kinda wish it was first part integration, especially given the extremely lackluster 3D level editing abilities of Godot itself.
Godot feels very much held back by how much stuff you need to do in 3rd party apps with flakey or nonexistent integration. Software developers often get shit for the learning curve of IDEs, but nothing has the "damn girl, you live like this?" energy as open source gamedev tooling. Even something pretty basic like doing texture painting in Blender? Jesus H. Christ. Makes The GIMP seem more polished than anything Apple put out at the peak of its polished days.
> I grew up using Hammer and this simply blows it out of the water.
Strange to read "I grew up using Hammer." when I still see Hammer as a newfangled update to Worldcraft.
No Quake map editor will let you do anything the Quake engine can't, of course.
If you draw your maps on paper first, as id Software did[0], then the editor you use doesn't matter so much.
J.A.C.K.[1] is the current torchbearer for the Hammer lineage.
Also there is a community fork of Trenchbroom[2] that exists because Trenchbroom includes slop. Or "machine generated code" or "wAIfu generated code" or however salves your feelings.
TrenchBroom is great. I am the maintainer for Neverball (which is incidentally one of the games that does still use the old style texture projection). TrenchBroom was the first Quake editor that already had a functional Neverball gamepack without me having to do a thing.
It is neat all of these years later to see Qt pop up now and then, just chugging along with comments from users like the author saying "Yep, that was worth it.". Just doing its thing getting out of the way and letting users build what they want to do.
Cool article, never knew the actual history of how Trenchbroom got started! Have been using it very casually over the last decade or so. There are some incredible Quake mappers out there making things that would make your jaw drop if you haven't seen Quake in quite a while.
For example, Arcane Dimensions[0] or the Quake Brutalist Jam[1]
Anyone looking to get into single player Quake should grab an engine like IronWail and just go through all three Brutalist Jams. These are essentially map packs with contributions from various mappers, linked by a museum like base map (as many jams do). Each successive Brutalist Jam pushes the boundaries of what a thirty year old base game can still do.
Trenchbroom is very good, but I still think, it's not the best possible map editor. It uses brush-based approach, which isn't the right way of designing maps for games in closed spaces (like Quake). Creating each room requires creating at least 6 brushes for its walls/floor/ceiling, which is way to much for such stuff. On the other hand Unreal Editor (for first Unreal and Unreal Tournament) supports creating rooms directly (as subtractive brushes), when two room primitive touch each other, they are automatically connected.
Back in the day I made a lot of Quake 3 and Unreal Tournament maps. The Unreal Editor was a lot buggier than Radiant but the workflow was far superior. You could bang out a floor plan quite fast with the subtractive approach. No caulk textures to deal with either (a special texture that the renderer ignored for the sides of the boxes used to create the walls that the player never sees).
I tried both and both are interesting. Conceptually the brush approach seems more intuitive for some types of maps. Like making a few rooms that come out into an open space or some oddly shapped stuff like pyramid rooms, etc. I dunno, both are interesting and once you got used to the approach, the additive system works pretty well.
The unreal method and the quake one are almost exactly the same technically. The level has to be watertight, no leaks from the inside out, even outside areas are actually inside. I suspect for the previs set calculation to work correctly. The editors were both csg brush based and compiled to similar bsp data structures. But in one of those strokes of brilliance where the problem is inverted, the unreal editor devs said "if we start from a solid world and you subtract the rooms you want then you can never have a leaky level" goofy as hell compared to how you think about building things, but it generally worked.
Note, that I never mapped much, but my standard approach was generally to cut a few large rooms out in the general shape of the map(because despite the clever opening if you got too ambitious too quick unreal absolutely would leak like a sieve) then use a mix of add and subtract brushes to make the fine geometry, which was exactly the same as quake maps, large simple rooms to avoid leaks(this time needing to be assembled) filled with fine geometry via adds/subtracts.
This is sort of the early id, Epic engines in a nutshell, id better technically, Epic better tooling and ergonomics.
And a footnote on brushes, because I did not understand this until long after I stopped mapping, A "brush" is a 3d primitive unique from the point,face one commonly used in 3d modeling software. A brush is defined as the convex shape made from intersecting planes. So where for a point,face model you define where the points are and which points form a face, for a brush you define where the face is(point, normal) and what faces are in the brush, the shape comes out of how they intersect. I assume this was because for large simple geometry that you are going to be doing csg operations on the plane model is more attractive than the point model.
I know nothing about this scene, but interested to know more. I remember hearing that Unreal Tournaments engine used this subtractive model internally so it is not strictly editor ux decision?
I don't know what Unreal Tournament did use internally, it's hard to investigate, since there is no (official) source code release for it. But I do know, that brush-based (additive) approach isn't strictly necessary for creating maps for Quake/Quake II/Quake III, it's technically possible to write a map compiler taking maps in some subtractive format. The reason why it's not done (or at least not common) is because it's not a trivial task and because existing infrastructure adds some friction.
I remember back when I was heavily into making Doom 2 maps, I had a sort of Tetris effect where I started seeing real world building interiors as the sectors and textures that I could use to recreate the building in Doom.
I tried Quake map making, but the 3D tools were too complex for young me to figure out, also my PC was too slow to use them.
Happy to see Trenchbroom love :) I made a high school project using it with Godot and it was such a breeze even as someone who had never done Quake / HL / Source mapping before.
I am working on a new project and looked at both TrenchBroom and NetRadiant. Neither of them were very usable for me. I am familiar with old and new UnrealEd so I ended up using that since it is a free download now with the OldUnreal release.
Trenchbroom is legitimately among the best software I have ever used. I grew up using Hammer and this simply blows it out of the water.
One nice thing is that you can use it as a level editor for your own games in Godot with func_godot
Agreed! I used it to build the maps for my 13kb Quake demake[1]. Compared to q3radiant that I used back in the day, Trenchbroom is just so much more pleasant to work with. In hindsight it seems totally obvious that _this_ is the way a map editor should work.
[1] https://phoboslab.org/log/2021/09/q1k3-making-of
Interesting, and cool project by the way!
func_godot works better than I expected it to the first time I used it, properly imports and compiles triggers, lights, materials, sounds, etc straight from trenchbroom so you really can do 90% of your work in trenchbroom. It's awesome for prototyping!
It's great when you have it set up but there's so a fairly gnarly amount of ritual magic needed to set it up. I kinda wish it was first part integration, especially given the extremely lackluster 3D level editing abilities of Godot itself.
Godot feels very much held back by how much stuff you need to do in 3rd party apps with flakey or nonexistent integration. Software developers often get shit for the learning curve of IDEs, but nothing has the "damn girl, you live like this?" energy as open source gamedev tooling. Even something pretty basic like doing texture painting in Blender? Jesus H. Christ. Makes The GIMP seem more polished than anything Apple put out at the peak of its polished days.
> I grew up using Hammer and this simply blows it out of the water.
Strange to read "I grew up using Hammer." when I still see Hammer as a newfangled update to Worldcraft.
No Quake map editor will let you do anything the Quake engine can't, of course.
If you draw your maps on paper first, as id Software did[0], then the editor you use doesn't matter so much.
J.A.C.K.[1] is the current torchbearer for the Hammer lineage.
Also there is a community fork of Trenchbroom[2] that exists because Trenchbroom includes slop. Or "machine generated code" or "wAIfu generated code" or however salves your feelings.
"The map editor everybody uses" is reductionist.
[0] https://xxcancel.com/romero/status/643540836072992768
[1] https://jack.hlfx.ru/en/
[2] https://codeberg.org/NextBroomTeam/NextBroom
TrenchBroom is great. I am the maintainer for Neverball (which is incidentally one of the games that does still use the old style texture projection). TrenchBroom was the first Quake editor that already had a functional Neverball gamepack without me having to do a thing.
It is neat all of these years later to see Qt pop up now and then, just chugging along with comments from users like the author saying "Yep, that was worth it.". Just doing its thing getting out of the way and letting users build what they want to do.
Cool article, never knew the actual history of how Trenchbroom got started! Have been using it very casually over the last decade or so. There are some incredible Quake mappers out there making things that would make your jaw drop if you haven't seen Quake in quite a while.
For example, Arcane Dimensions[0] or the Quake Brutalist Jam[1]
[0] https://www.moddb.com/mods/arcane-dimensions
[1] https://www.youtube.com/watch?v=vquTPCYbOxk
Anyone looking to get into single player Quake should grab an engine like IronWail and just go through all three Brutalist Jams. These are essentially map packs with contributions from various mappers, linked by a museum like base map (as many jams do). Each successive Brutalist Jam pushes the boundaries of what a thirty year old base game can still do.
Trenchbroom is very good, but I still think, it's not the best possible map editor. It uses brush-based approach, which isn't the right way of designing maps for games in closed spaces (like Quake). Creating each room requires creating at least 6 brushes for its walls/floor/ceiling, which is way to much for such stuff. On the other hand Unreal Editor (for first Unreal and Unreal Tournament) supports creating rooms directly (as subtractive brushes), when two room primitive touch each other, they are automatically connected.
Back in the day I made a lot of Quake 3 and Unreal Tournament maps. The Unreal Editor was a lot buggier than Radiant but the workflow was far superior. You could bang out a floor plan quite fast with the subtractive approach. No caulk textures to deal with either (a special texture that the renderer ignored for the sides of the boxes used to create the walls that the player never sees).
I tried both and both are interesting. Conceptually the brush approach seems more intuitive for some types of maps. Like making a few rooms that come out into an open space or some oddly shapped stuff like pyramid rooms, etc. I dunno, both are interesting and once you got used to the approach, the additive system works pretty well.
The unreal method and the quake one are almost exactly the same technically. The level has to be watertight, no leaks from the inside out, even outside areas are actually inside. I suspect for the previs set calculation to work correctly. The editors were both csg brush based and compiled to similar bsp data structures. But in one of those strokes of brilliance where the problem is inverted, the unreal editor devs said "if we start from a solid world and you subtract the rooms you want then you can never have a leaky level" goofy as hell compared to how you think about building things, but it generally worked.
Note, that I never mapped much, but my standard approach was generally to cut a few large rooms out in the general shape of the map(because despite the clever opening if you got too ambitious too quick unreal absolutely would leak like a sieve) then use a mix of add and subtract brushes to make the fine geometry, which was exactly the same as quake maps, large simple rooms to avoid leaks(this time needing to be assembled) filled with fine geometry via adds/subtracts.
This is sort of the early id, Epic engines in a nutshell, id better technically, Epic better tooling and ergonomics.
And a footnote on brushes, because I did not understand this until long after I stopped mapping, A "brush" is a 3d primitive unique from the point,face one commonly used in 3d modeling software. A brush is defined as the convex shape made from intersecting planes. So where for a point,face model you define where the points are and which points form a face, for a brush you define where the face is(point, normal) and what faces are in the brush, the shape comes out of how they intersect. I assume this was because for large simple geometry that you are going to be doing csg operations on the plane model is more attractive than the point model.
I know nothing about this scene, but interested to know more. I remember hearing that Unreal Tournaments engine used this subtractive model internally so it is not strictly editor ux decision?
I don't know what Unreal Tournament did use internally, it's hard to investigate, since there is no (official) source code release for it. But I do know, that brush-based (additive) approach isn't strictly necessary for creating maps for Quake/Quake II/Quake III, it's technically possible to write a map compiler taking maps in some subtractive format. The reason why it's not done (or at least not common) is because it's not a trivial task and because existing infrastructure adds some friction.
Couldn't this be solved by "map compilation"? IIRC, Hammer etc. did something like that. Occluded faces were removed.
Trenchbroom is excellent and fun. Many game devs use it to block out levels or make entire games.
Trenchboom is great!
Shameless plug but I ended up making this q3 map using a custom Trenchboom MCP:
https://sajarin.com/q3inc
I remember back when I was heavily into making Doom 2 maps, I had a sort of Tetris effect where I started seeing real world building interiors as the sectors and textures that I could use to recreate the building in Doom.
I tried Quake map making, but the 3D tools were too complex for young me to figure out, also my PC was too slow to use them.
Happy to see Trenchbroom love :) I made a high school project using it with Godot and it was such a breeze even as someone who had never done Quake / HL / Source mapping before.
I am working on a new project and looked at both TrenchBroom and NetRadiant. Neither of them were very usable for me. I am familiar with old and new UnrealEd so I ended up using that since it is a free download now with the OldUnreal release.
Anyone remember Qoole? It's the editor I grew up on and truly loved.
I never mapped much(more curiosity than real interest) but when I did qoole was always my first choice.
If I remember correctly, it had better csg and a neat method to link planes so they would texture as one surface.
Everybody? I was editing quake 2 maps in 1998 and not using this. ;)