commit 0aa4cef5

-It is important to be aware of some issues relating to the Q3 game engine that will impact upon your building. The 3d world is rendered as triangles (or tris) by Q3. If the number of triangles drawn at any one time starts to get very high, the game will slow down. Although more powerful computers can cope with higher tris numbers it is still advisable to try to keep tris at around 8000 at any one time. More about tris and how to control what is being rendered later. The other important point to consider at the moment is the prevention of 'leaks'. Leaks are when your world has a hole in it through to the void outside. Your level must be completely contained and sealed off from the outside otherwise you will create problems for your self later on. Good brushwork will help prevent leak spots in the first place, but GTK also has a handy feature called pointfile which can be found under the file menu. If during compile it is reported that your map has a leak you can click on pointfile. This draws a red line that shows you where the whole in the outside of the map can be found, making fixing the problem much easier.

-Right, let's do some building! Firstly open up the editor. Then you will need to select a texture to draw with. It is good practice to draw objects in the caulk texture. Caulk is invisible in game, but also solid so it has the effect of not adding to what Quake 3 has to draw on the screen at any one time and also preventing the inside of your world leaking through to the void outside.

-Now we're ready. In the 2d window, the large black one in my set up, we are going to create a 'brush'. Brushes are the blocks from which the worlds we create a made.

-Draw out a brush in the top down (yx) view 1088 by 1088 units. That's going to be our floor. In the zx or zy view adjust the thickness of the floor to about 24 units.

-In the top down view draw out a brush that fits exactly along the edge of the floor area. Make sure the brushes are right up againt each other. Use your mouse wheel or insert and delete to zoom in and out and right click and drag in the 2d window to move your work area around. This way you can inspect what you're doing very closely. In the side or front view pull up the wall brush to 192 units. Make sure the bottom edge of the wall sits against the top edge of the floor, no overlapping it at all.

-As I said before the caulk texture is invisible in the game. Not a lot of point in creating a room we can't see, so the next step is to paint or texture the insides of the area. As rule of thumb, only texture what will be seen by the players in game. This way we can save valuable tris.

-Having selected the face we want, lets add a texture

-From the texture menu load up gothic_floor. Select the face of our floor brush then click on the largerblock3b4 texture. The caulk will change and the brush will now be textured. Now load the gothic_block textures and texture the inside faces with the killblock texture. Now open the skies texture folder. See how some of the textures have white borders. That means these textures have shader scripts. In game these textures will have a special effect (in this case they are skies). Select the inside face of the ceiling brush then texture it with hellskybright. A useful texturing technique is after you have textured one face use Ctrl shift middle click to apply the texture with the same alignment to other faces.

-Press the 90 on the little box of squares. This rotates the starting point so that the player begins facing toward that direction. It's not really a problem in a large room but you don't want to spawn in game facing into a wall!

-To begin we will cover the basics of clipping brushes. Clipping, or cutting brushes is the primary means of shaping geometry available to the level designer and therefore is perhaps the most important tool to get to grips with.

-As with most functions in the editor it is best to keep the grid snap as high as possible, once again keeping thing neatly aligned to the grid will save a lot of frustration. Lets get underway then. As illustrated in fig.1, draw out a brush. Size here isn't really an issue.

-Easy isn't it! You can clip through multiple brushes stacked on top of each other too. Remember though, keep thing aligned to the grid!

-Lets talk about using the clipper tool for building levels tidily and for optimal performance in game. Imagine you want to build a wall with a hole through it. Well you could do it as shown in fig. 4 below

-Lets look at using curves or *patches.*

-Using curves to good effect can really make your level stand out but there are some things to be aware off. Firstly they are not solid like brushes, this means that you can't seal the world off from the void with them. If the the patch forms part of your outer wall you will need to fit  caulk brushes behind it to stop leaks (see fig.15) Use the caulk texture as it isn't drawn in game, hence eliminating over draw and any chance of z-fighting (where more than 1 texture is drawn in the same place, causing an ugly mess in game). Secondly, patches use up a lot of tris, very quickly. Having a lot of patches can cause your map to run slowly!

