"When creating levels, where you have many brushes on the same plane (z axis) does the wall thickness have an effect on how Quake draws the level? Also, does overlapping brushes have any positive or negative effects on the frame rate?"

- KillMe

...as long as the connections between the brushes (where they meet) is not too thin (one pixel), it shouldn't matter.

[regarding overlapping brushes effecting framerate]...not that I know; especially if the brushes are rectilinear. When I make mountains (very non-rectilinear), I let the irregular shapes butt right into each other. BSP takes care of everything from there. The irregular shapes themselves can slow things down, but there connections to each other do not.

- Levelord

Part of the job QBSP does is to remove any polys that are either outside the level or are embedded inside solid objects. In fact, this is why it's important to fix leaks, since it can't figure out what is "outside" and what is "inside" when there is a leak.

To see what's left of overlapping brushes, just noclip and go outside the level. You'll see that the only part that's left over of overlapping brushes is the part that is visible. If you see polygons that should be embedded but are still visible, that means that they are ajoining an "air" space, and could possibly contribute to the frame rate. Filling that air space in will get rid of them.

One benefit to removing hidden polys is that they may be splitting the world, thus generating extra polys in other areas.

Here's a real world example of problems that can be caused by this:

During beta testing for Scourge of Armagon, we had a bug report about a lighting problem on one of our levels. (see pic mess1.jpg). I talked with Tim Willits at id about it and he said they had problems like that before and the best solution was to put more lights there to help cover it up. I wasn't too happy with that since it didn't really fix the problem, but it was better than nothing.

While NOCLIPing through the level, I noticed that the support that was against the wall with the lighting bug was still visible on the outside of the map (see pic mess2.jpg). It turned out that the wall was very slight (one pixel in world space) gap between the support and the wall. If the support was flush with the wall, that polygon would be removed by QBSP. Also, if the support was flush with the wall, the wall would be split differently when it was bsp'ed.

I moved the wall inward 1 unit, getting rid of the gap. When I rebsp'ed the map, the polygon was removed (see pic fix2.jpg), and the light bug disappeared (see pix fix1.jpg). Thus the evil bug report #17 was vanquished!

- Jim Dosé