• Don't go hog-wild with the "number of divisions" fields. Although GenSurf will allow you to produce a surface with a 64x64 grid, I'm not suggesting that's a good idea! The number of triangles produced is of course twice the number of rows times the number of columns, so in the case of a 64x64 grid that's 8192 planes on one surface alone... unless you plan to add a lot of vis-blocking architecture to your map, a surface this size will almost certainly have horrendous r_speeds. On the other hand, there's certainly nothing wrong with starting with a 64x64 grid and using the decimate function to keep key terrain features.
• Make sure the number of divisions can be evenly divided into your extents, so that the grid rectangles are all the same size. If you don't do this it won't cause any runtime problems, but you'll have many diagonals that are not on the same plane, which will cause addtional (needless) work for qbsp3. Better still, use a number of divisions that makes the grid rectangles a large power of 2 (say 64 or 128). This will help you when you're trying to line up ground surfaces with cliff walls.
• If you manually edit vertices of a GenSurf-generated surface and you use the "detail hint brush" option, be sure to remember to pull the ends of the detail hint brushes out so that they completely enclose the 2 triangles. NOTE: If you are using the "detail hint brush" option, you should not use vertex manipulation to make the surface grid non-square when it can be avoided. For example, pulling vertices of a ground surface up or down won't cause any problems, but pulling the vertices north, south, east, or west will defeat the purpose of the detail hint brushes. These hint brushes will not work very well on non-rectangular grids. An obvious exception to this "rule" is manipulating vertices to close up gaps between adjacent surfaces, as described above under Surface Intersections... yes, this method will produce some brush splits, but not as much as if the hint brushes weren't used at all.
• For smooth surfaces (or surfaces that are meant to appear smooth) in Q2-engine games, use the "ArghRad 2 value" field to assign a Phong-shading ID to your surface. Each surface in your map that uses Phong shading should have a unique ID. If you don't have ArghRad 2.0, you're behind the times! Get it here. Blocky surfaces with many sharp angles will probably have a better appearance if you do not use this option.
• For Quake 3 Arena maps and normal brushes (rather than curved surfaces) use the detail content property and be sure to use common/caulk for faces other than the surface. The current version of q3map contains one or more bugs that produce visual glitches in some complex surfaces unless the detail property is used. For surfaces that don't do much to block visibility, using the detail property will not result in any performance degradation. If you do use the detail property, use of the common/caulk texture on faces other than the surface is absolutely essential to keep polygon counts in check. If you do not use this texture with detail brushes, all sides of the terrain surface brushes will be seen by the game engine.

• Use the "Linear borders" option to force the edges of your surface to be straight lines. This will make dropping a GenSurf-generated surface into another map and getting the edges matched up with existing brushes trivially easy.
• When it can be avoided, don't overlap GenSurf-generated surfaces. You'll be better off (fewer brush splits) if you bound a ground surface with normal cube brushes, then add cliff walls around those cubes. Overlapping surfaces won't cause any big problems, but will very likely produce more brush fragmentation than a group of surfaces that don't overlap.
• If you are using multiple GenSurf-generated surfaces in the same area (for example a ground surface and cliff walls), you'll have the best results if the grid divisions for all surfaces match up. For example, if the grid lines for the ground surface are spaced at 128 units north-to-south, then you'll have the best results if a north-south wall uses a horizontal spacing of 128 units as well (and make sure these intervals are at the same coordinates).
• Do not rotate GenSurf surfaces by angles other than increments of 90 degrees, particularly if you are using GenSurf's detail hint brushes to control brush fragmentation. Rotated hint brushes can easily cause bizarre visual errors in the game. Even without using these hint brushes, a rotated surface will almost certainly contain gaps and misaligned brushes that will detract from the appearance of the surface, increase the polygon count, and possibly cause leaks.

• Qoole 2.5 is known to foul up GenSurf-created maps and produce orphan planes in the game that the player can walk through. Qoole 99 reportedly does not have this problem to the same degree, but also produces these errors. You can get around Qoole's butchery by using the -noopt command line option with qbsp3. Thanks to Geoffrey DeWan for this tip, and Rust -regulars Beelzabub and Owen Coughlan for pointing out the problem. My advice: Use another editor. Please.
• GenSurf maps sometimes produce "leaf portal saw into leaf" warnings in Quake2 maps, even when using Geoffrey DeWan's qbsp3 (which eliminates many of these warnings). However, it's Geoffrey's belief that these warnings (if you use this compiler) are only due to small roundoff errors and do not cause any of the problems normally associated with these warnings (long vis time, visual errors in the game). I've tested that theory inside and out with literally hundreds of test maps, and have been unable to disprove it. Short version: use Geoffrey DeWan's compiler and ignore the warning if it occurs.

As with so much of what I do, many thanks go to Mad Dog for providing a wealth of suggestions.

Alexander Malmberg (Quest guy and all-around Q2 genius) initially suggested the detail hint brush solution and provided the changes to qbsp3 to make this possible. Geoffrey DeWan suggested using skip faces for the ends of the detail hint brushes, to avoid unintentionally splitting other brushes.

Thanks to Geoffrey DeWan for all of his work on the Quake2 compilers. His changes have eliminated a lot of in-game errors, as well as improved the overall performance of the compilers. You can download Geoffrey DeWan's versions of qbsp3 and qvis3 here. For lighting of Quake2 maps, though, there's really only one choice: Tim Wright's ArghRad2 with it's sun features and Phong shading can be downloaded here.

The grid decimation algorithm used by GenSurf is very similar to one described in the article Fast Polygonal Approximation of Terrains and Height Fields by Michael Garland and Paul Heckbert. You can download this article and/or read up on other decimation algorithms at their Terrain Simplification web site.

GenSurf uses the Triangle code by Richard Shewchuk for triangulating a decimated grid. More information on Triangle is available from the Triangle web page, or read the paper Triangle: Engineering a 2D Quality Mesh Generator and Delaunay Triangulator by Richard Shewchuk, First Workshop on Applied Computational Geometry, ACM, May 1996.

Several guys at Rust have provided excellent suggestions, many of which have been incorporated. Names aren't named because I'll be sure to miss somebody, but you guys know who you are. Thanks, all of you.

Thanks to the folks at Ritualistic's Editing Forum for providing guidance to this new SiNner.

Thanks to trix/dhazel for providing assistance with Heretic 2 support.

The environment map used in the screenshot is by Jason Abott. You can find this and other environment maps at his homepage.

Thanks to Sean 'Zoner' Cavanaugh for developing his Half-Life compiling tools. These tools make it possible to use hint brushes with GenSurf surfaces, without which these surfaces are just about worthless in that particular game.

The Q3Radiant plugin version would not have been possible without a lot of assistance from plugin guru Timothee Bessett of MGS fame. Thanks, Timo.

As far as I know Capt Tripps was the first to discover lighting problems on curved patches larger than 512 units. Thanks to him for sharing that knowledge.

And... I've had some help from the big guys on this version. Thanks to id Software's Paul Jaquays, Mr Elusive, Robert Duffy, and Martin Ka'ai Cluney for their advice and patient assistance, and also for making a pretty fair game or two.

David Hyde rascal@vicksburg.com