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
 
He doesn't want to interact with you. U mad? 
Lul 
deqer, this is the treatment you'll be getting for such an attitude from the regulars of this board.
relax, go use radiant or whatever for your quake 2 boxmaps and stop polluting interwebs with your posts. 
Deqer 
Yes it does appear to be the case that your requests are being ignored. Hmm, yes we should probably investigate this peculiar turn of events...I'm sure there must be some reason for this, if only I can remember-

-oh wait, it's because you're a cunt. 
Elevory, Ricky 
Ricky, I understand your issue was about importing Hammer maps (or rather, Valve 220 maps) into TrenchBroom, which causes TB to choke.

Elevory, your issue seems to happen when doing it the other way round: Importing a TB map into Hammer. TB doesn't support the Valve 220 map format yet. Full support for it is planned for the 1.2 release, though:

https://github.com/kduske/TrenchBroom/issues/400

But I'm afraid it will take a while! 
Will 1.2 
Include stripping out the extra data or actually recognizing / reading it?

If I remember rightly Necros (?) was working on a stripper script that would remove the extra data attached to each face string.

Recognizing it would be the first step supporting the advanced texture projection. 
Ijed 
Fixing the parser to strip the extra data is scheduled for the next maintenance release. Actually recognizing and reading the data as well as in-editor support for changing the projection axes and saving .220 map files is what's planned for 1.2. 
Although 
I fully appreciate the difficulty in reverse engineering it and maintaining the original .map format, which is definitely a strength. 
Aha 
Ok then :) 
What's Going On Here 
Like seriously. Mad seriously. 
Ijed 
The Valve 220 format is properly documented and I know how it works. The Mac version already had support for it, but that feature got lost in the C++ rewrite.

You will be able to set the format in the map properties dialog. So if the map is standard Quake, TB will save standard Quake. If it is 220, then it will save 220 (and give you the additional tools to adjust the texture projection per face). 
Will You.. 
be able to open a normal map file and then re-save it into 220 at a later date to fix up the textures? 
Sounds Like It 
And that's awesome.

Thanks for the continued dedication to this project, it's well appreciated. 
Beer++; Continue; 
 
Vondur 
Quest and Quake 3. 
Friction 
What's Going On Here

He's the turd that won't flush. 
FifthElephant 
Conversion of standard Quake to Valve 220 map is trivial (it will not affect the textures), but the other way round is tricky. I'm not quite sure how well TB will support that. 
 
"What's Going On Here?"

What's going on? SleepwalkR is being a bitch, just like all programmers.

I'm not surprised. Programmers are bitches, and many people have known that for years.

Maybe I should post videos of the things that trenchbroom lacks, and promote those videos as a "beware" message to all mappers out there. Would that help?

"Oh Fuck Of Deqer "
Thanks Ricky. I know, the truth hurts, doesn't it. 
 
deqer

U mad? 
Sleep 
I think the most sane choice would be to discard the additional texture information.

As much as I like how it works, it does have its limitations - often when slicing a brush it'll corrupt the projection leaving the actual BSP unplayable on certain engines (that being a linux issue AFAIK, but I could be wrong).

Trying to replicate the projection sounds like a minefield, and one it'd only be possible to partially cross before you lost your legs. Then arms, etc. 
 
Willem, nope. Like I said, I'm not surprised. I'm just pointing out the facts.

Even when people are nice, they still get ignored by programmers.

Heck, even the Project Manager in the company I work for complains about the same thing. Says the same thing too, lol, "programmers are such bitches."

So, if SleepwalkR feels he's better off being a bitch, then so be it. "Not to sound harsh or anything", right SleepwalkR? heh.

I'm sure he uses that quote a lot, "Not to sound harsh but ... ", but doesn't realize that it's complete bullshit when you actually read his entire post that follows that quote. lol 
Ijed 
Not quite sure what you mean now. Are you talking about converting 220 to standard Quake? There would only be approximate solutions in that case, but I could at least try to keep the texture's center pixel in a face intact. This is how texture lock works right now. 
I Was Referring 
To both, but yeah, in the previous I was talking about 220 -> .map.

Keeping it locked as you mention sounds the best solution. 
 
I think the most sane choice would be to discard the additional texture information.

As much as I like how it works, it does have its limitations - often when slicing a brush it'll corrupt the projection leaving the actual BSP unplayable on certain engines (that being a linux issue AFAIK, but I could be wrong).

Trying to replicate the projection sounds like a minefield, and one it'd only be possible to partially cross before you lost your legs. Then arms, etc.


I think that the texture projection stuff is powerful enough that it's worth trying to get it working. especially if you could directly control it in the editor, to, for example, make tri-souped terrain faces all use the same projection. 
Necros 
That's the plan, yeah. All modern compilers can handle the 220 format anyway and to Quake it's all the same AFAIK because QBSP generates the texture coordinates for the engine. 
Yeah 
I just meant the scope of the conversion features - once you're working in 220 you probably won't want to change back anyway unless exporting to another editor. 
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.