News | Forum | People | FAQ | Links | Search | Register | Log in
TrenchBroom - A Modern Quake Editor For Mac OS X
Hi everyone,

after two years of work, I am releasing the first beta of my Quake editor for Mac OS X, TrenchBroom. It is the result of an experiment where I tried to find out how Quake editing would be like if you could do it directly in the engine - that is, in 3D only. Consequently, TrenchBroom has only one big 3D view and an inspector (which you can hide anytime).

Go to for a screenshot and downloads.

Some highlights:
- renders even large maps smoothly
- support brush and alias models in the 3D view
- create new entities by drag and drop
- create, move, rotate, and resize brushes with the mouse
- clip brushes using the smart 3 point clipping tool
- create new vertices by splitting edges and faces or merge two neighboring vertices
- move vertices, edge and faces without creating invalid geometry
- texture lock that also works for rotations
- prefabs
- brush groups
- builtin compilation tools (TxQBSP, MH's light version, Willem's vis version)
- autosave, since this is a beta and all

Thanks to Bengt Jardrup, MH and Willem for their compilers and to Gom Jabbar and Vigil and other #tf guys for feedback.

Okay, that's it for now. I hope there are some people who will find some use for this. I'd certainly appreciate it if you reported any bugs, problems or feedbacks to me either here or via email to
Given that the grid is god when it comes to creating usable Quake maps, this looks like an interesting approach. I wish I had a working Mac to try it out! 
I Don't Have A Mac 
But the vertex and clipping tools sound very, very cool! 
In this editor, the grid is projected onto each surface, so you're not working without a grid at all. The clipping tool even draws a virtual grid that represents the plane on which you can position the clipping points. I find that the projected grid actually works well in most situations. Of course, a mapper needs to relearn some techniques in order to use this editor, because some things are just different.

What's wrong with your Mac then? 
Okay, Boo Boo #1 
The version which I had uploaded before didn't render edges at all. Uploaded a fixed version already. 
I've Got My Mac 
is this a good toll to use if you're deciding to start out mapping, or would you say 'not really'?

i have never tried making maps, so i am completely in the dark, i admit. 
Er, Toll? I Meant "tool". 
Yeah, I Would Say It Is 
At least you'll get some documentation with it and it's fairly modern. Note that the documentation does not contain a general introduction into Quake mapping, so you'll still have to learn a lot. But I think you already have noticed that there is some helpful folk on this board. 
Note However 
that this is still a beta. It's fairly stable, but there are crashes, esp. when editing vertices (still trying to get a good test case for that). That's why it autosaves your maps frequently. 
Good Direction 
Does the editor have a feature to align objects to a surface? like a drop down function? So you can quickly add objects and then snap them to a floor/wall surface without having to guess or leave stuff floating?

The cryengine tools only had a 3d window and it was an awesome experience. Nowadays I rarely use the 2d grid when creating stuff. When I see people using 3 x 2d grid windows for their mapping I cringe and think old cad tools! This is certainly a good step forward in editing tools.

I don't suppose this tool would ever work with Q3? 
Would love to see some movies of this in action! :)

What's wrong with your Mac then?

It got old. And died. Boo! 
Since it's all 1 window and stuff - I wonder if this would work on the iPad. Because that would be killer. :) Working on Quake maps while on the train and what-not... 
Oh, and the measurement things you're displaying are fucking awesome! 
The editor aligns entities to the surface under the mouse if you drag an entity from the entity browser, yes. It doesn't do this for other objects (yet) because I'm still uncertain as to how I can do this properly. But it's on the feature list.

Regarding Quake 3, it depends. I am certainly going to keep it open for extensions to other games, but since I don't map for Quake 3 myself, I'd have to work closely with someone who is familiar with Quake 3. This will not happen in the near future though. I plan to do a complete rewrite of the internals in C++ in order to port it to other platforms once the current code is stable and has all necessary features. Once that's done, multi-game support is surely an option. 
Sorry about the Mac. So I take it you switched to Windows then? I guess that makes sense for a gamer / designer such as you.

In fact, an iPad version has surely crossed my mind. I have tried to keep memory requirements low for the editor, and once I start redoing it in C or C++, it will be even less hungry. The thing I still see as problematic is that you obscure the stuff you want to edit with your finger as soon as you start editing it. I am not sure how to solve this properly, but yeah, it would surely be interesting to port TrenchBroom to the iPad just to see how it turns out.

On the other hand, I am writing a PhD and I have a family, so this is not going to happen soon ;-) 
I have never been so jealous of Mac owners before (or jealous of Mac owners at all until now.) 
please please do not name the download but use a version number of something. 
ewwwwwww.. I hope you don't :) 
Can I 
call it Trenchcoat? 
I would greatly prefer doing it in C, but I think that polymorphism could make adding support for other games easier. 
So you can see when it gets updated? 
can't use this on 10.5.8? (intel) 
No, it's 10.6 only for now as it uses some features that are available only in 10.6. I'll put 10.5 support on the to-do list. 
well, don't do it on my account only if it's a lot of trouble.

