News | Forum | People | FAQ | Links | Search | Register | Log in
The TrenchBroom Level Editor
Today I am releasing TrenchBroom 1.0 for Windows and Mac OS X. TrenchBroom is a modern cross-platform level editor for Quake.

Features
- True 3D editing, no 2D views required
- High performance renderer with support for huge maps
- Vertex editing with edge and face splitting
- Manipulation of multiple vertices at once (great for trisoup editing)
- Smart clip tool
- Move, rotate and flip brushes and entities
- Precise texture lock for all operations
- Smart entity property editors
- Graphical entity browser with drag and drop support
- Comprehensive texture application and manipulation tools
- Search and filter functions
- Unlimited undo and redo
- Point file support
- Automatic backup
- Support for .def and .fdg files, mods and multiple wad files
- Free (as in beer) and open source (GPLv3)
- Cross platform (Windows, Mac OS X and Linux supported)

Check out a video of TrenchBroom in action here.

You can download the editor here.

If you would like to give feedback, please do that in this thread. If you find a bug or have a feature suggestion, please submit them at the issue tracker.

If you are wondering where the Linux binaries are then sorry, but currently there are none. The Linux version has a few problems which I could not fix before this release. I will get working on those right away so that the Linux version should be available in a couple of weeks, too.

Finally, I would like to thank necros for all his work over the past year. Without his tireless efforts, TrenchBroom would simply not exist. Or it would suck.

Alright, enough of this. Have fun with the editor!

Update: 2.1 here:
https://github.com/kduske/TrenchBroom/releases/tag/v2.1.0-RC1
Features "cool shit".
First | Previous | Next | Last
 
Great to hear it's still moving forward. I'm just grateful that people find any time to work on projects like this.

I think we all understand that real-life gets in the way a lot more than for example 13 years ago... when I was living at home, playing Q1SPs while mum makes me din dins.

The cool thing about Trenchbroom though, is that it's making mapping so much easier, it seems to be combatting lot of mappers real-life time constraints, and therefore caused a resurgence in Q1SP releases! So keep up the good work, it's very much appreciated. 
Yup, That Darn Real Life 
I wish I had started with TB a couple of years earlier when I was still a student. Oh, the time I could have sunk into it then. Now, it's just the odd couple of hours here and there.

Thanks for the encouraging words! 
 
Haha, seriously ... I wish I could take everything I know now, and rewind a few decades. Single, all the free time in the world to work on projects ... I didn't realize what I had. :P 
 
Not really touched the editor for longer than 5 mins while I got a new girlfriend. I have a crazy mapping itch needing to be scratched 
Anyone Compile TB On An Arch Based Distro? 
Didn't realize there was a newer thread for TB and posted in another, but here is my issue compiling on Linux. I have finally gotten to the point where it almost compiles, but now craps out with 4 g++ errors ; http://pastie.org/9726329

It might be a simple error on my part or obvious to someone more knowledgeable than I. Any help appreciated. 
Also BTW 
When I attempted using latest wx src 3.0.2 its still failed, but a whole different way. http://forums.inside3d.com/viewtopic.php?f=6&t=5142&start=75#p55021 
 
Pet peeve:

"wad" "C:\new\new.wad"
or worse:
"wad" "C:\new\"
(found in at least one map)

C:<NEW LINE>ew<NEW LINE>ew.wad
makes no sense, and the other one:
C:<NEW LINE>ew"<UNTERMINATED STRING CONSTANT>
will just corrupt the world entity and everything that comes after it.

Seeing as most tools take significant shortcuts and don't parse things properly, can you at least ensure that wad paths are written out with / instead of \ or \\, so as to ensure maximum compatibility with existing tools, without outputting unsupportable gibberish please?
The alternative is to ban \n and \" etc, but this issue interacts with saved games, but making special cases for parsing wad values, or special cases for saved games vs initial load is annoying and clumsy. 
Haha 
So / is preferable to \\ ? 
 
/ works fine in the core windows api, but may be rejected by microsoft's commandline tools.
\\ will generally work, but might cause problems with things that do try sanitising things (poorly).
/ is a single char
\\ isn't usable at the start of a relative path (unc shares), and is thus potentially dangerous in windows (if poorly sanitised, // is identically dangerous).
/ is portable
\\ is not (poorly sanitised, // is equivelent to /../ on amiga and thus unsafe).

so yeah, / is preferable to \\ or \
but hey, \\ is at least a correct C string, and acceptable as-is for most of the windows api. 
/ May Be Portable For Relative Paths 
But not for absolute paths. TB supports both. So I think I'll use the escaped version with \\ on Windows. 
 
as far as windows and the C api is concerned, / is as portable as \
leading \\ (or //) will be interpreted as a unc path if the tool doesn't de-markup the string (hurrah for lazy parsing), so be sure to use / instead of \\ if its the first char of a drive-relative path, even in windows. 
Alright 
Thanks. 
Hexen 2 Support? 
So are there any plans/chance for Hexen 2 support?

I have a couple of mapping ideas I want to try out for it but I'm sick of the editors I used to use 
 
Hexen 2 is supported in TB 2.0... You need to speak to SleepwalkR about access as a beta tester 
Beta Test? 
How would I go about that? Should i just ask about it here? 
Yes 
Send me an email: kristian.duske@gmail.com 
Annoying Issue 
so i go and make some terrain looks fine in the editor and compile it looks fine in game

then i load my map back up in the editor and some of the terrain vertex points are off by one unit or more which is impossible to fix sometimes without making the terrain again and hoping it will be trenchbroom valid

yet when i load the map up in hammer those vertex points arent messed up 
Is That In TB1? 
 
 
seems to load vertex points correctly nothing is off grid in 1.0 
Seems I Fixed It 
running trenchbroom.exe with compatibility mode for any OS fixes it idk why but it does 
That Is Unlikely. 
But do make sure that you use the latest version, which is 1.1.1 
 
You do tend to see vertices wander off grid over time. I think a fix was suggested but not sure if it was implemented 
There Is No Fix 
But if you keep your plane points on the grid and don't build too complex brushes, the errors will be small enough to ignore. 
 
i wasnt even making anything complex just some raised or inverted brushes and they were going off grid until i set compatibility mode

and the problem doesnt occur on my win 8.1 x64-bit computer if i dont set compatibility mode only on this computer which is win 7 x64-bit so maybe its OS based 
Posessed Map 
https://www.dropbox.com/s/01zqjoe1komd5nn/good.map?dl=0

In Mac OS, if I double-click this map in the Finder to open it in TB (latest 1.1 build), look at the brushes, then quit the TB application and repeat, the map will look different each time: sometimes there's vertex drift (with different amounts/directions), sometimes not.

https://www.dropbox.com/s/d6ue7uurj84882n/good1.png?dl=0
https://www.dropbox.com/s/326ujizx92fqq1k/good2.png?dl=0
https://www.dropbox.com/s/27ud4h7527qkcyc/good3.png?dl=0
https://www.dropbox.com/s/ivcl33lewk0w4kg/good4.png?dl=0

On the latest Windows TB1.1 build, it seems to always open with no vertex drift; but if I open the map, go to File -> New, then open it again, it has vertex drift then.

https://www.dropbox.com/s/w5dur8zisoj3wlm/windows_not_drifted.png?dl=0
https://www.dropbox.com/s/npor518z96rh3lz/windows_drifted.png?dl=0

Here is what I got when saving the drifted version in Windows:
https://www.dropbox.com/s/nc9x7iwznrbyo2j/windows_drifted.map?dl=0

It's pretty weird, I might see if I can debug what's going on. Maybe memory corruption somewhere? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.