-Detail and structural brushes, so what exactly are they and how should we use them? Structural brushes are solid, they block vis and seal the world off from the void, detail brushes are solid in game, but as far as the compiler and game are concerned they do not block vis, nor can they seal the world off from the void. To make a brush detail, select it and press Ctrl m, to make a detail brush structural select it the press Ctrl shift s. By default all brushes are structural. Why should we worry about all this? Well, a complicated map could take a long time to compile vis. We can shorten the time it takes by making all the outer brushes that touch the void structural, and everything else that isn't needed for blocking vis into detail. If we make our rooms and corridors out of nicely rectangular structural brushes applying hint brushes is also much easier as the splits created by the hint brushes are not effected by detail brushes.

-N.B. toggle details on and off Ctrl d

-toggle structural on and off shift Ctrl d

-toggle patches on and off  Ctrl p

-Remember how in the first tutorial it was stressed how brushes shouldn't over lap? Well, with detail and structural brushes we can or even must break that rule! Here is another shot of the same room with detail and structural brushes both turned on. See how the caulk structural brushes are drawn on top of the detail brushes in many places? This doesn't matter, caulk isn't drawn in game.

-Examine the corridor below. The complex shape is all detail brushes. Buried in the walls and floor are simplified caulk structural brushes brushes. Vis only considers the simplified brushes. Because the caulk brushes are never drawn it is not necessary to worry about t-junction errors either. Structural brushes made from caulk can be slapped down quickly. Only the detail brushes with textured  faces, or structural brushes with textured faces need to be optimised in the way discussed in tutorial 2.

-It is important that the caulk brushes do not stick out into the world, if they do and can be seen in game they may create visual distortion.

-Having talked about *how* we are going to build now lets talk about *what.* The next stage in the building of our map is to come up with a layout. Deciding a layout depends on many things. In this case theme will not be an issue. In order to make the process as straight forward as possible I'm going for standard id Gothic, although later we will be using some custom textures and shaders. There are certain factors in layout we can not ignore. The level must be built with vis blocking in mind from the out set. The scale must be correct, average corridors would be 192 units in height and width. Let the texture sets be your guide, wall top and bottom trims are 32 or 64 units high, wall textures are 128 units high. The level must be playable for humans *and* bots. The level must be appealing and attractive whilst running smoothly and fun to play. Leading on from fun to play, there must be a high degree of connectivity between areas, with out losing control of vis. The classic Death Match level forms a closed circuit, whilst a CTF map consists of 2 normally identical bases with all routes in and out leading through a central 'choke point'.

-The brief for this level was to design a Death Match level that could easily be turned into a CTF map later. Hmmm. Not exactly mutually compatible, but lets get started!

-Lets get to it then! The following are some in game shots from the alpha build. Fig.1 is the room we created in the first tutorial with some slight alteration that we can come to in a moment.

-The other points of interest in the alpha build are jump pads, teleporter and the pits of death. Lets look at each in turn.

-Lets talk about the changes I've made our original room(fig.16 and figs 1 and 2)

-Lets start to add some architecture!

-Figures 22 and 23 below show how verts should line up between the curved patch that makes the arch and the surrounding brush work. Remember brushes should meet at corners and vertices of patches should meet the vertices of the brushes they touch, otherwise 'sparklies', or t-junction errors will occur in game.

-Sometimes when you add patch trims even though vertices align perfectly in the editor, in game holes or tears appear when the geometry is rendered. These are known as LOD (Level of Detail) cracks. These errors are caused by the Q3 code itself in the way it calculates the drawing of curves. Small LOD cracks can be stitched by the game, but some will be quite visible. Luckily there is a solution. Through the use of Ydnar's mighty Q3map2 it is possible to convert compiled .map files into .ase model files. As models are rendered differently by Q3, they do not suffer LOD cracking. Fig.26 and Fig.27 show 2 areas where .ase models have been used to solve this problem. Fig.26 shows an endcap with patch mesh trim that cracked, Fig.27 shows a group of vertex edited square cylinders that also exhibited this problem. I should point out that using square cylinders can be expensive in tris. Often other geometry gets embedded inside part of a cylinder or square cylinder, wasting tris. Z-fighting will tend not to occur in game as the player can not see inside the cylinders. Using 4 (or more or less) patch meshes to do the same job as a square cylinder would be much less wasteful in valuable tris, as the patches could be edited so that  no overdraw occurs. In certain places I would choose a square cylinder over patches as in spite of their problems when drawn in game they have a lovely smooth and rounded appearance to their edges, which patches do not have.