my mac isn't really good enough that i'd want to use it as a primary mapping device (it's a 4 year old laptop).
but i was mostly intrigued with the 3d only mapping.

i have a tendancy to maximize the 3d viewport in sikkpin's QE3 a lot these days when working on complex organic stuff so i was interested in seeing that mapping style done 'properly'. 
I'll look into it anyway ;-) 
First Time I Wish I Owned A Mac 
Looks good SleepwalkR. 
lol Spirit.
I am only now learning how intense the "archiver's impulse" really is. It's extremely useful: hell without it, we wouldn't have classic literature. So props.

SleepwalkR: uhh, holy shit man. Awesome. Great idea with no 2d views as well. It should lead to less blockish/halls&rooms Quake maps (damn that first shot of Necros' map is a great example too). 
It looks totally amazing. And i'm impressed with your "3D only" design goal. 
for archival purposes / finding old versions. with this naming scheme you can only provide one version and it is going to be multiple versions (yay, confusion). old versions can be useful sometimes. 
Will do that once there's a new version. 
Looks Great 
Will probably give it a try on my gfs mac at the weekend. No chance of a windows or linux port? 
An iPad version would be awesome! 
There will be ports to other platforms, but it will take time because I need to port significant parts from Objective-C to plain C. 
Another +1 
For a IPad version, I want to make Quake stuff on planes! :) 
Great work! The camera-only editing approach reminds me of an old level editor for DOS called GEOMETRY by Billy Zelsnack (anyone remember Prax War 2018? ;). I use to live by GEOMETRY for mapping. It took me a long time to switch to a Windows editor because I was so resistant to giving up DOS back in those days.

QUAKE editing/mapping/modding (and more generally id Tech) is a difficult thing to do outside of Windows. I'm an old schooler that has converted to using Mac's.

I've been fascinated with editing on the Mac because QUAKE was originally developed on NeXTSTEP (precursor to Mac OS X).

Oddly enough, I wanted to learn the proper ins and outs of programming and decided to try to get a QUAKE editor ported to Mac OS X -- starting with the original NeXTSTEP QuakeEd sources and eventually mixing various code bases (QE3/QE4/QE5, Radiant, etc). No intention to steal any thunder from SleepwalkR and TrenchBroom, so I'll save my editor banter for another thread at some point.

Some random questions for SleepwalkR:

How are you loading textures? I couldn't get my WADs to load, but that might be because I created them with qlumpy (which I think uses a different miptex format than what typically gets extracted from BSP files).

Did you build TrenchBroom from scratch or use anything as a starting point?

Is the "back end" code (rendering, core editing) Objective-C or C?

Any thoughts about open source?

My years of using QuakeEd/Radiant make me really resistant to different keyboard shortcuts. Thought about allowing people to customize the keyboard shortcuts?

I've tinkered with Willems ToeTag and I'm really happy to see TrenchBroom (and any other QUAKE editing/apps) being developed for Mac OS X! 
Answers For Mindabuse 
How are you loading textures? I load them directly from the wad files. I used these docs as a reference.

Did you build TrenchBroom from scratch or use anything as a starting point? It's from scratch. I purposefully did not use existing code because I wanted to approach problems with original ideas.

Is the "back end" code (rendering, core editing) Objective-C or C? Currently it's a mix of Objective-C and C. Math functions and performance-heavy code is pure C, but the rest is Objective-C. I plan to reduce Objective-C to an absolute minimum because it's slow and not easily portable.

Any thoughts on open source? Yeah, the source will be published under the GPLv3.

Thoughts about allowing people to customize the keyboard shortcuts? I am torn about this. On the one hand, I can totally understand that you would want to customize the shortcuts so that it matches your habits. On the other hand, I have kind of a daddy-knows-best approach. Apple doesn't let you customize keyboard shortcuts either, and for a reason: They have put a lot of thought into how the user interacts with their apps, and the same goes for TrenchBroom. That said, if you have suggestions or find the keyboard layout idiotic, I'm all ears. It's important for me to allow the users to edit maps quickly and efficiently, so if you think that I should approach it differently, then be sure to let me know.

That, and getting keyboard / mouse customization right is difficult. In summary: it may eventually happen, but it's not very high on my list right now. 
I am torn about this. On the one hand, I can totally understand that you would want to customize the shortcuts so that it matches your habits. On the other hand, I have kind of a daddy-knows-best approach. Apple doesn't let you customize keyboard shortcuts either, and for a reason: They have put a lot of thought into how the user interacts with their apps, and the same goes for TrenchBroom.
Has daddy made a lot of maps? Because sometimes programmers THINK they know what's best for users but are often wrong.

I don't actually know your history so I apologize if I'm uninformed. :) 
Daddy Has Made A Couple Of Maps ;-) 
I used to do a lot of mapping back in the day, and the main reason for writing this editor is to have an editor that works the way I want it to. That, and I used it as an exercise to learn more about Cocoa, C and graphics programming.

But I do agree with the fact that programmers tend to misunderstand the needs of users, which is why I said that I'm very open to suggestions. 
Oh, OK, awesome! Yeah, that's what people really liked when I was actively working on UnrealEd here ... the fact that I was also a level designer meant that I "got it" when users requested features and would implement them the right way.

Microsoft used to call it "eating your own dog food". If you have to eat it, you're going to make sure it tastes good. :) 
Yeah, I Agree 
Also, for a hobby project, I have found that if you don't have a use for an application yourself, you won't keep the motivation. I have worked on this thing for two years, mostly late in the evening and during my holidays, and I'm sure I wouldn't have come so far if I didn't have the motivation of making a tool for myself to use.

So, I'm really looking forward to getting actual hands-on feedback! Btw, the more I think about it, the more am I inclined to make the ports to other projects the highest item on my to-do list, because the group of Quake mappers who use a Mac is quite small... 
Time to buy a mac?

Or can I emulate this somehow? Wine? 
Apprently Not With Wine... 
Congrats on the release :) 
Looks Awesome 
yeah, congrats. :-) Will play with it as soon as I get a minute.

