Creating Large Areas

Intro

This is a (WIP) tutorial by Jdude to help beginner and intermediate mappers come to grasp with how to create large complex environments, specifically as cities. It will cover a variety of topics which are covered more in depth in other articles. There is no one way to go about creating a large complex city environment, but this may help and give some direction to those that are eager to do so:

Basic required knowledge of the Doom3 engine:

Note: This is very generalized but has most of the information one would need to understand Doom3's performance:

Before you begin there are a few things you will need to understand about the Doom3 engine to fully utilize the engine. The Doom3 engine relies on both graphical and processing power. Therefore the performance of a map will rely on both the graphics card and the processor of any given machine (as well as other factors such as RAM but for simplicity purposes we will ignore that and categorize it under processing power). When you understand which factors affect which components of a computer, you can work to maximize each specific asset. For example, if you have to much visual components, your graphics card may lag causing the entire game to lag, but this doesn't necessarily mean your processor is lagging. Therefore if you can balance the two you can get the best results.

The GPU(Graphics processing unit)

Generally speaking, the graphics card will be doing all the rendering of polygons in a map. Every brush you make, every model you insert will add polygons to your map. In addition, sprites and graphical affects such as fog and post processing effects (like overlays) affect this aspect of the engine. The Doom3 engine is a great polygon pusher however and one will have to have created a very complex area to experience slow-down due to polygons. Usually unnecessary patches are the cause of polygon related lagging. [See using patches effectively. (coming soon)] Sprites however may cause severe fps drop; the reason is unknown as Doom3 is not open source yet but sprite affects such as snow, rain, smoke ect. should be used sparingly especially in areas which the player will be close to the sprites because when the player gets close to a sprite, the engine will slow down. You may notice this if you place a puff of smoke or several torches near each other. From a distance you may get decent FPS (frames per second), but when you are very close to them you will experience slowdown.

The Processor

Your processor, generally speaking again, will be rendering the shadows, physics, sound propagation and AI calculations (including Pathfinding ). This means that every shadow you have will slow down your FPS. The CPU tells the GPU where to render the lights, and each lights is a mathematical calculation. Lights which do not cast shadows also slow your FPS but not nearly as much as calculated shadows. For this reason it is important to understand how the Doom3 engine acts with shadows. A popular conception is that the Doom3 engine will slow down when you add additional lights but that is not true. The performance you get in Doom3 in regards to lighting will be directly linked to how many shadows you have in each rendered scene. For instance: You could have 5 lights casting 5 shadows, it will render roughly the same as one light casting five shadows. This is important to keep in mind when placing lights. You don't want the engine rendering a bunch of shadows that the player will not even notice. You also want to take into consideration how many AI you will have in a given scene. With the current version of TDM having more than three AI actively searching for a player can be very detrimental to your FPS. AI optimization techniques include extensive monster clip work ( AI Performance Options ) and good planning.

How to Use This information

Now that you have a basic understanding of what aspects of the Doom3 engine effect your FPS you can use this information to troubleshoot your map and plan it better. For instance if you notice you are having FPS issues in a specific area, try using r_shadows 0 (this removes dynamic shadows) and see what the difference in FPS is. If it is minuscule then you know it isn't an issue related to lighting.

Intermediate Lighting Techniques for Performance and Aesthetics

For the above reasons it’s important to be creative in the placement of lights throughout your level. Certain objects and lights should have the "noshadows 1" parameter applied to them. This can be set in a light by selecting the light and pressing J then checking the "noshadows" box, or in the entity inspector toolbox. To optimize your map properly, you must first pick and choose which lights have the “noshadows 1” parameter. They must be properly placed or else they will appear strange to the player and take away from game play. This can be difficult due to how Doom3 renders lights. The “noshadows 1” option will cause the light to go through brushes. Below is an image that displays how the Doom3 engine renders lights:

