Generating the map image

The basics

As part of the initial installation process, you installed the Birdseye mod by moving the "birdseye" folder into your Quake 3 folder. This mod is used to get a precise vantage point for taking a screenshot from a position far above the map, looking down. That image will be used later when building the page for the map overview.

Setup

Before using Birdseye to take a picture of your map, make sure that it is possible to load your map in CTF mode. Your map must have a red flag and a blue flag, and an info_player_intermission entity (or at least one info_player_start or info_player_deathmatch entity).

If this is your first time using the Birdseye mod, you should create a shortcut for launching the mod directly, rather than using the mods menu in Q3. This will ensure that any graphics settings you adjust while in Birdseye will remain that way for future uses of the mod. To go directly to the Birdseye mod, a Quake 3 shortcut should specify "+set fs_game birdseye" on the command line. On a Windows system, the easiest way to create such a shortcut is to copy an existing Quake 3 shortcut and add those arguments to the end of the Target entry box in its properties. (Make sure that there are no other arguments in there that set fs_game to something else.)

The essentials

When running the Birdseye mod you will be able to use a new form of the setviewpos console command, which changes your location and viewing angle. This new version of setviewpos transports you with no drifting after arrival, and with your view pointed straight down, or as close to straight down as the Q3 engine can handle.

setviewpos altitude yaw shift xshift yshift

(Note that the fourth item really is the word "shift"; you're not supposed to substitute some value at that spot.)

In the command arguments, altitude is the number of gameunits your POV will be placed above the centerpoint between the two flags (this is why it is important that your map have flags in it). yaw is the angle in degrees to rotate your view. xshift and yshift move your POV parallel to the ground; the effects of these shifts, in terms of up/down left/right on the screen, will depend on what your yaw is, as x and y are relative to the map coordinates.

If you don't want any x or y shift, you can just specify altitude and yaw and omit the subsequent arguments.

So, from start to finish, this is the sequence of actions you need to perform to use Birdseye:

After you have acquired the screenshot, convert it into JPG format, and rename it so the root of the filename is the same as the root of the map's .bsp filename. E.g. an overhead view of mymap.bsp should be named mymap.jpg. The final result must be 800x600; more about that below.

Good practices: mapping

In your map, be sure to caulk surfaces that a player cannot see, especially roof surfaces. If roof surfaces are not caulked, then the overhead view can't "see through" the roof, and the usefulness of the overview will be greatly diminished.

Good practices: graphics settings

You can arrange your graphics settings however you think best for taking the screenshot. Since image quality is the issue instead of framerate, you want to make the picture look as pretty as possible. Aside from the obvious settings that you will want to enable or crank to max, here's a few additional considerations.

To remove the HUD and place your map against a black background, set "\cg_draw2d 0" and "\r_fastsky 1".

You may also want to increase your gamma a bit, unless you normally play with a very bright gamma. I normally play with r_gamma 1.2, but I set it to 1.4 in the Birdseye mod.

Finally, be aware that Entifier will require the map image to be 800x600. So at the very least you should use a resolution that has the same aspect ratio as that. If your video card has FSAA capability, you'll probably get the best results from enabling FSAA and taking the screenshot in an 800x600 resolution. Otherwise, you might want to try taking the picture at a higher resolution and then using a graphics program with a good resize/resample feature to shrink the screenshot down to 800x600, to blur some of the jaggies. Of course, that might end up blurring other map features too much.

Good practices: dealing with fog

Fog in Q3 gets visually denser the farther away from it you get. When you're taking a screenshot for the overhead image, you're going to be really far away from the fog, so the fog will probably be impenetrably dense. For the standard use of fog in "deathfog pits", this is not a problem. However if fog actually covers playable surfaces on your map, you do have a problem, since you don't want impenetrable fog hiding important parts of your map in the overhead image. When this became an issue (like in q3wcp3) I edited the relevant fog shader and added 7000 to the last value of the "fogparms" line -- that's the distance to opacity. This made the fog much thinner so I could then take good screenshots. Such a change does not require recompiling the map.

Make sure you change the fogparms opacity back to the original value afterward!

Good practices: setviewpos altitude value

All of the Threewave overhead view screenshots were taken from an altitude of 4000 units. This should be fine for any map that fits within the original size of the editor grid -- really, for any map likely to play well in Q3CTF. It's good to use a consistent altitude value so that the relative sizes of maps can be judged from their overhead views. So use an altitude of 4000 if you can.

For larger maps that would not fit on the screen at an altitude of 4000, you can of course use a larger altitude value, but you should probably find some way to make this known so you don't confuse people about the size of your map. Adding a floating label to the map display would be one good way to share that information -- more about labels in the next section of the manual.

Good practices: setviewpos yaw and shift values

The yaw value should be chosen to place the blue base on the left and the red base on the right -- again, for consistency's sake. If the map is large enough that you have to rotate it to a "diagonal" position to make it fit on the screen, blue base in lower left and red base in upper right is preferable, because the lower right portion of the screen will be covered by the levelshot, and the upper left is a good spot for floating labels. Usually you will only have to try out yaw values on 90 degree increments, even on maps that need diagonal placement, but Birdseye is capable of using any yaw value you specify.

The x and y shifts can be used to center the map on the screen. (Remember that the x and y axes are in map coordinates; they are not relative to your current view orientation.) The map will already be left/right centered unless it is an asymmetrical map. But even a perfectly symmetrical map will not be up/down centered on the screen. This is because, unfortunately, the Q3 engine does not allow you to look straight down, so the map is "tilted" just a tiny bit in the view. If the map is large enough to actually extend to touch the top and bottom edges of the screen, play with the shift values until it looks centered. On the other hand, if it is small enough to only fill the middle of the screen, I usually shift it up by 256 units. This actually places it somewhat above the center of the screen, but I think that looks nicer than dead-center for the smaller maps.

Good practices: image quality

From such a long way up, a lot of features on the map are going to be small. So I would recommend using the highest quality setting for the screenshot JPG conversion, especially if you are going to be providing this overview for download and offline viewing. But if it is online-only, and you don't notice a loss of detail at lower quality settings, then lower quality settings are fine of course.

As a matter of fact, the overhead image does not have to be a JPG, so if you have a different image format you'd rather use (and one that will be displayed correctly by all popular Web browsers), go for it, but don't be a file-size hog.

< IntroductionAnnotating your map entities >