re: porting, I know I failed to deliver on this with Willem's editor, but it could be worth trying gnustep (or there's also cocotron, which i haven't tried) to do a windows/linux port. i'd be happy to look into it if you want.

mindabuse: cool, was this yours? (dead link.) 
Ijed & Ericw 
Thanks! ijed, I don't think you'll be able to use emulation. You'll have to wait for the ports.

ericw, gnustepnis not an option for me. And porting the internals to C or C++ has other benefits apart from better portability: better performance, lower memory footprint and it gives me the. Hance to review and refactor old code.

I will need help with the Windows and Linux GUIs though (the Mac version will keep its Cocoa GUI. If anyone is interested in helping me with that, let me know. 
It may be an option to use Gnustep or Cocoatron, but only after the core has been separated from the GUI and rewritten in C. 
I'm sure I wouldn't have come so far if I didn't have the motivation of making a tool for myself to use.
In other words, you're going to release a map in the near future. Going to nail you down on that statement! 
Define "near future" ;-) 
Ericw Re: Quakeed-macosx 
Yeah, I set up that Google Code site with the hopes of putting my QuakeEd project up there. I ended up nuking that since github has appealed to me much more (social coding aspects, etc).

I don't have much up yet, but my intention is to put QuakeEd on github eventually:

Are there many mappers out there that are also Mac users? I know it's not immediately related to TrenchBroom, but I'm curious if there are other forums/sites/places to poke around at since I've been out of touch with the mapping/modding scene for a while and am curious about mapping/modding on the Mac platform.... I found Func_Msgboard while searching for various QuakeEd-related projects (came across sikkpin's QE3 tree/fork, which is what my port is based off of).

GtkRadiant on Mac OS X with X11 was not maintained and was awful to look at (in comparison to a native Mac app, not to mention that I never ran X11 for anything else).

I appreciate that there's people out there that have an interest in QUAKE/id Tech development on Mac OS X. 
btw, how are you loading entity definitions?

please say structured text. ^_^; 
There's not a ton of Mac guys making Quake levels. It's a tiny niche within a small niche. :) But there are some... 
I'm loading def files - why? What do you mean by structured text? XML? I have to say I'm not a big fan of XML, but .def files are pretty stupid, also. 
anything with structure really. just wanted to know for that def/fgd converter thing. i'm almost finished it now... has a gui, can parse files and such. was going to see if i needed to add another format. :) 
No, TrenchBroom uses standard file formats for everything. It won't have a special format for anything. 
I'm all over this the instant I can get a build that works with my shit. Which would pretty much have to be PC/Windows. The iPants version sounds like a great idea but a massive challenge! I bought one for the wife a while back though, so bring it on. Hell, I'd even install Linux as long as I can get a build where I don't have to recompile my Colonel Sanders and write my own sound drivers.

On the subject of .def files, it's probably a good move to go with that, since it'll be familiar to some people, and you can use existing resources if needed. Tigger-oN has some that were pretty comprehensive and well documented that he was distributing with his GtkRadiant guide/package years ago. Whatever the format is, if its easy enough to follow, people can help with adding Quoth stuff and what have you. 
Isn't There A Def File For Quoth Already? 
I plan to include .defs for commonly used mods with the release. Currently, only standard Quake is included, but I'd like to add quoth, too. Which other def files should I add to that list?

Okay, I see that many people are interested in a Windows / Linux version, so I'll get cracking on that right away. 
Quoth Def 
I would certainly imagine there's a .def for Quoth by now, that was the point though, it was a smart move to use an existing format rather than creating a new one. But of course you already know that. I can also state some more obvious things such as ports would be awesome!

I'll have to start planning my first TrenchBroom map. 
I'll keep you guys posted about the progress. 
did anyone make an SP EFDM12 yet? If not, you should! 
Hi Than 
Not yet, but yes, I should. If only because you said so. Honestly, I'd love to do some Quake stuff again. I have a great setup for it, just need to stop working 80 hours a week on shovelware to make my own mediocre stuff! 
Don't Forget 
The rubicon def file. 
Already On The List 
Multi-type Classnames 
Does/will TB support multiple entity types with the same classname, e.g. brush triggers along point-based ones? Not allowing this is a major inconvenience in Gtkr.

Def files: I hope the existing Quoth def (if there is one) was done by Preach. Otherwise it'll be just as incomplete as the Quoth mapping manual. The standard Quake def that comes with Radiant is missing some stuff, too. 
I Don't See Why Not 
I can add support for that, yeah. 
Compile Error 
I downloaded to test compile, everything completes without giving an error but when I try to run the map I get:

Removing existing BSP file '/Applications/quake/id1/maps/TTSample.bsp'
Failed to copy BSP file from '/Applications/Quake/id1/maps/TTSample.bsp' to '/Applications/quake/id1/maps/TTSample.bsp': The operation couldn�t be completed. No such file or directory

when I try loading the .bsp file directly the map is fullbright. 
looks like the shell script is removing the bsp file first then trying to copy?? or is it removing the old version?

fullbright map just means light.exe did not run (or no light data was saved). 
Yeah, I see that sometimes, your Quake directory has a capital Q and sometimes it's lowercase in those error messages. Can you drop me an email with the full error messages at please? 
It's not a script, and yeah, it removes the old bsp from Quake/id1/maps first, then copies the new version. 
Did you put the .map file into your Quake/id1/maps folder and the compiled the map from there? Because then, it'll create the new bsp, remove the old one (which in this case is identical to the new one) and then, when it tries to copy the new bsp, it's gone. You should not store your .map files in Quake/id1/maps. Put them someplace else. 
Some Results 
moved the map files into a separate folder and now I can run them from the editor. still getting fullbright maps. no errors come up in the console but all the light threads take 0.00 seconds. are there verbose modes I can set to give you a more useful error log? also would it matter that I'm running 10.6.6? 
Can you post the complete log from the console please? 
You're sure the map is sealed? I know it's a sample map but maybe a vertex drifted or something.

