That's okay, thanks for the video.

I wonder why all these bugs show up just now. We have had all those alpha builds and it seems like noone has really tested them. Maybe I should stop doing alpha builds. 

https://pbs.twimg.com/media/CdhlNGxW0AEmRVB.jpg:orig

Overall, TB is quite impressive. :)

Before that, I've wildly copied and pasted brushes until it crashed. Then I tried the same in Microbrush until it crashed. TB reached 64k brushes before crashing when cloning them, Mb reached 512k brushes before the crashing clone. We're probably both hitting 32bit memory address bounds or something like that. As I associate more data with my brushes for texturing, my total count before a crash will probably decrease, too. 

https://pbs.twimg.com/media/Cdho17wWEAAw4js.jpg:orig

:P 

I suppose you're on Windows? Memory consumption is a weak point of TB, I have beens squandering memory to be honest. It is something I'd like to improve in the future. On the other hand, "64k ought to be enough for anybody", ask Bill Gates! 

It would be nice if the compile tools and engines adopted handling such large numbers of brushes normally... think of all the possibilities for detail modeling, not necessarily larger maps... mmh. 

the quake bsp / visportal system really does not scale well as maps become more and more detailed.

There is a reason games abandoned this model 15 years ago 

I haven't been using the alphas very often which is why you rarely get bug reports from me.
I would bug test more but I don't want to risk losing work at the moment 

One could harness the ease and expressiveness of brush-based modeling in conjunction with other ways of doing the vis work, too. I recall many approaches to these issues from lectures I've attended. BSP and vis portals are just two flavors.
In the Quake domain, there might be some room for extending the concept of detail brushes a bit, so that the compiler and engine identify complex parts that could be made into models that go through a different rendering pipeline, etc.
What I meant was a bit of daydreaming that some underlying fundamentals are changed with a lot of effort. :P 

Yes, if you mean like how the Quake 3 and Doom 3 engines have much more efficient ways of dealing with detailed brushery than Quake 1 then I agree.

Darkplaces has q3bsp support for quake 1. That's probably as good as we're gonna get. 

Thank you, I'll get back to you re dropbox. First priority is to get my primary machine up and running again. 

oops, i never use the info panel... when it went away, i just figured you made it remember i had set it off when i quit. :S 

Would you be interested in some packaging pedantry? (I can totally understand if not). Can't find the debian directory anywhere... 

Just create an issue on github. I haven't done the CMake config for the Linux packages, but I can notify flp, the person who has done it. 

I don't know if they supposed to in this version though. 

 

Those that interest me the most is definition file and texture lock state. 

Should be stored in the map file, so you shouldn't have to reset it when you open a map.

Texture lock state could be a preference. 

As I'm a a TB newb I have a quick question, does TB not have a compile / launch option? 

But this is very high on my todo list as it's a very commonly requested feature. 

What happened to the Docs? I get a 404 when trying to access it even though it still pops up in Google search. 

Am I able to scale a brush up in any way? 

But they are included in the app under the Help menu. 

Is it possible to add WAD3 support? It would be great to use TB for GoldSrc based games :D 

And it's already been requested, but it's not very high priority for me.

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

Changelog: https://github.com/kduske/TrenchBroom/tree/release/v2.0.0#trenchbroom-200-beta-0f4b6d2

Downloads: http://kristianduske.com/trenchbroom/tb2/downloads.php

Thanks to everyone involved!