You know that func_detail exists, right? 

I tried making all the beams, thin pillars, light fittings and small wall details on my map func_detail the other day and the compiler was just having absolutely none of it. (txqbsp or tyr's bsp) The brushes werent showing o the mp at all, it was like I had deleted the lot. It took me hunting for an autosave where I hadn't edited it yet to get it back to normal. Something I did notice was that when it did work on some wall text I added: whichever engine I was using to play (darkplaces or ezquake) with refused to draw it ater a certain distance. 

You know that func_detail exists, right?

Yes.

You know a func_detail isn't the same as a Quake 3 detail brush, right? 

oGkspAz,

In Quake, func_detail only has one real use. It excludes the brush from the vis process. This can greatly speed up vis if you have a lot of small brushes that do not really block the player's view.

My understanding is that they can cause the problems you are seeing when used to seal the map or if they protrude out into the "void".

I could be wrong though, because I generally don't use them. If I had a map that took more than a few hours for a full vis, I might reconsider, but I don't think they make the final result any better. 

"It's too bad they contribute to the 256 model limit. Is that impossible to change? "

This still exists? Even in expanded/enhanced engines? 

I'm sure it's not a hard limit anymore. FitzQuake will print a warning for over 255 models but the map will still run okay. I'm not sure Quakespasm even bothers with the warning. Maybe it's limited in the network code? 

Perfect, thanks.

Think I confused two "splits". Func_detail allows you to let brushes out of VIS computation, so they don't split (1) 3D space, regarding Binary Space Partition. But makes perfect sense their brushes still split (2) other brushes' surfaces, or the engine would have to know about them in runtime for proper sorting. In this case, shaded func_walls come to hand, but you better not abuse them.

oGkspAz are you sure you didn't just checked one of those "not in easy", "not in deathmatch" etc by accident? 

Q2/Q3 detail brushes don't split polys/space, but I don't think that was possible in Q1 due to a bsp structure limitation I also don't understand and won't try to describe.

I'd love to hear a cogent explanation though. 

func_detail isn't like any other func (except func_group). It doesn't carry through as an entity into the game, it purely exists as a compiler directive. It's a fake func. Making the classname worldspawn_detail might have technically been more accurate.

Q2/Q3 had a 'detail' flag in the .map format spec, which won't be modified for Q1 editors and tools because of reasons. There's occasional discussion of using the q2 or q3 .map format (or even the q3 bsp format), but it never leads to any movement except in wacky topheavy ports like Darkplaces which can load Megaman levels and includes quakeC builtins for running SETI@Home. 

the new edict limit is like 32768.
in fitzquake, i think you may have to explicitly set that with max_edicts "32768". quakespasm too maybe. 

I tried hacking qbsp to make func_detail not split world polys. The result was you could shoot through the func_detail things (bullets are collision detected by doing bsp traversal of hull 0). That change must have broken the bsp tree construction somehow.

q3bsp, I think, stores all of the original map brushes in the .bsp file, and uses those for collision detection. 

What? No. no way. then decompiling would be only a matter of extracting the right lump and writing it to .map? 

q3map2 has an option for decompiling:
https://en.wikibooks.org/wiki/Q3Map2#Decompiling_into_a_.map

I checked out the code to see if it was doing anything interesting, and it's pretty much just "open the 'brushes' bsp lump, write each brush to a .map file" 

http://www.mralligator.com/q3/#Brushes
I had no idea. 

Here's a picture that shows the difference between a world brush, a func_detail, and a func_wall.

Those are 16x32 octagons placed against a flat wall.

The func_wall is in the middle. Notice how it doesn't cause the wall behind to get chopped up.

http://quaketastic.com/files/screen_shots/WallvsDetail.png 

BTW, that's in Quake.

Most of the time, a detail brush in Quake 3 will work just like a func_wall in Quake. 

quake 2 also has the brushes. This is how they are able to support collision for arbitrary sized entities, rather than using N number of "hulls", one for each bounding box size. 

guess you learn something new every day

are the brushes linked to the tree at all? how's the space searched efficiently? 

when is the best situation to use func_detail? Does it have any impact on the end user or does it only impair compile times? 

The impact on end user is a level portalized in a more rational way. Visibility will be based on walls enclosing the room, not the six uber detailed pilars or the chandelier inside it, ones you will carefully turn into func_detail. Someone correct me if I'm wrong. 

adib - No, that's right. You should func_detail anything that will create a ton of cuts and portals for no real benefit. 

As far as I know, the only reason to use func_detail is to speed up vis. If done correctly, the player will have no idea that they were used. Do it wrong and the player will see brushes start disappearing. Func_detail brushes have no effect on how qbsp chops up the brushes. 

That sounds like the issue I was having with my text shaped brushes on the one wall. 

As far as I know, the only reason to use func_detail is to speed up vis

Actually, is there a run-time benefit too? e.g. let's say you have a huge and detailed map - it's better for performance to have fewer visleaves (with more polys in them) than tons and tons of small visleaves, right? I'm guessing func_detail results in less visleaves? 

tyrutils qbsp (and I assume rebb's as well) uses knowledge of which faces are func_detail in its bsp heuristic; it will try to use non-detail faces to divide up volume in preference to detail faces.

That might give a more optimal bsp tree, but aside from that, using func_detail creates just as many visleafs as not using it, so I wouldn't expect any difference at runtime.