If you noclip in the game, is all of the outside cruft gone or is it still there? 
Oh wait, light would still run if it was unsealed... never mind. :-/ 
Test Map 
Where did you download it? I'd like to get it and test it myself. 
TTSample ... that's not my map, is it? 
I Can Compile And Run The Map Just Fine. 
Light finishes in 0 seconds for me, too, but the map is not fullbright. Which engine are you using? 
@willem yeah, had it sitting around from when I was trying to map in os x with toetag.

===== Running Compiler Profile Full =====

===== Launching task 'Compilers/TxQBSP TTSample.bsp' =====

TxQBSP 1.13 -- Modified by Bengt Jardrup

Outputfile: TTSample.bsp
------ LoadMapFile ------
Title: "ToeTag Start"
3968 faces
672 brushes
74 entities
61 miptex
1557 texinfo

Building hulls sequentially...
Processing hull 0...
------ Brush_LoadEntity ------
644 brushes read
------ CSGFaces ------
3800 brushfaces
3994 csgfaces
3404 mergedfaces
------ SolidBSP ------
5887 split nodes
2635 solid leafs
3208 empty leafs
45 water leafs
8843 leaffaces
8192 nodefaces
------ FillOutside ------
1716 outleafs
------ MergeAll ------
2400 mergefaces
------ SolidBSP ------
1445 split nodes
788 solid leafs
641 empty leafs
17 water leafs
3432 leaffaces
2631 nodefaces
------ Portalize ------
658 vis leafs
1899 vis portals
------ Tjunc ------
2975 world edges
9895 edge points
1858 edges added by tjunctions
0 faces added by tjunctions
------ MakeFaceEdges ------
------ GrowRegions ------
Processing hull 1...
Processing hull 2...

------ FinishBSPFile ------
WriteBSPFile: TTSample.bsp
986 planes 19720
3677 vertexes 44124
1588 nodes 38112
1557 texinfo 62280

===== Launching task 'Compilers/Vis -threads 4 -level 4 TTSample.bsp' =====

---- vis ----
testlevel = 4
658 portalleafs
1899 numportals
average leafs visible: 162
c_chains: 3173902
visdatasize:27876 compressed from 54614
32.0 seconds elapsed

===== Launching task 'Compilers/BJMHLight -gate 1 -threads 4 -extra4 TTSample.bsp' =====

----- Light 1.43 ---- Modified by Bengt Jardrup
----- Release 2 ---- Coloured light and LIT support by MH

Fade Gate 1 set
Extra 4x4 sampling enabled
File: TTSample.bsp
74 entities read, 43 are lights, 2807 faces, 34.3M casts

Light 0.0%, Thread 0, Elapsed 0:00
Light 0.0%, Thread 1, Elapsed 0:00
Light 0.0%, Thread 2, Elapsed 0:00
Light 0.0%, Thread 3, Elapsed 0:00
Light 100.0%, Thread 1, Elapsed 0:00
Light 100.0%, Thread 0, Elapsed 0:00
Light 100.0%, Thread 2, Elapsed 0:00
Light 100.0%, Thread 3, Elapsed 0:00

lightdatasize: 52724 
Please Send Me That Bsp 
I want to verify that it is without light info. Also, which engine are you using? 
Did You Set 
'Light' keys on your light ents to give them brightness? No light key, no light. 'light' '300' is a good starting point.

I'm sorry if this is a stupid question, I'm not trying to insult anyones intelligence. 
Is It The BSP2 Version Of Light? 
Hopefully not.... 
Usually when it's full bright you don't have any lighting data but his light compile is reporting a size there. Weird... 
The map should be working properly if he didn't change it (which I don't think he did). The problem must be related to his setup and TrenchBroom's inability to work correctly in that setup. 
is there a light key in the worldspawn?

if you had say 'light' '300' in your worldspawn, it would be a maxed out minlight which would look like fullbright. 
using a brand new install of trenchbroom, running the map with quakespasm, and a fresh id1 folder. the .map file is unchanged from willem's .zip file. emailing sleepwalkr the .bsp I built.

thanks for helping so much. I really appreciate it. 
yeah, had it sitting around from when I was trying to map in os x with toetag.

the .map file is unchanged from willem's .zip file.

Please also send me the .map file. I can confirm that your BSP is fullbright, but I don't know why. 
Hmm, When I Compile The Map, I Get Slightly Different Output 
So maybe you did change the file inadvertedly. 
I Suspect In Issue In The Realm Of Duh 
Also Ricky, no light key does not mean no light, it means the default value of 300 is used. 
pretty sure the .map file isn't the issue, I've downloaded it twice since I first posted here, still sending it over with the .wad I used for textures. 
where is the preferences file kept? I tried preferences and application support, if it's external then maybe deleting those files will fix things. 
You can try. The preferences are in ~/Library/Preferences - but I doubt that it's the issue. 
out of curiosity, any progress getting this on windows yet? 
I'm rewriting everything in C++, which takes some time. I have decided to do the interface using an OpenGL GUI toolkit so that it is portable. I plan on getting map loading, rendering and camera navigation to work today so that the editor will be able to display a map. Then I will use that milestone to make a windows and a linux version. When that's done, I'll start implementing all the editing functions and the GUI.

