Full map... Make it func_detail and box it in. Basically do like you'd do in Doom3 with meshes. 

Aren't there still collision horrors everywhere? 

How long does vis take with such a map?

I imagine this style of design wouldn't lend to big maps with lots of monsters because there would effectively be no visblocking (or am I wrong?). 

Well, if it's a giant func_detail inside of a box ... VIS should be almost instantaneous. 

I imagine you're not literally suggesting surrounding it with a big box, but rather having a boxy structural hull that still essentially follows the layout of the map?

Otherwise:
(reaction.gif) 

What would be the drawback of building your map out of simple brushes, and then when you need detail that requires using techniques that often cause invalid brushes / microleaks (such as vertex editing), just adding such things as detail brushes inside the already built and sealed structure?

As an example, let's say I'm doing a section where I have rocks on one wall of a room. I'd build that wall using a simple cuboid brush that seals the room, and then add the rocks as detail brushes. Is that feasible, or do detail brushes cause other headaches? 

I'm pretty sure that's more or less how everyone has mapped since detail brushes became available. I may be wrong. 

I've heard (but not looked into it myself) that detail brushes that stick through the structural hull and into the void are problematic - does anyone know anything about this / elaborate? 

I would advise against that anyway. Build the detail brushes flush against the sealing structure.

I'm trying to put together some best practices for the TrenchBroom 2 manual. 

"I would advise against that anyway. Build the detail brushes flush against the sealing structure."

Why is that? 

Like UE, where BSP is just for blocking and the rest is meshes. 

Afaik detail brushes don't care where they are. func_ objects that are in more than one leaf, or that stick out of the world, can have the entity flicker problem though.

Details are part of the bsp though, so if you can see em, there they are.

The bug they can cause is when a mapper either on purpose or mistakenly uses them to seal a leak, inadvertently creating one.

The bad practice is making everything in the world detail, apart from your outer hulls, effectively trading off vis time for performance. This is usually unnecessary, but also kind of subjective over 'when' it becomes bad practice, depending on your geometry. 

Oh, but UE and other engines has a portal system that Quake 1 doesn't have (not that I know of). Does Quake 1 have hint brushes? 

I mean, you can make the sealing walls world and the rest detail, as BSP + meshes in UE. But you don't have any tool in Quake 1 to manually tweak VIS behaviour, like Q2's hint brushes. 

Modern quake compilers do have "hint" texture support to force a BSP split. Never tried it myself.

Oh, but UE and other engines has a portal system that Quake 1 doesn't have (not that I know of).

Darkplaces has "r_drawportals 1" which is cool for viewing the portals/leafs. There's also a gtkradiant plugin that can load prt files generated by qbsp. 

I would advise against that anyway. Build the detail brushes flush against the sealing structure.

In Q1 compilers, func_detail brushes take part in CSG (clipping away overlapping geometry) and outside filling (clipping away anything that faces the void) just like world brushes.

This is unintuitive, imho, and means you can't just build a sealing structure and completely cover it in detail, because the detail will clip away the sealing structure. e.g. If you have a long corridor and cover the floor/ceiling/side walls completely with func_detail rocks to make a cave tunnel, you'll get bad vis quality (vis will see through into other parts of the map).

otp, regarding a giant box filled with func_detail, that would be the same as unvised as far as performance in engine. In fact it would be better not to vis it so the engine doesn't waste time doing useless tests against the vis data which is all '1' (every leaf can see every other leaf). 

Just tidyness. I know that in general qbsp doesn't mind clipping overlapping brushes. However Having brushes align and not overlap makes for less visual clutter in the editor.

But that said, I wouldn't be surprised if even though it appears that qbsp doesn't care, having overlapping brushes has other ill effects esp. if entities are involved. But I have no proof of that. 

"But that said, I wouldn't be surprised if even though it appears that qbsp doesn't care, having overlapping brushes has other ill effects esp. if entities are involved. But I have no proof of that."

Yeah, there are many urban legends regarding overlapping brushes. I'm a believer that it doesn't matter at all but I know there are others who have strong feelings the other way. To me, it's a bunch of busywork to miter everything but what-ev... 

We need a barf icon. 

 

Overlapping brushes don't matter at all to the resulting hulls in my experience, i guess you talk about the case where a plane is represented by 2 or more brushes.

In that case i only care for the sides which share the plane to have the same texture alignment/ratio/angles. You get it.

Of course this may produce weird portals for vising, and the face splitting isn't always ideal in other cases resulting in lightmap errors and and and.

So better not do it if you can avoid it. :) 

e.g. If you have a long corridor and cover the floor/ceiling/side walls completely with func_detail rocks to make a cave tunnel, you'll get bad vis quality (vis will see through into other parts of the map).

I still don't get what the problem is here - you'll end up drawing more because the visibility err "chunks" are more coarse-grained, but how does that make an important difference on today's computers? 

I still don't get what the problem is here - you'll end up drawing more because the visibility err "chunks" are more coarse-grained, but how does that make an important difference on today's computers?

I think ericw is worried not that simplified visblocking has slightly worse performance, but that you might accidentally have no visblocking from your tunnel at all. In other words, there can be no difference between building detail brushes around standard brushes, and only using detail brushes for the corridor. The former case gets reduced to the latter if all the standard brushes get clipped away by the details - and it's not obvious that detail brushes pose this risk. 

I Do It Cause Im OCD Like That.

+1

ALIGNENBLOCHEN 

ericw, preach:

So are you saying that the only parts of a structural brush that can contribute to visblocking are the parts of that brush that remain visible in the map?

I kinda assumed it worked more like quake 3 where the structural brush can be completely covered by the detail.

This changes everything :(