Notice how with "noshadows 1" applied the light travels through the wall in the middle but with "noshadow 0" meaning the light casts a shadow, it does not. Thus anything within the radius of your light with "noshadows 1" applied will be lighted as per your light settings.

With this in mind, you can pick and choose which lights should have "noshadows 1" applied to them. Sometimes a light which regularly casts shadows, set to not cast shadows, won't even be noticeable to the player. Below are two example pictures:

One would not regularly notice that the light on the left doesn't cast any shadows.

The lights with the red circles around them are the only lights which cast shadows. The rest are using "noshadows 1" on them. Note: The strange jagged lines in this picture are from using noclip.

In the above picture you may also notice that none of the lanterns are casting shadows. This is because on the model itself, the "noshadows 1" parameter is applied. This prevents the object from rendering a shadow. This can help drastically because the mapper can pick and choose which objects cast shadows, and the less shadows, the better the performance. Many times players will not even notice if an object is not casting a shadow, especially if it is on the edge of a light.

The above image also shows how no shadow lights can be used to illuminate windows. There will rarely be an exception to using "noshadows 1" on window illumination lights as the shadows will rarely ever be important.

It's also important to remember the rules and tips from previous tutorials [link will go here], such as:

Moving lights cause a lot more lag than stationary. Moving objects which cast shadows in lights may cause lag. Lights which cast shadows and overlap cause lag.

In some cases you may want to consider making custom shaders for your map. This will allow for your light to not cast shadows, but look as if it is by using a specifically made shader. A custom shader tutorial can be found here [link]. You should only use this method however, if you have exhausted all other techniques.

Visportaling and Planning

Before progressing to this part of the tutorial, you should have a basic knowledge of how visportals work [see this link]. Visportals are the most important optimization process!

One cannot start making a map without having at least a rough plan of the layout of the map either on paper or in their head. If you have begun to construct a map without any direction you are likely to run into un-fixable performance problems. When constructing wide open areas you should take into consideration three main issues:

1. How many shadow casting lights will there be?
2. How will the vis portaling be setup?
3. What is the layout like?

This tutorial is made specifically for a detailed large scale city map. Large terrain maps have different attributes than complex dense city maps and have been explored in forums such as doom3world.org. One should have two trains main of thought when making plans for their map. Firstly, imagine your roads and buildings as hallways. This train of thought goes back far even to Thief 2 where levels such as “Life of the Party” take advantage of this layout (Link to reference picture). The other train of thought should be how you can use bottleneck points to your advantage. Both of these will be discussed below:

With a basic understanding of how visportals work, one can see how the image below results in optimization using visportals.

The areas highlighted in red are the main city street. Every time there is a corner, there is a visportal. This allows for the Doom3 engine to only render the straight hallways directly infront of the player. This concept is the most crucial part when planning a map. Your map must have corners such as shown in the above image, to support visportals. If you cannot support visportals in your map, your map will either A) run horribly or B) look horrible, because you will have to reduce your detail to accommodate the extreme rendering. The above image does not allow for the player to go on the roofs of buildings, that will be discussed later and is far more advanced to setup. However you can see how it isn't a sandbox like a GTA game where you can go anywhere. TDM is not setup for that type of level so you will have to follow specific guidelines to give the illusion of a large city, but in actuality, the map is a series of hallways separated by visportals! It's easier than it sounds.

The bottleneck technique is for large open areas which are seen more as large rooms with lots of details connected by hallways. Imagine the first map you made. It was likely two rooms connected by a hallway. We are basically using the exact same idea, but instead of two rooms, it's two large cities connected by a pathway. The image below illustrates this concept:

As you can see the area circled in red is a small hallway which separates two large areas. Therefore, when the player is in the top area, the engine wont render the bottom area, and when the player is in the bottom area, it wont render the top area. The bottleneck must consist of some turns to allow for proper visportaling. An "L" technique is ideal and this will be covered shortly. By using this bottleneck technique, you can create the maximum detail possible for both the top and bottom areas and by using a bottleneck such as a gate, a sewer pipe, ect ect (get creative) The player will not feel as if it is two seperate areas, rather just one giant one. This is very important for areas which permit the player to run on specific rooftops. (Imagine "Life of the Party again. It had many areas that you had to go into interiors. These are the bottlenecks!)

"L" Technique

The L Technique is a simple but extremely effective way for cramming a bunch of interiors into a small area. Say you have a street with 6 houses, 3 on either side. If you open every door you will have lag because the Doom3 engine will be rendering some of the insides of those houses. What you must do is create an L shaped entrance with minimum detail to prevent a performance drop. The image below illustrates this point:

The red square is the player and the yellow is what is being rendered by the engine(of course the red shouldn't be behind the player, because the engine wont render things behind you, my mistake). The green is your door / visportal, and notice how the second visportal inside blocks the rendering of the rest of the house. One must always consider how the Doom3 engine will render what you are making. Say you have another door leading to a bedroom within that red area inside the house. If the player opens both those doors than it's going to be rendering some of the interior entrance, as well as some of the bedroom. It's ideal to move that bedroom somewhere in the un-rendered area where when the player has both doors open, he will only render the minimal amount of the inside of the house. When planning your map you must also take into consideration where the player will be positioned in regards to visportals. For example if the player is in the left of the image facing the visportal door while the door is opened, obviously more of the inside will be being rendered. If this is too much then instead of using an "L" shape use an "U" or "S" shape.

Possible Errors

Although the Doom3 engine is extremely flexible, you may come into a particular error if your map exceeds the limit that your computer can handle. As far as I've been able to decipher, this specific error is not related to how "large" your map is on either the X,Y or Z axis, rather it's related to the amount of texture your map has. The Doom3 engine is only limited by current hardware in this aspect. If your map is using too many different textures (textures are used on models as well, do not forget that!) your graphics card may not be able to load all the textures into it's memory. Also, 32-bit build of DarkMod can only use 2 GB of RAM. If the total size of assets used by your map exceeds this limit, then you will get a Malloc failure:

Note: This error will only occur when you try and run the map, the map should compile fine.

This error occurred for me when I was adding onto a map which consisted of: 14538 brushes 973 patches, 2674 entities, and approximately 150 brush textures alone, with the dimensions of 6144X6144. This is an extreme case however. It was running on a 1.87ghz core 2 duo, 3 gigs of ram with a x1950 pro 256 card.

If you have problems with memory consumption, you can see how much memory is taken by each particular asset (images, models or sounds) by running printMemInfo command in console. The generic results will be printed into console, but text files with detailed data (with file granularity) are put into the directory where your map file is located.

Starting with TDM 2.06, you can run 64-bit executable of TDM, which does not suffer from 2 GB memory limit. But keep in mind that the amount of VRAM in GPUs is still limited.

---

Recent Observations

See the Performance Tweaks article for the latest config recommendations

Note:

For mission authors with a 64bit OS, a special 4GB patch is available which can overcome these errors during dmap.

Alternatively, setting inaccessible decorative geometry to "noclipmodel 1" can help a larger map dmap before resorting to the 4GB patch.

• For 64bit patch details see: Malloc Errors

Users who experience these errors may also need to enable texture compression. This has been reported more often in v1.04 and v1.05.

(verify these settings in your DoomConfig.cfg Darkmod.cfg)

 

 seta image_usePrecompressedTextures "1"
 seta image_useNormalCompression "1"
 seta image_useAllFormats "1"
 seta image_useCompression "1"
 seta image_preload "1"

AAS errors

If you get errors about AAS in your map, then you might have a rat (or an other small AI) and this causes the AAS compiler to run into errors. Simply visportal your error into two halves. Note that the area doesn't have to be particularly large, sometimes even 50x20m are to big for rat AAS.

See Also

• Performance: Essential Must-Knows
• SEED