It really is a whole lot of work, so don't hold your breath. I am sure that I will be able to release a beta in summer though. 
sounds good 
wow, that sounds great! let me know if you need some windows testing. ;) 
I Will 
Once I got something to show. 
Which One? 
"I have decided to do the interface using an OpenGL GUI toolkit so that it is portable."

Which one do you plan on using if you don't mind saying? 
Google for Gwen Gui and you'll find it. It's better than all other toolkits I've looked at, but it's still very cumbersome in comparison with Interface Builder. 
Web Browser Based Version 
I think Warren mentioned sometime ago that he was trying to do a webgl version of toetag but gave up for whatever reason. I think it would be pretty cool if there was an editor that worked in a multi-platform browser such as Chrome. Chrome currently supports all kinds of ways to access files as well as WebGL. For GUI stuff it would be possible to use jQuery.

Would anyone else like to see a web app version of this or any other Quake editor?

For what it's worth, Insomniac, developers of Resistance and Ratchet and Clank started using browser based tools and say their tools are pretty awesome now (not just because they are browser based, however), so it's probably not nearly as shitty as you might think if the tools are made well. 
Keep in mind this is just one opinion, but a few months ago I seriously was playing with WebGL. But it would be a ton of time and effort to maintain a WebGL version since Javascript and C derivative languages share little in common.

And then there are the major security issues of WebGL ( , there are sadly several which the statement "The reports provided example exploits capable of cross-domain image theft, graphics memory theft, and client-side denial of service." touches on), which I think may terminally prevent it from being seriously adopted ... and as a result as far as I know only Chrome and FireFox will support it "out-of-the-box". Safari has it disabled, although it is used for advertising within apps on iPhones and such. Internet Explorer will not support it.

I don't think WebGL can ever take off since it is easily possible to make a harmful web page with it if one choose too.

I like the idea of WebGL, but as security issues are a major concern on the internet, I think WebGL has no future.

/One opinion 
That sucks I guess. But surely those security issues will get patched? What alternative is there for 3d on the web? What about performance? MS probably won't support webGL because it's not webDirectX.

It is entirely possible to make an app that runs in the browser but is loaded from client side files. However, I suppose if it's easy enough to make a portable native app, then you might as well just stick with that, since it will give better performance. 
Java Applets 
Can access OpenGL directly, and are portable. If I were to make a browser-based editor, I'd check out Java applets. But I'm not ;-) 
Looking Forward To The Windows Version 
Prefabs And Instancing 
haven't tried it yet (windows lol), but does the prefab stuff work like instancing?

e.g. change the prefab and this ripples through to all your instances of that prefab already in the scene... 
!!(!) instancing would be insanely awesome. even more so if it worked for anything.

ie: in 3ds max, when you copy any object, you can make a copy or an instance without having to make something specifically as an instance. 
i'm always doing shit like having a million copypasta'd light fixtures then somewhere down the line i decide that I wanna change the design slightly, and having to track down and change every single one again is just about the worst thing ever. 
Proper, Max-style instancing would make this the one and only true editor. Seriously. 
Like many awesome features, QuArK has cloning. And since it also has groups (think folders), it is really super duper awesome. 
Quark is, unfortunately, an abomination. :) I've tried to use it several times and give up within 5 minutes. The interface is absolutely atrocious. 
Very 90's retro UI, could never get my head around it enough to build anything. 
Weird, I would say it is much more standard and intuitive than any of the Radiant editors for example. Or any other Quake editor I ever saw. 
If you say so. My brain recoils at the mere sight of the Quark interface. 
And mine vomits tarbaby sauce if I see a Radiant. 
Yeah, you're different, I get it. Most other people feel the opposite way. Quark is bizarre, at best. 
Yeah, it's weird. I would like to see some generic Windows user sat infront of Radiant or QuArK and see which one they are able to use immediately. 
Editor Fails 
Quark is not quite the worst Quake editor ever made - that award has to go to the commercial product "DeathMatch Maker". Features:

1) the grid is decimal. I'm not joking. You simply cannot make geometry to the power-of-2 grid, only units of 10, 20 etc.
2) No graphical texture browser, just a list of texture names. 
Interesting side note ... I gave a talk on level design at a local business and afterwards, one of the guys who came up to ask me questions was the writer of DeathMatch Maker. He seemed totally normal too... 
Big part of why Trenchboom looks interesting to me is because it has the modern styled 'all in one 3d window' approach as opposed to multiple fiddly panes 90's set up. 
I'll really have to try it out and see. I like 2D viewports but that might just be because I'm so used to them. But I use them in UnrealEd, 3D Studio Max, etc. So ... I feel they must be useful. :)

Would like to play with it though since it's not just REMOVING the 2D viewports but rather it was designed to not need them. 
That's a very interesting idea that I hadn't thought of yet. I don't see why this wouldn't work. I guess the greatest problem is that it has to survive map save / load cycles and it'll be hard to stuff the additional information of what was instanced from what into the map file.

I'll keep it in mind. 
Extra File 
You could create a second file that goes with the original map file that includes the extra instances. Personally I would prefer if you could use a standard prefab format like ASE for example. Only downside to a prefab format is the compiler would need to understand them as well. 

it's worth mentioning that aguirre's qbsp compilers (really, the only qbsp compilers worth using) support the -group switch which turns anything in a func_group into normal brushes at compile time, so you could maybe use func_groups and attach additional info with comments 
There's the bsp2 compilers, based off AguirRe's but supporting the extended formats.