-In previous tutorials we have covered basic patch manipulation and touched on more advanced techniques. In this section we will look at more approaches to using patches. The merits and draw backs to using square cylinders (draw out a brush, with it highlighted, drop the curve menu, select *more cylinders*, then *square cylinder*) have been discussed previously. In fig.1 a square cylinder is being used to create a flying buttress style of support. A brush has been clipped at an angle to form the top of the buttress. The brush is a few units wider than the square cylinder we are going to manipulate. Create a square cylinder  and rotate using the tool bar buttons and move into roughly the correct position. Engage vertex mode (press v). Click on the verts (or drag a selcction box and select a groups of verts) you want to move and manipulate the cylinder into the position shown below. Make sure the cylinder is a little narrower than the support it ends in and the brush forming the top of the buttress. Don't worry about the cylinder entering the brush, that will not be seen in game. Press shift s to bring up the patch texturing inspector and hit natural to align the texture. Heavily manipulated patches can warp detailed textures, so it is generally better to keep the textures you select for your patches fairly simple.

-In several places around the level you may have noticed sharp, dramatic shadows being cast upon the surrounding geometry. Unlike newer games, Q3 has a static lightmap. Shadows are not cast in real time, they are pre-calculated during the compile of the level. If you run a level in devmap mode (type `/devmap` *mymapname*) then type `/r_lightmap` 1 at the console, you will see the level's lightmap. The geometry, apart from non-lightmapped shaders, will be white, with the shadows, light and colour burnt into it clearly visible. `/r_lightmap` 0 returns the map to normal. This lightmap is rendered onto the textures you apply to your geometry, so in a way, all textures in Q3 are blended shaders. Just because Q3 doesn't have dynamic (real time) lighting (how to fake dynamic lighting is covered later in this tutorial), doesn't mean that it can not rival the newest games in terms of realism and beauty. So how can sharp shadows be cast? The key is the use and positioning of your light sources, whether that be, shader or entity in origin. Try to shine light through interestingly shaped geometry, where it can be cast on to an appropriate surface. In fig.5 the area under the central archway is shown. I have placed a light ent inside the little lamp brush model I made, so that light is cast through the lamp, falling onto the curved arch ceiling. If you were to compile the map with the arrangement I described, the result would be disappointing. No crisp, clear shadows would be present. So how is it done? The final thing to do is to increase the resolution of the affected geometry's lightmap. Select the geometry, drop the entity menu. First select ungroup entity if patch groups are chosen, the select func_group. Bring up the entity editing window (press n) then add the key _lightmapscale, and a value less than 1. 0.125 is very Hi Res. Be aware that many Hi Res lightmaps will bump up the size of your .bsp considerably.

-Let's return to more advanced patch work. In the base area ceiling I have constructed a dome with a patch of sky visible at the top (fig.6). It is those little details that perhaps most players wont even notice that set the look and feel of a level. Interesting ceiling work, just as interesting floor details are what sets a map apart from the crowd. So how is the dome created? Select your texture. It is important that texture is not detailed or busy, as some distortion is unavoidable.

-We are going to make a quarter of the dome at a time. Firstly create a bevel. Then naturalise the texture (fig.7). The dimensions of the bevel don't really matter. The important point is to keep things square. In the sample map the quarter section of the edited dome bevel is 184 units wide and long, and 104 units high. It's best to align textures now, as naturalising heavily vertex edited patches can really mess things up. Now bring up vertex edit mode.

-Nearly there. Now lets create a square cylinder, arrange it in such away that it sits with the top edge of our dome section halfway through it. Then vertex edit the cylinder to fit around the top of the bevel, as shown in fig.10 below. Naturalise the texture on the cylinder.

