One of the most vexing problems with large outdoor areas in Quake2 is the high r_speeds and associated sluggish framerate. While the rectangular mesh used by GenSurf will generally provide lower polygon counts than an equivalent surface with randomly-oriented brushes, it still needs a bit of help to make your map playable. The screenshot below is taken from a map with a total of 461 brushes. The area is roughly 1024x1024x256 units high.

As mentioned, there are a total of 461 brushes in this map. They are all perfectly aligned and have only one face visible from the playing area. Since many of those faces are facing away from the player from a given viewpoint (and so are ignored by the game engine), many brush faces are obviously being split by qbsp3 (otherwise the wpoly count would never exceed 461). Here's the same view in software mode using sw_drawflat:

Yuck! Check out the brush fragmentation in the cliff walls. Another problem with this map is the long vis time - about 16 minutes on a P400. OK, that's not too long, but then again this is a small test map. Double the size of the map and you can expect to at least quadruple the vis time. You could try using hint brushes around each grid square to reduce fragmentation... this will work, unfortunately these hint brushes will also produce many portals that would drive vis time way up and not necessarily provide any visibility benefits. You might try using detail brushes to reduce brush fragmentation... unfortunately in the case of adjoining brushes the detail property doesn't do a bit of good (although it does reduce vis time considerably). What we need is a new gizmo - enter "detail" hint brushes. This idea is the brainchild of Quake2 master Alexander Malmberg. Basically, each grid square in every surface is surrounded by a hint brush with the "detail" property. These hint brushes are all the same size and extend from the base of the surface brushes. The surface brushes themselves also use the detail property. Detail hint brushes won't generate portals, but will prevent most of the brush fragmentation you see in the screenshot above. The next screenshot is of the same area, but using GenSurf-generated detail hint brushes:

Much, much better. And the best part of this method is that you get the vis-time reducing benefits of using detail brushes for the surfaces:

No detail brushes, no hint brushes

1585

970

712

Detail surfaces

4

0

712

Detail surfaces + detail hint brushes

4

0

318

Of course these detail hint brushes don't do anything to block visibility, since they produce no portals. Very often, though, the reduction in brush splits achieved with detail hint brushes improves r_speeds more than anything you can do with normal hint brushes. You can also add vis-blocking architecture to GenSurf-generated maps, of course, as well as add normal hint brushes to try to block vis. (Don't expect the same exceptional run times if you do this, though.)

Note that to use this method you'll need a modified qbsp3. The original qbsp3 automatically turns off the detail property for hint brushes, even if you've explicitly set that property. For Quake2, you'll need to download compiler-guru Geoffrey DeWan's qbsp3 1.07 here. For SiN and Heretic 2 maps, the GenSurf distribution includes a modified qbsp3 which replaces your existing copy. Changes to this qbsp3 are documented in the distribution files.

GenSurf 1.7 and later versions produce hint brushes for Half-Life. To make use of this feature you'll need to use Sean 'Zoner' Cavanaugh's compiling tools, available from the Half-Life Editing Resource Center. These hint brushes do not use the detail content property (since there's no such thing in HL) so compile times will be quite a bit longer than the equivalent Q2 map. However, you'll get the same benefits that Q2 maps do - much lower r_speeds due to less brush fragmentation, fewer (if any) vis errors ("leaf portal saw into leaf" and hall-of-mirrors effects). Also I've noticed fewer lighting errors when using hint brushes. I'm not sure of the reason, but hey.... I'll take it.