Maybe additional data could even be incorporated inside for things like instancing. 
Ideally, and this might be pipe dreaming, but if you could do what valve does with their func_instance entities ... that would be fucking AMAZING.

Basically, you build your instance in it's own MAP file at the world origin. Then in your real map you add a func_instance entity and tell it which filename to reference. It draws it in the world in a different color and you can duplicate it as many times as you want to.

To edit the instance, you just double click it and it opens up that file in Hammer. Save your changes, flip back to your level, and all of the instances have been updated.

At compile time, Hammer copies in one copy of that file for each instance in the map. Done! Then the tools don't have to change and everything is clean. 
Oh! And a huge advantage, since you have rotational texture locking, is that using this system you can do great stuff like work on a crumbled building or something in a file. Then include that as a func_instance in your level but now you can tilt it 15 degrees or whatever you want.

So, in the level itself, the building is tilted and awesome looking. But your source file is axis aligned and easy to edit.

We'll know to stop asking for stuff when you start screaming. :P 
not having to include the actual "god parent" inside the compiled map sounds better than quarks way (it does have prefabs too actually, but that never worked for me). but having separate files for the source is half nice (since sharing prefabs is easy), half bad (since you must make sure you have all the files or you won't be able to build correctly). 
We've actually experimented with that - I got a func_door_model working, which could reference a .bsp - the idea being that you use them all over the level without exploding the model limit.

We also got misc_models doing the same job.

I spose it could work as a prefab too.

Nobody got excited about it so it stayed as it was.

Problems with this are collision and lighting. Collision needs to be handled in Qc and lighting in engine. We got both of those reasonably functional.

It becomes more of a systematic organisation problem than anything.

The two desirable features for an editor would be a fixed format - as Willem describes you double click to open a prefab .map and all of such must be called and the other one being showing the external file in editor.

Food for thought. 
Misc Models 
@SleepwalkR, what willem describes is pretty much what Q3 has been doing for years. Create brushwork or models in separate map, compile into ASE file (text format++) place in map as many times as required. The compiler takes the model/map object and compiles it into the map at specified points.

Also you can rotate and scale the model in any direction and something that I find really useful is that you can remap the texture to something else and create sub-model versions. (Useful for creating additional versions for variety reasons, same model different skin etc)

Not having this ability in Q1 is strange to me, something I use all the time in Q3 because I like to rotate stuff to any angle and maintain texture alignment. I always think of level design nowadays as prefabs and set pieces. Manually clipping the instance afterwards is easy. It is rare for a instance to have to be exactly clipped, rough outline can do. 
sock ... If it's being compiled as brush work anyway, why the conversion to ASE first? 
Not sure why, but the ASE model is setup ready for the compiler as a triangle stripe. The best way to describe it is pre-compiled model. The only drawback is that anything touching it has to be align correctly otherwise there is sparkly lines on certain video cards.

The compiler assumes the ASE model has been cut up into triangle surfaces already which sort of makes sense especially if you are dealing with 100s of models. Why waste the final compiler recalculating the prefabs over and over. 
Q1 Is All Bsp 
It doesn't have any support for containing meshes.
Having arbitrarily rotated geometry all over the place in Q1 is a bad idea because it will go on to make a mess of the bsp tree.

This is perfectly fine in Q3 where you have the detail geometry separate from the structural geometry that vis is calculated from. 
Sure, but maybe you can make a pillar and stick to 90 degree rotations when you prefab it.

Besides, people do crazy crap with Quake1 all the time. :) 
Barging In Without Reading All Posts 
Maybe I don't understand it correctly, but groups is no problem in standard map format. See how Quest (and possibly WC) does it: group information is stored in comment lines before each brush. This is sufficient for normal use, and much better for compatibility reasons. Func_group entities require additional editing and may be an unnessary source of conflict.

No idea about instancing, but wouldn't it be possible to make it work in a similar way? Editors without support would just disregard the comments, but the brushes remain in the main map file. 
I like the idea that Willem outlined above: Create instances in extra map files which can be opened separately, and store instances as entities. Those entities would then contain the following information:

- reference to map file where the instance was stored (relative path)
- translation
- rotation
- scale
- texture remappings

I would supply an additional program that you would run before qbsp that replaces the instances with the brushes from the original map files - then you won't even have to change qbsp at all.

The main problem I see is that this opens the door to creating all sorts of qbsp compiler problems due to rotation and scaling of instances. But as others pointed out, this is a risk associated with Q1 anyway.

Good stuff, keep the ideas coming! It'll be a while until I can implement them, but I'm keeping all this in my to do list. 
well, it's your program, but i don't like external instances at all.

you'd have to open up the external file, make changes, then load up the actual map and look, then go back in the external file...

it would be better if everything is contained in one map, and you can edit any of the instances and those changes will propogate throughout. the instances shouldn't be read only.

this way, if you're in an one area, and you suddenly realize your pillar sucks, you can change it on the fly and see how your changes affected other areas.

if you build in a method to change external map files right in the current map then that's fine. i'm just against having to open up extra files and such.

maybe consider your own format? as long as you have an export option, it would be fine... like flattening a multi-layer photoshop image into a jpeg or something. 
Own Format 
I'm trying to avoid this as long as possible. I'll try the different options once I start with this feature... 
@necros, if you want to keep tweaking instances to fit every situation then you are thinking about instances the wrong way. They should be fixed/readonly because they are an object you want the same in multiple areas. If the instance doesn't fit a situation, create another or tweak the surrounding architecture to fit.