-As discussed in a previous section of these tutorials, Q3 uses shader scripts to create special effects with textures. In very simple terms textures are blended together or manipulated in some way to create the required results. The Q3 Shader Manual offers the definitive guide to writing shaders, and in a later section of this series we will cover how to add your own custom shaders and textures to maps. Sometimes using a shader to achieve an effect is far easier than creating complicated brushwork. One of the best examples of this is grates or fences. Examine fig.1 below. Shaders are identified in GTK by a white border around the texture and [] around the texture name. Remember the image in the editor is only a representation as far as shaders are concerned. The grate shader used below looks solid in the editor, only in game are the transparent parts visible. Because of this it is necessary to have some idea of what each shader does before you can use them.

-So how is it possible to get new textures into Q3? Quite simply, locate the texture folder under the baseq3 folder. Into the texture folder place a new folder. It is good practice to name the folder *mymapname*, where *mymapname* is the name of your level. Into this you place the textures you want to use in the level. The exact details concerning Q3 textures will not be discussed here, other than to state that they must be either .jpg or .tga. By placing all your textures in one folder, you make it less likely that something will be missed out of the .pk3. Inevitably textures are drawn from several folders, but it helps to be organised.

-In order to avoid ugly 'spotting', where strange pools of light appear, do not place light ents too close to geometry. More light ents, with lower light values, generally give better results than single entities with high values. Try to use a sky that suits the look and feel of your level. Experiment with different skies to try to find the correct brightness and sun angle, choose a texture that gives you the required brightness and the most interesting shadows.

-Although the images in fig.1 and 2 can not depict dynamic lighting in a still picture, both these areas use this technique. The flaming torches would emit a flickering light, so it seems reasonable to try to recreate that effect. Be careful in the use of dynamic lighting, as with all shaders, over use impacts upon performance in terms of a loss of frame rate. Also, any one surface must not receive light from any more than 4 dynamic light sources.

-A light ent is created or selected in the normal way. Bring up the entity editing window and add the key *_style* and then a value of your choice, normally somewhere between 1 and 12, in this case 10 was selected, see fig.3 below. Some experimentation is required to achieve the look that is required.

-Fairly simple so far? Things get a little more complicated now. When the map is compiled Q3map2 generates a custom shader and texture folder, used in game to achieve the flickering light and shadow effects. The texture folder, which will have the same name as the map, is placed automatically in the maps folder and the shader, named *`q3map2_mymapname.shader`*, is placed in the scripts folder. Both the texture folder and the shader must be included in the .pk3 for distribution, just like other custom map content. Each time the level is compiled the texture folder and shader are updated, so be careful to include the current versions of the textures and shader with the .bsp (the compiled map).

-Sometimes it may be necessary or desirable to have the light source some distance from the area where you require the light to fall. This 'spot light' effect can be achieved by targeting a light entity at a target_position or an info_null entity (fig.4). Create the light ent, then create the info_null (under *info*, in the entity menu). Select the light, then the info_null, next press Ctrl k to connect the entities. Unfortunately GTK can not show lighting effect in real time, so it is necessary to compile the map in order to observe the effect you have created. Sometimes it may take 3 or 4 attempts to achieve the result you want, adjusting the strength of the light source and the distance and angle from the info_null.

-A good test for where to apply clip brushes is to compile the level as a test, and run around the walls in the map. If you become snagged at any point, that area requires smoothing out with the clip brush. It is perfectly fine to overlap clip brushes. They are not visible in game, so optimising clips in the same way that is required for rendered surfaces is not necessary. In fact, the more simplified clip brushes are kept, the better, in most cases.

