Absolutely I will use teleports, I will make everyone hate the map ; P 

I listened when you guys talked about it earlier, but I haven't used it personally ever, what is the purpose of func_detal brushes and how to use them? 

Thanks dude* 

They are used to decreased compile time. Brushes set to be detailed are usually just that - details in your level like rafters, shelving, overhangs...stuff that isn't the basic geometry of your maps. 

Thanks Bloughsburgh. But because I want to understand it practically/precise, let me do couple questions:
Situation 1:
I have a wall that made of 3-4 slices of different brushes with different textures, do I move func_detail brush over all that?

If I have a square brush which is on floor and has sliced in two parts, do I move func_detail brush over that as well.

I already use clips in some cases, but clips are used to add that collision only right? Func_detail doesn't add collision?

Sorry my bad English* 

By "isn't the basic geometry" do you mean detail that has no collision? 

by collision I mean "collision mesh/box" 

Detail brushes are included when the collision hull is created. They are just ignored by Vis.

Vis basically just calculates which parts of the map are visible from other parts. Any parts that don't significantly affect line of sight could be made detail.

However, any brush that contributes to sealing the map or contacts the unsealed area should not be made into detail. 

I should probably add that the main reason for visibility calculation is so that the Engine only has to render what is visible from the player's position. That was pretty important back when Quake was new. Most mappers would carefully monitor "r_speeds 1" for their maps. 

By visibility calculation do you mean back side of the brushes or sides that are never shown to player? But why not use skip texture then? 

Or is there something to do with this "less time more results" mentality. Maybe I didn't just get it, because I'm stupid. But it sounds like you can place func_detail brushes between walls so everything before that "cut point" are calculated, am I on right direction now? 

Just figured I'd ask before going further:

Trying to use a waterfall that is "3" models high. Preach's Tome of infinite wisdom states to have each one be 4 units back from the last.

Here is a picture of my attempt, granted it looks okay in the picture but there is an obvious seam where each fall starts in game.

http://www.quaketastic.com/files/Jam7/mjb_waterfall.jpg

Is that the intended look? Or maybe someone could steer me in the right direction. 

The basic, low-poly skeleton of your map should be made with worldspawn brushes - this will define the spaces that vis uses to create the potential visibility information for the map.

In addition to this basic hull there will be various brushes that add detail and other embellishments to the geometry.

Any brush which doesn't significantly block the player's view should probably be detail. Specific examples include:

Pillars, plinths, supports.
Beams, trusses, buttresses.
walls that don't extend all the way to the ceiling of the room.
Suspended walkways, platforms, overhangs.
Arches (e.g. build arches in such a way that when you hide the arch, a boxy hull is underneath).
Steps (create a smooth wedge-shaped world brush underneath).
Furniture and other clutter.
Rocks, terrain etc.
etc. etc. etc.

MOST IMPORTANT - do not use detail to seal gaps in your basic "map skeleton" - i.e. imagine hiding all your func_detail brushes - when these are hidden, the structure of your map should still look watertight. 

Is that the intended look? Or maybe someone could steer me in the right direction.

Yeah, that's more or less what you get. The built-in waterfall model can't be tiled into a single seamless flow. This is because the water falls with acceleration - each wave moves faster the further down the model it gets. Once you get to the bottom, you have fast water meeting slow water below. So the idea is long waterfalls get made out of several smaller steps, with the water landing on a lip and then flowing over the next.

It can look a bit off, but one thing that can help is staggering the animations of the waterfalls. Setting the frame key to a number between 0 and 25 staggers the animation, but you need to work around a bug first! The workaround is simple, set targetname to a placeholder value you don't ever trigger elsewhere in the map, like "!!!invalid-target". That way the waves aren't all landing at the same time on each one.

Another option is to make the steps more distinct by offsetting each one more than 4 units, with a little pool of water between them. This might communicate the steps better. Here's a screenshot of how that might look:

https://tomeofpreach.files.wordpress.com/2016/08/waterfall.jpg 

What's r_speeds? 

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*