So basically everything which is more complex inside my map's basic structure/skeleton and so can be set as func_detail.

So if I have a bunch of boxes in one hallway for example, which are sliced and made to be a bit different than just 32x32, 48x48.. should I check one by one that element's brushes, so every one of those parts are indivually func_detail or are talking about selecting them all making them as a ground func_detail, is that what you're saying?

But all the other boxes that are in normal shape and size (normal square 32x32, 48x48, 64x64)... are those details as well? But that would mean that most of the map is basically func_details. 

Thank you for the detailed explanation, I was hoping for a response from you.

I'll play around with it and see where it goes! 

individually* as a group* sorry my typos 

Something like this?:

https://drive.google.com/file/d/0BwxYkKdSD855N1BtbWZPaTJtSnc/view?usp=sharing 

"r_speeds 1" is a command you type in the console. It prints out info as to how many polys the engine is actively drawing and roughly how long it's taking. It's real time, so as you change position and direction, the numbers change.

In the old days you would target 800 or less and 1000 was really pushing it. Today, on a decent computer, I don't think it means much. It's probably debatable whether a full vis is really necessary.

I looked around in the map I'm working on, and with only fast vis the worst I can find is a little over 6000 polys in barely 3 millisecs, and it runs like greased lightning. 

I'm hitting around 25k wpolys on my latest map. :D

My surface pro does experience slow down in places. So if you have an equivalent of an intel 4000 graphics card it might not be optimal. 

Yes, all of those boxes should be func_detail.

Structural non-detail stuff is generally your real basic "floor, wall, ceiling" type stuff. Things like crates and other filler is not typically placed to block visibility of one major area to the next, and is a candidate for func_detail.

The compiler does not care whether each box is its own func_detail, or the whole group is func_detail - so the best option (for your sanity) is clearly to group that whole box pile as one func_detail.

But that would mean that most of the map is basically func_details.

Quite possibly, yes. 

I always avoided using detail brushes because I saw several maps that did and had problems.

I don't know for sure, but aren't there some caveats with detail brushes? Such as you can't use them to seal the map and can't have them extend into the void?

I don't really know why they were called "detail" anyway. They're not actually like detail brushes in Quake 2 or Quake 3. Those were more like Quake's func_wall. These detail brushes are more like clip brushes with visible texturing. 

Thank you very much, now it's crystal clear to me finally* 

Pros: Doesn't block vis
Doesn't add leafs
Doesn't add to vis compile time

Cons: Doesn't block vis
Doesn't seal map
Adds to max visible leafs during play 

Use of these is for the mapper only. When faced with a 4 day compile time even with 8 cores, one tends to want to use them for everything. Treat the vis like minecraft. Any angled brushes get turned into details. 

Yes obviously they can't be used to seal the map but the whole thing about not having detail brushes extending (through a structural brush) into the void is a murkier area, and I don't think I've ever seen a clear discussion of whether or not this actually causes issues and why... 

Build your entire map inside a 8192x8192x8192 box and make all your other geometry into a func_detail. It's cruise control for awesome. 

Just to give an idea how func_detail work, I've provided a few screenshots from my jam5 map with func_detail filtered on and off. The remaining brushes when they're filtered off are worldspawn brushes (save for the odd func_illusionary).

http://i.imgur.com/zhtFg9Y.jpg
http://i.imgur.com/MPNjY2M.jpg 

Got it to compile with full vis. Woop...only 11 minutes this time. I found that one particularly egregious 384 brush tetrahedron soup group was not actually a func_detail as it should be. Oops. That wiped out over 1000 leafs and 10mb of final bsp file size. Now the bsp is only 21mb. (ha yes only!) Just need to finish the lighting and enemy placement and a few areas now.

Ugly full brights (need to light):
https://dl.dropboxusercontent.com/u/20160676/quake/engine1/keep20160813204338-00.jpg
https://dl.dropboxusercontent.com/u/20160676/quake/engine1/keep20160813204414-00.jpg

Nicer half lit areas (need to light slightly more):
https://dl.dropboxusercontent.com/u/20160676/quake/engine1/keep20160813204455-00.jpg
https://dl.dropboxusercontent.com/u/20160676/quake/engine1/keep20160813204538-00.jpg
https://dl.dropboxusercontent.com/u/20160676/quake/engine1/keep20160813204655-00.jpg

Yes, sprite based foliage...in a greenhouse...in a cave. 

Looking really nice, btw how did you managed to make that glass? Could you demonstrated it in a practice, not just logical theory bullshit which doesn't tell me anything.

I have tried that two times now, I always receive annoying z-fighting in the surface. So I need to use glass* texture for brush, is that brush also func_wall or not? What then? Clip brush over it, right? What then, is that all what is really needed? 

Could someone demonstrate it to stupid noob like me. 

There are instructions with the mapjam7 bundle by Than.

But okay:

1) Grab the apsp2 wad from the jam bundle
2) Create a brush for your glass (Simple square)
3) Set the *glass texture from the wad for the square brush
4) Make it a func_wall
5) add an alpha key with value of 0.35 or 0.50 or however transparent you want your glass to be.

That's your basic glass. If you want colored ones, then you use a different solid color. 

So only thing this time was, I didn't remember simply just try to set up those alpha values, even though I made earlier glass using different texture (not *glass), putting func_wall and alpha.. reason why I get carried away, mind have been that I mentioned it here and didn't get reply for that and then I just forget.

Thank you for making it clear to me again. That time I was also messing around with skip textures which might be the reason why I received that z-fighting. I really don't want to talk about window-test.map, because I'm sure I already get it wrong, but that's just me.

Now that I have making choices in areas how to replace windows, because at time it felt like I will never make them work on time, but now it seems like utterly easy to do - I need to start re-thinking some areas. 

might have been* 

is the glass supposed to look like this, or does not glass care about about lights at all?

https://drive.google.com/file/d/0BwxYkKdSD855SlBrLVI0bzJLRWs/view?usp=sharing 

Is it possible to give func_wall key "_color", and use that the same way as in lights which chooses the color of light.. is there solid_color key even? 

This kind of glass is merely a trick. It's made of liquid, essentially. Liquids can't be lit in most engines.

That's why the texture is solid - so you don't see it warp. 

The end draws near. Who's in? Who's out? I'll be finishing up the start map in a few days, so I'd like to know how many level entrances I need to make.

Some things to note:

Make sure that your map exits to 'jam7_start'.

Send completed maps over to 'voice DOT of DOT the DOT nephilim AT gmail DOT com' when complete. 

I'm not sure I'll make the deadline, to be honest. I took a break when the deadline got extended but I kind of lost my mojo in the process, so to speak.