-Often bots will not act in what would seem like a logical manner at all. Some areas may not be visited or certain jump pads ignored. The solution is tweaking, tweaking and more tweaking (fig.6). Bots do not like to use jump pads where 'air control' is required. Step onto the trigger and see where you end up. The jump pad should place you neatly at your target level, if you need to move in the air, bots will struggle, or ignore the jump pad. If the path connecting the trigger to it's target passes through any solid geometry, this also can cause bots to reject the jump pad. Try adjusting the size of the trigger brush, this can also influence whether or not bots will use the pad. Sometimes bots will refuse to visit a certain area. This can be a result of small clusters, more about that later. Ensure the ignored area is clipped and smoothed, so there is nothing that might be confusing the bots. The items you place in a map will encourage bots to circulate, just as real players. Try to scatter items, like a paper trail, for the bots to follow. Apart from at jump or launch pads, bots will not go for suspended items. Having an understanding of individual bot behaviour can be helpful. One particular bot may handle certain aspects of a map better than others, but this is largely a case of trial and error. Knowing bot preferences for weapons or items is a definate help. Placing a Super Shot Gun in an area in a map where Bones is included as a bot, will almost certainly encourage at least one bot to visit that area! If, despite your best efforts, bots still refuse to enter an area, or use a corridor, try inserting an item_botroam or two (fig.7). Item_botroams are bot only entities, they can be given a key of*weight*, and a numerical value. The higher the value of the key set, the more the attraction to the bot. Much care is needed when using botroams. Play can very easily become unbalanced if you set the value too high, or not alter in the slightest, if you set it too low. Unfortunately item_botroam entities are always on, there is no respawn time after a bot has collected them, this can cause constant revisiting of the entity's location. Placing an item_botroam on a jump pad trigger sometimes causes bot to repeatedly bounce up and down like they were on a trampoline. Setting a high value to begin with is generally the best approach, start with 400. Much recompiling will be required, but then adjust the value until bots act reasonably sensibly. Try to use item_botroams as a last resort, if all else fails, rather than as a first course of action.

-2. Use a targeted entity to connect the clusters. If you don't require the entity for game play reasons, then place it in such away as players and bots can not get to it.

-Although fairly highly detailed, the sample maps have been built with vis blocking in mind. The main areas are separated by solid vis blocking structures to prevent too much of the entire level being drawn at any one time. In a previous tutorial problems resulting from the 'sky bug' were discussed. If more than one area occurs in the same vis leaf node, it is possible to observe partially rendered geometry from one region through the sky brushes of another. Building with this in mind it should be possible to prevent this from happening, however a small error was made and it was possible to see part of the base area roof from the centre area. Although annoying at the time, it is useful to discuss the solution here as it directly effects vis control. Firstly, however, let us take a look at hint brushes, the reasons we need them in the sample map, and where they are placed.

-Having identified a problem with vis, how can the situation be improved? If you have read Bill Brook's article then you will already know the answer. We are going to use the hint texture to create artificial splits in the bsp tree. Brushes textured in the hint texture are structural, but invisible and non-solid. A common misconception is that hint brushes block vis themselves. This is incorrect. The job they do is to manipulate the vis calculation process by creating portals that otherwise would not exist. Where the vis process calculates that 2 portals can not see each other, culling will occur in game. This is a simple theory, yet sometimes much harder in practice to achieve. Fig.2 below shows the corridor that needs attention. All the detail brushes are filtered out as they have no effect upon vis. In the 2d window, examine the 2 selected brushes, marked A and B. The faces of the 2 brushes are cut on EXACTLY the same angle and meet at the corner of the corridor where it is intersected by a wall. Both brushes are made out of the common/skip texture, with only the angled faces textured in the common/hint texture. Common/skip is the one advance not covered by Bill Brook's tutorial. Skip informs the compiler to ignore any part of the brush that is textured by it. In this way only the faces textured as hint will cause portals avoiding unnecessary portal creation, as would happen with the original method. The down side of using common/skip is that only GTK 1.5 will filter skip/hint brushes out when you try to filter hint brushes from the map. Renaming the skip shader *hint_skip*, is one way around this. As both skip and hint are compiler only shaders this will cause no problems with missing textures in game. If the angled faces of the 2 hint brushes are not on the EXACT same angle their effect will be lost. Both brushes must end right up against other structural brushes, and they must meet right at the corner of the corridor. The compiler will calculate that the portal created by brush A could not see the portal created by brush B, and vice versa, therefore culling the map beyond.

-In the *maps* folder are placed the .bsp and .aas files. In the sample .pk3 the .bsp and .aas for both the FFA and CTF versions have been included. The source .map files are not normally required, but because they support this series of tutorials their inclusion is essential in this case. There are also 2 folders containing a number of .tga art files. These folders were generated by Q3map2 as part of its computation of dynamic lighting effects. In order for in game textures effected by dynamic lights to be shown, these folders must be included.

