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 :( 

Oh... Wow... That sucks. :( 

Well, I can't speak authoritatively but it's only logical that VIS can only work with the visual faces in a BSP as that's all it has once it starts working. It doesn't work with the MAP file, it reads and writes the BSP. 

But that doesn't make a ton of sense to me ... so if I stick a func_detail cube in the middle of a wall, that means there's a square in the wall where I can see through to the rest of the level or something, in terms of VIS? That can't be right. 

Yeah I thought about that as soon as I posted my post and felt even more confused. 

That was my interpretation of what ericw was saying, I can't vouch for it being correct. 

I just tested this. Two box rooms connected by a horseshoe hallway, no visibility between them.

Lining the walls of one room with detail brushes does indeed permit visibility into the other room. Plus, because vis is assumed to be two-way, you can see into the detail-brush-lined room from the other room, too.

A small detail brush in the center of a wall does not create a 'portal' with which to see into the other room, however. Extending that detail brush until it almost covers the wall behind it, with an 8 unit margin around the edges, also does not permit visibility.

Interestingly, I can extend that detail brush to touch the floor and ceiling, thus dividing the structural plane 'behind' it wholly in two, and vis is still blocked. I can extend it on a third side so it touches the next wall, reducing the structural plane to a tiny thin strip along the other edge, and vis is still blocked. So, if there's any fraction of a brush plane left in the world, it blocks vis as if the entire thing were there. As soon as the detail brush gobbles up the entire plane, though, it's gone completely and visibility is fully permitted. 

Theoretically, if the information of the original structural brushes was retained somewhere, could this be...fixed? 

I've just disproved all of the above with further tests!

I tried to make a showcase map with one example of each detail brush, and rearranging the hallways broke the effect one way or the other. The original test was the one horseshoe, modified and saved and rebuilt, and my first run was with no detail brushes at all to verify that vis was blocked under normal circumstances, so the effect was real. It seems to only happen in a more narrow set of cases than we'd thought.

Looking at how I've rearranged the map, the detail brush 'test chambers' are at the ends of little hallways now, and stepping into one fully closes off visibility of everything else regardless of detail brush use. I'm guessing that since there's a portal that's closed in all cases higher up the tree, that closure simply applies all the way down the branch into each test chamber and overrides any 'hole' a detail brush might make.

I'll clean this map up and put all the test cases in it, and you can just noclip between them instead. :P 

I'm posting the link in 'Mapping Help' instead so as not to further hijack the OBJ2MAP thread for detail brush debugging. 

So basically func_detail breaks the world. Neat... 

Good info tho, thanks for doing that. So as long as some part of the original structural poly remains, VIS will be intact. 

Wait so Lunaran your saying that Func Detail was not working at all like we intended it to do?