Andrew Smith started up a Twitter thread about Quake mapping and John Carmack is involved now talking about QBSP and various timings. Fun if you're into that sort of thing. :)

https://twitter.com/meejahor/status/948700123995009025 

The bottleneck used to be vis, then light. Then these awesome people named Tyrann and ericw made the tools threaded and more efficient. Now Qbsp is the bottleneck (unless you use bounce and extra on light).

Is qbsp threaded? Could it be?

I usually get very fast compile times anyways. Does func_detail improve Qbsp time? 

Qbsp is the bottleneck

Since when? 

Then these awesome people named Tyrann and ericw made the tools threaded and more efficient.
*waves hand* Hey, I started it! 

Good god, searching back for the original thread ...

2009?! Jesus wept, I'm getting old ...

http://www.celephais.net/board/view_thread.php?id=60365 

Is qbsp threaded? Could it be?
It's not currently.

The bulk of time in Q1 qbsp tools is spent is CSGFaces: it clips every brush against every other brush (i.e. an O(n^2) algorithm, so the qbsp run time will be proportional to the number of brushes squared).

The solution I have in mind is upgrading to quake 2's qbsp tool (backporting it to support Q1). That eliminates the slow CSGFaces function, has multithreading support built in, and it should be more robust.
(Q1's has this weird design where it converts the brushes into faces, chops them against each other, builds a BSP tree, and then re-generates the leaf contents types by looking at the faces. This is how you can get the player falling through solid floors in some cases; the fact that a volume is solid/empty/etc is only carried through the compilation process in a "accidental" way that is prone to being lost.) 

You could probably do the 3 hull generations on their own threads? Not sure if that would save any time or not ... 

I missed that stage in compiler evolution. I jumped straight from Bengt Jardrup's ol' tools to Tyrutils. Sorry Jne...willemZ.

@ericw that sounds awesome! 

Sorry to be dramatic about it. I'll be on my fainting couch if anyone needs me. 

for Quake 2 compiler. That would be a bigger improvement than any other in the last years: i made maps almost breaking several Quake 2 limits and never had to wait more than five or six minutes for a full compile. That's unthinkable in Quake even when keeping it on the original limits, going heavy on func_detail and surface lights.

Qbsp is the bottleneck

When? In which cases? I'm intrigued. Vis is still the highest time consuming one in all the maps i make by a large margin, even when i don't use func_details or go really heavy on lights (3-10 per source). 

And a map the size of texas. 

The solution I have in mind is upgrading to quake 2's qbsp tool (backporting it to support Q1)

That's sounds awesome. Beyond better compile times, would a Q2-based compile set the stage for any other new features that could be introduced down the line? (in the vein of things like func_detail, which we have now of course) 

I feel like most of the potential features are already implemented (not sure if you saw the detail variants I added last summer: link), so a migration to q2 qbsp code would be mostly speed / stability. I'd want to port over all of those current features though. 

(not sure if you saw the detail variants I added last summer: link)

Yes, I discovered those a few days ago - they sound awesome :) 

Which topic should I use for help with key bindings? 

I'm trying to create a toggle for r_wateralpha "1" and r_wateralpha "0.5" 

you'd have to bind each to a separate key. binding a toggle looks like this, btw: bind x "toggle r_showtris" 

You could use the bind-that-rebinds-itself sort of technique. E.g.

alias w1 "r_wateralpha 1; bind k w05"
alias w05 "r_wateralpha 0.5; bind k w1"
r_wateralpha 0.5
bind k w1 

that's a useful technique, haven't seen that before. 

bind k "cycle r_wateralpha 1, 0.5" 

Thanks. Also when using r_wateralpha "0.5", assuming the map supports transparent water, should r_novis be set to 1 or 0? I'm using QuakeSpasm. 

0 

"r_novis" should pretty much always be "0" (i.e. off) -- which is the default anyway, so basically, don't tinker with it. This is why:

What r_novis does, is to tell the engine to ignore vis data, which specify which parts of the map are visible to the player at any given time.

Vis (short for visibility) saves the engine from having to draw the entire map at all times (which is a waste of resources and, especially on large maps and slower computers, can slow the game down). If a map has not been designed and compiled with transparent water in mind, then the water blocks visibility, and whatever is below or above the water (from the player's perspective) is not drawn. Simply setting r_wateralpha to a value lower than 1 will not magically make the water transparent -- in Quakespasm you'll get some ugly visual artifacts.

By switching r_novis to "1" and then lowering the wateralpha, you can force the engine to display the water as transparent -- but at the cost of having the engine ignore vis data and drawing the entire map at all times.

Perhaps more importantly, maps that do not support transparent water have often been deliberately designed as such, so if you "trick" the engine into displaying transparent water, you might also end up breaking the gameplay and/or aesthetics of the map you're playing.

So in summary: only ever adjust wateralpha and leave novis alone. If the map has been designed for transparent water, it will work; otherwise stick with opaque water (i.e. wateralpha 1). 

bind k "cycle r_wateralpha 1, 0.5"

Did cycle exist in vanilla quake? o_O 

Got it. The reason I asked is because one of mfx's maps had to be run with r_novis "1" to make some funky transparent glass in the map show up properly, but that's a special case I guess. Thanks mates.