-Into the *textures* folder go any custom textures used, placed in side their folders. A common mistake is to fail to include textures from the *`mapmedia.pk3`*, which came with GTK and was not distributed with the original game. The confusion arises because the textures in the *`mapmedia.pk3`* will be included in the standard id texture sets. The importance of testing the level in a clean install of Q3 can not be stressed enough.

-The image shown as the map loads is placed into the *levelshots* folder. Do not make the image too large. A 512 by 512 pixel .jpg is normal. If the image is excessively big the over all size of the .pk3 increases with little benefit and the skirmish menu can start to lag. A useful trick for taking good screen shots is to turn off the gun and all 2d in game icons, *`/cg_drawgun` 0* and  *`/cg_draw2d` 0* entered in the console will have the desired result. The same commands followed by 1 will restore the gun and icons.

-Most mappers have 2 installs of Q3. One contains all the collected custom content, the other only the original .pk3 files that came with the game and its subsequent updates. Always run the new .pk3 in the clean version of quake. If you have missed any textures or shaders out of the .pk3, this will highlight the problem. The console reports errors. Drop the console and type */condump* *`mymapname.txt`*, locate the *`mymapname.txt`* file in your Q3 directory and open it. The console read out that you have just saved will inform you of what the game can not find. Add the missing files to the .pk3.

-At several points throughout this series of tutorials it has been mentioned that the map is intended to be converted to a Capture The Flag Level. This section deals with that process.

-Make certain you have nothing filter off. Before we make a mass selection, select and hide geometry on the existing base side that already exists in the area we are intending to place the cloned base. Delete the closed door ways that blocked of the un-built routes in the FFA version of the map.Draw out a large brush over the existing base (fig.2), then press the select inside button on the tool bar. Press i to invert the selection, then h to hide. Tidy up the parts of the base we want to select, hiding each brush that we do not want to select. When only the parts of the base we require are left, press i to select all (fig.3) and un-hide the rest of the map. Now for the tricky bit, hit the space bar to clone the base. Switch to top down view, if you haven't already. Rotate the selection 180 degrees. Hopefully GTK will not have crashed at this point.

-Now we have 2 neutral coloured bases. Not much good for red and blue teamed CTF games. Blue and red versions of the textures used, or suitable replacements will need to be applied (fig.6). Again, selecting an area by the select inside button, then using texture find/replace is a fast way of doing this. The only long winded part of the process in the sample map was needing to make 2 new .ase models for the bases as it is not possible to retexture the neutral coloured models like normal brushes. To add to the overall effect, the colour of the base light entities should also be changed to reflect the teams colour. Target_location messages should also be altered.

-After completing the main maps and the supporting tutorials I was aware that a number of entities had not been covered. In this article the entities func_rotating, func_bobbing, func_door (including areaportals), func_train and func_plat will be examined, in addition to using triggers and traps. Open `dk_lmtutmap2.map` for examples of the entities that are going to be discussed. Remember the shortcut Ctrl Alt and left click to select func_ entities.

-Normally jump pads or steps are used for ascending levels in Quake 3. At times, however, it may be useful to use a platform that rises and falls. Platforms can be triggered by another entity (in this case a button), or will work automatically when a player steps aboard. Create and select the brush or brushes you intend to create the entity from and select func_plat. Bots can be rather stupid about running underneath platforms. This can be easily avoided by including as part of the entity a player or bot clip brush that at the platform's highest point completely fills the space below to the ground. Edit the entity's properties. Platforms are drawn in the editor in the highest, raised position, but spawn in game at the lower point. A slow rising platform can be used to reach more powerful items quite effectively. Adjust the *height* key value so that the platform sits neatly on the floor in its lowest position (subtract the thickness of the visible part of the func_plat from the total height from the top of the entity to the ground). The most significant problem with func_plat entities is the absence of sounds in the original distribution of Quake 3. To this end, replacement sounds must always be included with any map that uses this entity. Examine the sample .pk3. It contains a *sound* folder with a *movers* folder within and a *plats* folder inside that. Contained within the *plats* folder are the *pt1_start* and *pt1_end* .wav files looked for by the game.