Map design hints


Not only aesthetical, but also technical issues must be considered when designing a level. A BSP tree level contains of surfaces that intersect each other. The edges and vertices are not taken over by WED, but calculated from the intersections. The advantage of this concept is that you can overlap blocks - the invisible intersecting parts are clipped off by the build process, and new edges and vertices are automatically placed at the intersections. This makes rendering much faster, because the invisible overlapping parts of blocks aren't rendered (other engines would just render all blocks over each other). The disadvantage is that small angle differences can lead to large vertex position differences. If surfaces touch or intersect at a very small angle, inaccuracies of only 1/100 degree can move the joining edge position by several pixels, which is really visible in the level.

For this reason, don't use extremely narrow, elongated, or acute blocks. Do not create blocks with edges smaller than 2 quants. Always try to design your map with as less surfaces as possible, and use as thick blocks as possible. Sometimes you can't avoid surfaces touching at small angles - but even then there's a bad way and a good way to do it. For instance, if you have a sloping road over a hill (side view):

Bad design: uses long thin plates, and small angle inaccuracies in the marked joints will be visible as 'gaps' or 'steps' from above.

Good design: 3 blocks with 13 surfaces instead of 5 blocks with 20, and angle inaccuracies, even if they occur, won't be visible.

Angle inaccuracies are less significant when using the High Prec mode for building your map. This comes at a cost, the building time and the WMB file size will increase in High Prec mode. If you use 3rd party software like Gensurf for creating map based terrain, you are sometimes forced to use High Prec mode for avoiding gaps and cracks in the surfaces.

Some more level design hints:

• Use the snap to grid function whenever possible. Blocks that are aligned to each other, and have perfectly vertical and horizontal edges in all three windows not only look better - they are also compiled and rendered noticeably faster.

• Each level should also be surrounded by a sky box. A sky box is just a very large hollowed cube with a sky texture (or any other texture) assigned. The level sits inside this box, like the office.wmp level.

• Use the Detail flag for small blocks that don't obscure visibility or need collision detection.

• Keep your map small. The closer to the center of the map a block is, the more accurate it is rendered. When you really need a large map, like for a city, use blocks only for gross structures like buildings, and use entities or detail blocks for details. Otherwise, visible errors can occur at large distance from the origin. They can be avoided by setting the d3d_nobsp flag in the engine, but better avoid them by design.

• For all non-visible surfaces - like the bottom side of ground plates or the sides of water blocks - mark the None flag. This will not only compile faster, it will also save valuable texture memory that would otherwise needed for the shadow maps.

Compiling

Compiling a map can take WED from some seconds up to many hours or even days. It depends on the design of the map, and on the number of blocks and lights used. It's a square dependency - that means if you double the number of blocks, building normally takes four times as long. An indicator for the build time is the number of portals displayed during the build process. Portals are the planes that separate the regions (sectors the BSP process splits the level into). Each surface of a block can generate a splitting plane, and thus produce one or more portals. Scaling a block can increase, or decrease the number of portals.

If you get more than 5,000 portals, try to reduce your level - e.g. by replacing prefabs by map entities or Detail blocks. If you really want to build extremely huge levels, your PC should be equipped with a lot of RAM - we recommend at least 128 MB for up to 10,000 portals, and 256 MB for 15,000 portals. The preview mode builds much faster, but then the WMB file is not optimized, resulting in a lower frame rate, and the shadows are not so smooth. The shortest build time is achieved by marking Test Map and Preview simultaneously.

Levels should be compiled with Preview during development, and without Preview for the final version. Each printed dot in the portals and the visibility calculation means 20 portals, so you can see how much dots will still be needed. The time per dot can't be easily predicted, though, and will be much larger for the last than for the first dots. If you have a very large level, but don't have the time for final compilation, compile with Preview off, but Test Map on.

Errors

Sometimes you'll encounter warnings, sometimes even error messages when building your map. In the latter case the WMB file won't be produced. You'll find a list of warning messages in the reference manual. The errors are usually caused by problems in your maps. A few of the common obvious mistakes on map editing are

- editing the WMP file manually
- assigning water, sky and normal textures to the same block
-
exceeding the maximum number of blocks, surfaces or textures allowed

Sometimes those problems are not so obvious. As mentioned, WED doesn't like very narrow, elongated, or acute blocks, like extremely long thin plates. They may not only produce visible 'holes' in the level, but also gaps in the collision detection hull. Also avoid small angle differences between blocks. If you get a warning message, you can ignore it; warnings normally are not harmful to the level. But if you see a visible fault in the level, try to find out what the problem is, fix it, and re-build. Mostly the problem is connected to a certain block number. Use the Find Block command to examine the block in question. It may happen that after deleting a suspicious block, another one will show up with the same warning. The build process issues only one warning of the same kind at a time, so if there are dozens of faulty blocks, only the first one will be announced.

Another type of error messages may be caused by a too huge or too complex level. Such errors are indicated as 'Map size - too much blocks', 'too much surfaces', 'visibility list overrun' or the like. In that case the solution is painful, but simple: remove a couple of blocks, or a building. Otherwise there will be not enough memory for the level. If you really need a level such huge - like for building a whole city - you can try to split it into several map entities and build them separately. Then place them together into an almost-empty level that just contains a sky box, and a ground plate with sun light activated to avoid fullbrightness. This will reduce the frame rate a little, compared with building everything together, but sometimes it's the best solution.

Some errors are not indicated, but are visible in the level. The BSP tree process divides the map into regions along all non-detail surfaces. This can lead to heavy subdivision of surfaces in rooms with complex geometry. You can see the subdivision in the level by pressing the [D] key two times while running the engine. Some 3D cards render 'T-junctions' - where 3 surfaces connect - inaccurate, which can lead to visible 'seams' in the level. For this reason, the BSP tree compiler tries to avoid T-junctions whenever possible. Another problem can arise when surface sections are smaller than one shadow map pixel (= 16 texture pixels). In some rare cases, a light 'shadow seam' can be visible along the edge of this surface. These problems are no 'bugs', but are inherent to the BSP tree process and the shadow map resolution, and are normally not visible. Otherwise they can be solved by simplifying the geometry, or using more detail blocks.

Textures

For running your level in D3D (16 bit or 32 bit) mode, you also have to consider the maximum texture size and the maximum video memory your and your customer's 3D cards are equipped with. Some old 3D cards have only 8 MB video memory. The width and height of level textures should be a power of 2, like 64, 128, or 256. 3dfx / Voodoo cards can only handle textures of 256x256 pixels maximum. Textures that don't fit are automatically resized by the engine, which however reduces the rendering quality, consumes memory, and increases load times.

Video memory is consumed by the textures as well as by the shadow mapped surfaces in the map. Each texture pixel consumes 5 bytes of video memory, each 64 surface pixels eat one additional byte for the shadow maps. The screen buffer also consumes more than 3 MB in 16 bit color depth and high resolution. Thus huge levels can exceed the 8 MB limit. The game will still run in that case, but will swap textures, which - dependent on the 3D card - may result in slowdowns and sudden 'jerks' at some places in the map. Advanced users can determine the current video memory consumption by examining the d3d_texsize varable, and avoid 'jerks' by adjusting the d3d_texreserved variable (see C-Script manual).

Map limits

Map diameter (quants)  100000 (coordinate origin must be at center of map)
Surfaces per block ............ 30
Vertices per surface .......... 15
Texture size ......... 1024x1024 (old 3D cards, like Voodoo3, render textures above 256x256 in reduced quality)
Textures total ............. 32 MB (old 3D cards have only 8 or 16 MB)