Instances are a faster way to work, you don't need to tweak every pillar in a room, just instance one pillar and copy and paste. Variety can be added later with the reskin option. Instancing is about blocking out a room with prefabs and then going back adding detail where it is needed. Plus with the rotation and scale options that should be plenty of variety. 
if you want to keep tweaking instances to fit every situation then you are thinking about instances the wrong way.

the whole point is so you can make something and later change it and all the instances reflect that change.
that's what i was saying in my post.
if you had pillar1 used in your entire map, you might be making a new room with pillar1 and decide you want to change pillar1 to better suit the new room.
you do that and now you can check how the new pillar1 looks in all the old areas.
if it sucks, yes, you make a new pillar2, otherwise you keep the changes to pillar1. 
Having arbitrarily rotated geometry all over the place in Q1 is a bad idea because it will go on to make a mess of the bsp tree.

Is arbitrary rotation any worse than if someone just went a bit hog wild with the 3-point clipper? I mean it's just planes at funny angles surely, which is all the 3-point clipper produces... 
yes and no...

if you use the clipper so that the vertices of the edges it's creating are off the grid, you will probably get some rounding problems, the same way as if you just rotated a brush but didn't fix vertex positions.
but this doesn't always happen. sometimes off grid vertices don't bother the compiler at all.
i'm not quite sure why though, sorry. 
Yeah, but I think focusing on this is a mistake. Yes, people can create bad geometry with an instancing function. So what? :)

Solution : "Don't do that" 
I have been experimenting with turning off netradiant's "snap planes to integer grid" option so the plane coords get written to the .map as floats, then taking a multi-brush structure, rotating it at a funny angle, then compiling with aguire's txbsp, which handles floats in the .map file.

Results are pretty good so far - faces get merged on the rotated stuff where you expect them to, I can't see any cracks between the brushes, and I can't see any visible downsides yet. That said, I have not tried this on a large scale. 
willem: yes, that definitely is a case of garbage in garbage out. and certainly no reason to restrict the power that a full on instance system would provide. 
The Thing Is 
There isn't really anything wrong with vertexes being off grid, since vertexes are never stored in either the map file or the bsp.

In the map file the planes are stored using three floating point vectors that mark points on the plane, these do not necessarily correspond to any vertexes.

In the bsp file the planes are stored using a floating point normal and distance from origin.

All the problems that come from building off grid come from I guess weird rounding errors in qbsp that doesn't try to do any sanity checking, or that if you have lots of planes in any possible direction there are going to be lots of splits and cuts and whatever. The algorithms for expanding the clip hulls seem to really get messed up with wobbly architecture.

Ninja edit: Looking through the source for the latest version of qbsp I've got, it looks like someone in somewhat recent times changed the internal representation of map file brushes from integer vectors to floating point vectors. This might explain why everyone from old of have been having trouble with off-grid brushes; the old compilers didn't really support them.
Does anyone know anything more about this and can confirm/deny? 
of course vertices are stored in the BSP! How else would Quake render triangles? It certainly doesn't compute the vertices upon map load. 
Oh Yea Right It Does 
I'm kinda confused and I don't really know where I was going with that... 
I would give my firstborn for someone to implement detail brush support into the quake compilers, so that we could all rotate, butt random things into things, and do whatever the hell crazy geo we want and everything will all be hunky-dory. 
Unless Of Course 
something about the quake engine/bsp format means that quake 2/3-style detail brushery is impossible on a fundamental level...? 
detail brush support is a bounty and still waiting for a loving coder after 2 years or so. 
Maybe One Day 
when TB is released and has all the features in the to do list, I'll go and take that on ;-) 
Just To Clarify About On-grid / Off-grid 
necros - are you using an editor that can write non-integer coords to the .map file - or does it snap to ints? In netradiant I have recently turned off the "snap planes to integer grid" option because to make a few of my thin trims flow perfectly around curves I've had to go down into the 0.5-unit grid on occasion. I've seen no ill effects so far at all...

After all, as czg says, modern bsp compilers (in my case bjp's txbsp) read in the plane coords from the map as floats right off the bat, and immediately convert them to a (normal, distance from origin) format anyway. 
I tried one time to add detail brushes but after spending several days wading through the QBSP source with minimal success, I dropped it. That code is a ridiculous mess. :) 
Interesting Thread

about detail brushage in Q1 - no real progress at the end but some interesting stuff to look into maybe. 
kinn: that might actually be the issue.
i'm thinking of trying to swap over the netradiant. 
If you still use qed3.1, the preference option "Use Brush Float Precision" writes brushes as floats in the map file. 
no, that thing is crazy broken.
the visual part of the editor is fine, but it saves as (badly) rounded coordinates which only show up either compiling or reloading the .map file. you end up with micro brush-misalignments everywhere. 
I like the way willem describes the Valve func_instance. That sounds like a pretty simple and foolproof way to do instances to me. No extra file formats, no modifications to the compile tools required, and the models can easily be built axially aligned and later rotated.

Instead of making an external tool, you could just have an option in your map export like "write instances to map". Which doesn't let you, or at least warns you if you try to save the map over itself. Maybe the concept of .map export is alien to you because you are using standard formats, but Worldcraft uses its own format and so has a map export function, which allows you to export visible objects only etc. That's pretty handy by the way...

Then again, a little program that sits in your compile batch file and deals with the instances would be fine too I guess... maybe better, I dunno :)

