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
THANKS! 
TrenchBroom lit a massive fire under my ass to take mapping seriously. Ive dabbled with BSP mapping for years...probably close to 10 but never took it seriously enough to care about releasing a full map. For the most part I just used it as a "sktechpad" of sorts. When I tried out TrenchBroom it answered a lot of prayers I had while working with Hammer and QuARK.

Thanks a million Sleepwalkr.

Lately Ive learned a lot about the creative process and how to manage progression of my creativity. Hoping to get a Q1SP done in the next few...months. 
Great To Hear! 
 
Texture Offset Is Not Same In Game As It Is In Editor View. 
I'm feeling stupid, because I can't figure out how to fix this : https://drive.google.com/file/d/0BwxYkKdSD855a0RHbUFpcDlacFE/view?usp=sharing

I have removed, remade, working on values (trying positive, no floating "float" values etc.). I haven't have this kind of problem ever before, even when working degrees that are more precise than 26.5. Normally something like this I was able to fix, just removing it and remaking it from scratch.. but not in this case. 
What Qbsp Are You Using? 
with tyrutils 0.15 you could get issues like that if you didn't use the -oldaxis flag. 
Version 0.15.5 
I was using tyrutils 0.15.5 it seems..
There seems to be new version available. 
Which Map Format? 
220 or standard? 
I'm Using Standard Map Format. 
 
Clipping Tool 
SleepwalkR - I was using the latest stable release without the 2D views. I get what you're saying about the pre-selected clip plane orientation with 2 points. I'm just saying it would be nice to have a hotkey to cycle between alternate (horizontal/vertical) planes. Also if you select 2 clip points on different faces as in my barrel example, the default orientation isn't always logical.

I suppose an even nicer feature would be to have a rotation control around the clipping axis so that you can do the clip at any angle. This would be a lot quicker and more convenient in many cases than placing a 3rd point, I imagine. I havn't seen this feature in any other editor so it would be quite innovative. 
Re: Numeric Instability (#1921) 
I've just looked into the issue again and realized that it might not be so bad as I originally thought.

Yes, the way the D3 editor represents brushes in a map file is inherently numerically unstable, because if for instance you translate a sloped surface represented like that, the little error adds up.

I've saved a map with a slope and cut off a few digits of its normal vector in a text editor. Resaved the map, the numbers after the decimal points changed a bit, as was to be expected because there is the binary representation in memory vs. the textual decimal representation.

Now... I've moved the brush slightly, and back into position, and poof, the numbers were exactly again as if I had just cut this slope freshly. I suspect the editor renormalizes all brushes that are manipulated in any way (an untouched brush wasn't changed like that). It's possible that internally, at runtime, they are represented as vertex meshes or with spanning vectors for the planes, and when saving, it's trimmed down to that simple but unstable plane equation representation.

Without looking into the code, I guess when loading, the editor derives a more stable representation by looking at the computed corner vertices, and calculates spanning vectors aligned to a really fine grid from vertices it picks as it best sees fit, to work with while it's running.

This math is more precise and less error-prone the closer the architecture is to the world origin. It's an interesting approach... and it solves a bit of the uncertainty when spanning vectors get too extreme, and being faced with the problem of checking for that and calculating better vectors. 
@Newhouse 
Are you using arbitrary face alignment.* You might want to try world instead of arvitrary or face alignment.

*Please note that I don't know Trenchbroom handles arbitrary alignment feature of ALT+RightClick that other editors have so talking out of experience with other editors here. 
SleepwalkR & Ericw 
(I sent email) I went through my map file, and tried to put replace integer values in some cases where some numbers really wanted to be "close to" integer value 0.5.. values like 0.499999999 = 0.5 etc. I have no idea about those values, are those really suppose to be not like set in editor or does it have to do something with coding language and how Math works in the end.

Though that didn't fixed my issue, hopefully this will be solved some way (even idiotic way).. maybe I need to create new map, and start copying same brushes from this map or something. 
@Qmaster 
I have no idea what you mean by that (have no experience), but in TB I select brush's faces and just rotate them.. so is that called 'arbitrary face alignment'?. 
Here: 
 
Thx, sometimes I wish I could have born in USA or Britain, so I couldn't need to use dictionary all the time. But that article seems like, it has some important information. 
NewHouse 
Did you look into whether or not you supply the -oldaxis argument to qbsp? 
 
Error unkown option 'oldaxis', I tried to put it on Qbsp : Txqbsp.exe -> command line arguments -> -oldaxis

Am I doing something wrong in here? 
 
Nevermind.. wrong place.. I have to look into it, I try to compile it now. 
 
Nothing seems to be changed after adding -oldaxis, texture is still off. 
Newhouse 
I didn't get the email, mind sending it again?

Also you mentioned tyruttils 0.15.5 which is my compiler pack (tyrutils-ericw), but you also mentioned txqbsp which is a different compiler. Are you sure you tried my qbsp too? 
Ericw 
Thank you, it fixed it* I have to continue mapping to see, did it actually fix all of the texture related problems I had.. this Txqbsp.exe, was it recommended in some website because I ended up using it? Ealier qbsps gave me errors or something like that.. but now it went flawlessly, you been doing a lot of updates recently I assume*

Thank you again. 
Cool 
I couldn't reproduce the problem in either tyrutils-ericw or txqbsp-xt; maybe you had an old txqbsp.exe 
Ericw 
It must be the case* 
Quaddicted 
Quaddicted recommends Txqbsp here, which I think is a large part of why people are using that older compiler. It's the reason I was still using it when I sent you that email a ~month ago ericw (I was too lazy to change my .bat files to use the 0.15.5 qbsp before then...). Someone should really ask Spirit to update the page, I suppose. 
Pritchard 
I must be equally as lazy not yet lazier, oh well - there is many updates to keep eye on. Some cases updates has been many so easy and automatic that we don't actually need to even thing about it. 
 
has been made* too easy and automatic.. 
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.