Regardless of whether you later rotate your instances or not (I would personally choose not to and make special rotated instances unless it was an instance of a func_wall or other solid_entity) it would be a brilliant feature to have. 
Sorry, why would you not rotate your instances? 
Depends What Was Instanced 
I'd rotate 90, 180, 270 for sure. Other angles I'm not sure... it really depends on whether I start getting errors or not. If I was just instancing something simple like crates, and especially if they were func_walls, there would probably not be a problem, however, with more complex geometry, and especially if it has to fit together with other parts, then it might be better to just build manually. I guess I'd need to test it to see how well it worked before saying for sure if I would use rotation at angles that are not multiples of 90. For light fixtures and simple things it would probably be awesome win win win. 
that's what willem was talking about earlier. just because it could cause errors is no reason not to include it.
it's like the carve function. it can be dangerous if misused.
if you're finding your rotated instances are blowing stuff up, you'd consider different methods. 
Necros (+ Q For SleepwalkR At The End) 
I was saying it was an awesome feature and I would use it, but perhaps not be too comfortable just rotating everything to 12.7784 or whatever in all axis and expecting things to be fine :)

Then again, I've used Worldcraft forever and it does not support floating point coordinates and does not do any brush validation, so although it gives you a little bit of flexibility, you have to be vary careful or you start getting all sorts of errors and have to open the map in a text editor to fix things that are broke (not due to rotations, but other things like clipping to get a brush with 0 faces... OMG! Duh!)

Anyway, I'm really looking forward to getting my hands on a windows or linux build of trenchbroom at some point.

SleepwalkR: ould I ask, what is the map in the trenchbroom screenshot here: Are you making something with you new editor? :) Also, are those rocks just manually made prism-soup or is there something fancier going on? 
Oh You! 
what is the map in the trenchbroom screenshot here: 
Yeah, Ne_ruins 
I am too busy with programming the editor, but I'll get back to mapping eventually. The stuff in the other screenshots is a map I've been dabbling with, but that's on the back burner until the ports are done. 
Another Request 
This is a real simple one:

a tool that lets me define two points, then both draws a line between those points and tells me the length. :)

also, a tool that will let me display an arbitrary sized sphere might be helpful as well. 
Distance Measure 
Quest had that, very useful. Probably even more so in an all-3D environment. 
just occurred to me:
in addition to arbitrary measurement, it would be nice if there was a toggle that would display a line between two selected entities (or last brush in a bmodel) along with measurement.
bonus if it does that for more than 2 selections (but you might want to cap it if you selected like dozens of entities) 
I think that there should be a "Z" checker at the click point of a current view. 
I Don' Understand 
what you mean by the terms "Z checker", "click point" and "current view". Can you elaborate? 
Also, there should be a bobble whenever I hover over the snitch guard. 
z-checker is a tall thin viewing window that is shown at the side of the main window in QER to show you the z position of the current selection relative to other brushes. I haven't used radiant in ages, so I don't remember if it showed other entities in the z-checker, but I remember it being somewhat handy sometimes, but I don't think it was something I couldn't live without - especially as it was possible to switch to side views anyway. 
you can see the z-checker at the left of this picture: 
I remember, thanks Than. 
thanks Than, for doing my explanation job 
I Still Don't Understand 
all of it. What do you mean by "click point" and "current view"? Should the Z checker be visible always or only if the mouse hovers over something in particular? 
isn't the zchecker just to get around limitations for people who use only a single editor view? :P
trenchbroom is 3d only, so it seems like it would be a lot less relevant for this editor.
guess work on my part, of course, as i've only seen screenshots of it and heard how it works in this thread. (any luck on older mac os versions or windows? ^_^;) 
I'm making progress and will post an alpha of the new windows and mac builds soon. No Linux yet though. 
Z Check 
since trenchbroom has only 3d view, my vision of z checker is a point that has additional control 'front', 'side' and 'top' view from it 
SleepwalkR making progress on the Windows/Mac builds? Unfortunately, I only have Windows but am really excited about this. 
It's goit slow due to my day job, but I'm implementing the features one by one. 
glad to know it's still moving forward, even if the going is slow. :) 
Don't Worry 
I'm still very motivated to do this. I'm just not goong to release public previews for the time being because the prep for a preview takes too much time away fom actual development. 
Sleep Has Spoken 

I think I told you this idea in IRC once but I am not sure so I better post it here:

User-defined coordinate systems. Like BKS (german) in AutoCAD. Basically you can rotate and scale a coordinate system as you like and return to the "world" system later. Scaling would not be interesting, but rotation would be fantastic for Quake stuff. Not sure how it work with precision though, so I am not sure it would be possible. 
Interesting Idea 
Anyone Compile TB On An Arch Based Distro? 
I have finally gotten to the point where it almost compiles, but now craps out with 4 g++ errors ;

It might be a simple error on my part or obvious to someone more knowledgeable than I. Any help appreciated. 
how do I compile in the mac application? can someone make a tutorial with very specific steps? 
Please Check The Release DEB Package 
If I try to download the 64-bit Trenchbroom 2.0 release DEB package, I get a truncated file. It's about 1.5 megabytes, while the 64-bit Beta DEB package is 73 megs. I tried three times with the same result.

There's another problem. The Beta version cannot be installed straight out of the package on systems that don't use libpng12 with that specific version number, which is one of its requirements. My Ubuntu 16.10 installation has libpng16-16 for example.

I don't have a suggestion about the second problem, but you should see if the first problem is on the server end. This is the specific page which gave me the 1.5M file with the Stable Latest link: 
Libpng Issue 
Follow up to my previous post: I guess the quickest solution is for people to install the old libpng12 package manually on systems that don't have it even in the repositories. 
You're In The Wrong Thread 
Also The Deb File 
was uploaded by accident. 
I didn't read the full title of the thread, because my browser didn't display it very well. I'll be more careful next time and check where I'm posting. 
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.