 |
|
 |
|
|
|
font face="Verdana,Geneva,Arial,Helvetica,sans-serif" size="-1">Please take note! For mod developers working with Unreal Tournament 2003, this documentation is meant to be a starting point for your own explorations into UT2003, not a definitive guide. There will be differences between the documentation here and the product in your hands, and you may have to figure out quite a bit for yourself. Check out the Unreal Tournament 2003 page in the Unreal Powered area for links to community sites if you're having problems. UDN is a licensee support site, and cannot provide technical support or game-specific assistance to end users.
|
|
|
|
|
 |
LevelOptimization |
 |
|
|
|
|
|
Licensees can log in.
Interested in the Unreal engine? Check out the licensing page.
Questions about UDN itself? Contact the UDN Staff.
|
|
|
|
|
|
|
|
|
|
Last updated by Jason Lentz (DemiurgeStudios), for updating of the 2107+ build. Original author was Tomasz Jachimczak (UdnStaff).
- Level Optimization Techniques
- Introduction
- Core Rendering Objects
- Frustum
- Geometry
- BSP
- Static Meshes
li> Terrain
- Zones and Portals
- Antiportal Volumes
- Distance Fog
- Advanced Tips
- Viewport Display Modes
- Terrain Grid
- Console Commands
- Manually Assigning Zones
- Plan Ahead
The process of level optimization is an involved and complex process. After a level has been optimized however, the speed and efficiency of your world in the Unreal engine will be greatly enhanced. The renderer draws everything in the field of view of the player (regardless of whether the player can actually see it or not), unless you tell the renderer not to draw it. We will describe the many tools you have to limit what the renderer will draw as well as outline a variety of other ways you can trim the fat out of your level.
The best time to start the optimization process is now. The actual optimizing of your level takes place at the end of the creation of the level, but it is very helpful to have a plan of how you want to optimize your level before you start. The more planning you do beforehand, the fewer headaches and restructuring of your level you will have when implementing the level optimizations to your world.
Level optimization is a somewhat counterintuitive process, partly because removing things from the renderer's "to draw" list is an additive process. In order to keep the renderer from drawing more than it has to, you are given a variety of tools. The following is a description of each, starting with the most basic and moving on to the more complex. Each has its place in the optimization process and this document will help you to decide which tool to use in each circumstance.
These are the components relevant to the level optimization. This section will outline what each of these objects is and how best to use them to get the most efficient level that you can.
The frustum is the volume of space that encompasses everything in the field of view of the player's camera. This is the only automatic optimization tool in the renderer as it only draws geometry that falls within the frustum of the camera. Below is a simple room in top down view that diagrams what the frustum would look like.
The large eyeball denotes where the player is standing in the room and the red arrow shows which direction he is looking while the shaded region is the space of the frustum. The frustum is a three dimensional volume and it goes well off screen. Here is what the camera sees from this vantage point:
The frustum extends from the player's view to form a four-sided pyramid extended from the eye of the player outward Using objects that allow the player to zoom (like a sniper rifle) obviously changes the frustum of the player. Other attributes of the frustum include the near and far clipping planes which determine how far away or how close an object must be located to be drawn.
There are three basic types of geometry, BSP (Binary Space Partitioning), Static Meshes, and Terrain. Each has different advantages and disadvantages for optimization purposes. We'll start by taking a look at the most basic of these geometry types, BSP.
BSP
BSP is the most primitive of the geometry types as well as the most fundamental. Without it, your level will not exist. BSP is the slowest geometry type to render. It does have some advantages over the other geometry types, though. As mentioned before, it is necessary in creating the actual space of the world. You must start with BSP by subtracting a BSP brush from the world, so that you are working within subtracted world space. Using BSP brush is also the only way to set up zones (explained in detail in the Zones and Portals section). Another thing to note with BSP is that it is occluded in nodes, which means that when it is set up to be hidden from the renderer it will be hidden in chunks, not on a triangle by triangle basis.
Lastly, BSP geometry always collides and handles collision calculations the most efficiently. Because of its limitations though (not easily manipulated and slow to render), BSP is being used less and less in by level designers. Typically BSP is only used for the following cases: To set up Zones (described in detail here, and for surfaces that will require constant collision detection such as floors and platforms.
Here are some images of a space that has been created entirely with BSP geometry carved out from the solid world space.
And with textures it can look like this:
Static Meshes are kept in packages in the Unreal-xxx/Static Meshes folder in files with .usx extensions. These packages may contain any number of meshes - much like a texture package can contain any number of textures. By default, they are set to collide with players and are usually modeled in some third party modeling tools such as 3DS Max, Maya, or Lightwave.
This geometry type is the fastest to render due to being drawn entirely through use of 3D acceleration on the client computer. Another advantage is that once a static mesh has been used in the editor, it may be reused in another part of the level with almost no overhead on the render times. Using the barrel static mesh pictured above this can be demonstrated in the BSP space shown earlier.
Here we've added 3 separate meshes to the BSP rooms, the barrel, the wall light fixtures, and ceiling lights in the center of the barrels. There are multiple copies of each mesh, but because they are all copies, and not just similar looking meshes, the scene will render much faster than if they were each unique meshes.
Static Meshes also work well with the manipulation tools in the editor. To prevent your environment from seeming too repetitive, you can scale and rotate the mesh to make it appear just different enough to seem like a unique mesh to a player. These minor alterations will change the appearance of the mesh for the player, but to the engine they will still be the same mesh and still takes advantage of the low overhead of rendering multiple instances of that same mesh.
These advantages allow for the creation of highly complex additions to the world that won't greatly encumber the renderer, but they do have a few disadvantages. First of all, a static mesh must be entirely hidden by a single antiportal in order for it to be occluded. This is explained in further detail here. Secondly, Static Meshes handle collision calculations slowly. While the Unreal engine can handle rendering thousands of static mesh triangles without a hitch, calculating the collision for thousands of triangles can take a far greater toll on processors. This disadvantage can be circumvented by creating invisible collision hulls that have the same basic shape of a complex mesh, but much fewer triangles. Using the barrel mesh above to demonstrate this, it is easy to see that the geometry for collision does not need to be as complex as the barrel geometry to give a realistic sense of collision. For a more detailed description of collision hulls, see the CollisionTutorial.
This screenshot shows the mesh from the barrel next to a standard eight-sided cylinder. For a player running through the level, the simpler 8-sided collision surface simulates the spatial volume of the barrel almost identically. The cylinder is exactly the same height, has the same circumference and will block the player from walking through the barrel. However, the eight-sided cylinder greatly simplifies the calculations needed by the engine to work out collisions against players.
Terrain geometry falls between Static Meshes and BSP as far as rendering and collision efficiency. Terrain is almost as fast as BSP for collision and when being occluded from the renderer, it disappears in 16x16 blocks, much like BSP disappearing by nodes. Below you can see three 16x16 blocks are being occluded.
The first step in optimizing your terrain is selecting the right resolution for it. By default, terrain is 256x256, but sometimes a lower resolution will suffice.
You may want to use terrain only in a small section of the world. For instance, if you are planning to use terrain to cover a smaller area, such as a small oblong cavern, a 128x64 sized terrain may be all you need. Unfortunately, since terrain sizes should be kept at powers of 2, you can't get too specific about the size of terrain you wish to use when creating it.
Another "fine tuning" tool for optimizing the terrain is the Visibility tool in the Terrain Editor.
By selecting this tool and highlighting the terrain map you want to hide sections of, you can turn patches of terrain triangles invisible by right clicking with the mouse. If you turn too much invisible, you can simply left click to turn those triangles back to visible. Note that the maximum radius can be altered to change the affected area so it is possible to hide large patches with a single click, or by setting the maximum radius to one, you can hide the triangles on a per triangle basis. Triangles that are turned invisible will never be considered for rendering.
Zones and Portals are the best tool for visibility culling that the level designer can work with. A Zone is an entire area of the level that can be sectioned off and considered separately for rendering. This allows the renderer to draw triangles or not draw triangles per Zone rather than going through and individually determining what meshes will and won't be drawn. This is a huge advantage since with zones the renderer may only have to worry about 50 Zones or fewer, versus 50,000 or even 100,000 triangles in a level.
To create a Zone, section off areas of your level by totally enclosing them in BSP volumes. A skybox, which does just that (completely surrounds a world), is in effect a Zone. Everything outside of that Zone will not be rendered as long as there are no lines of sight from one Zone to another. This brings up the problem of having players travel from Zone to Zone. To allow a player to move from one Zone to another a Portal must be added. Portals are invisible sheets that are used to divide up Zones. If a player can see through a Portal into another zone, then the renderer will render that zone. Given this, it is best to place Portals in the smallest connection two parts of a zone, such as doorways, to ensure you get the maximum efficiency of your Zones and Portals.
Using the previous example of the BSP room we will split this from one Zone into two through the addition of a Portal. As shown by separate colors, in this level there are two Zones, the blue two room Zone with the barrel and the light static meshes, and the green zone to the left that is simply an unattached box. As explained before, if you are in one of the green box Zone, nothing in the blue Zone will be rendered at all, but the blue Zone can be broken down further by the addition of a Portal. By creating a sheet that takes up the entire space of the hallway between the two blue rooms and then clicking on the "Add Special" button, and then select the "Zone Portal" default from the pull down menu:
The portal created divides the blue zone into two (now shown as red and green below) and still allows players to travel from one room to the other.
When the portal is not within the frustum of the player's view, the other room and all of its contents will not be rendered.
The more Zones a level is divided into (within reason), the better. A well zoned interior will allow for elaborate and intricate detail to be added within confined spaces. Outside environments can be a bit trickier as they are often large, wide open spaces that are not easily divisible into separate BSP Zones. It is possible to have small buildings that are their own separate zones within a landscape, but the landscape as a whole will be one large zone. Objects within large outdoor spaces can still be occluded, but different tools are required for this. These tools are described in the next section.
Antiportals are invisible barriers used for blocking geometry from the renderer's view. They are very versatile tools for not only obscuring geometry in large wide open environments, but also for fine tuning within smaller zones. They can be used in conjunction with any visual barrier to the player, be it a BSP brush, static mesh, or within terrain.
There are only a few constraints with Antiportal Volumes. First of all, they must be convex, or in other words, you should be able to draw a line from any point on the surface of the volume to another and not have it leave the boundary of the shape. Secondly, the Antiportal Volume must be at least touching the subtracted world space. They will not occlude anything if they are completely within the solid world space. Another constraint is that you cannot resize them once you've added them to the level. You can rotate them and move them, but resizing is impossible. Lastly, you may notice that Antiportal Volumes may not occlude nearby geometry. Because the occlusion tools are built for speed and efficiency, the process of occlusion is not a perfect one. The goal is to run as fast as possible and that doesn't necessarily mean rendering as little as possible.
Here is an example of how Antiportal Volumes can be used to occlude the various types of geometry. Below is an aerial view of a simple environment that can be greatly optimized with the placement of a few Antiportal Volumes.
In the screen shots below, we can see that the renderer can see many things from this vantage point while the player's view is mostly occluded. The camera is within a BSP room (seen in the lower right corner in the above image), looking out into a terrain that has several static meshes both in front of and behind the hill. From the player's perspective though, you can only see a wall mesh and the BSP wall.
The first Antiportal Volume we add is in the terrain inside the hill in the distance. Even though it is below the terrain, it is still within the subtracted world space and it occludes properly. It is best to make it make it as large as it can be without protruding from the terrain so that it occludes as much as possible. As seen in the wireframe view below, this Antiportal Volume occludes all the terrain behind it, and several static meshes.
Next an Antiportal Volume is used with the BSP wall to occlude much more of the outside environment. This Antiportal Volume cannot be placed entirely within the added BSP wall though, as it would not occlude anything. To prevent the Antiportal Volume from being ignored, make it just larger than the wall so that it juts out into the room as well as outside. This ensures that it is touching the subtracted world space. It will not hide the BSP wall, because it is not entirely hiding the BSP node which the wall is within.
As can be seen in the above image, even though the tree mesh is partially hidden by the Antiportal Volume, it is still being rendered in its entirety. As stated earlier in the static mesh section, a static mesh must be entirely hidden by a single antiportal in order for it to be occluded. Adding one more Antiportal Volume in the wall static mesh will totally occlude the tree static mesh in conjunction with the last Antiportal Volume added, but since neither one will completely obscure it on its own, the tree will still be rendered. This can be seen in the following wireframe screen shot that has Antiportal Volumes about the BSP wall and in the wall static mesh.
The addition of a zone portal in the doorway of the BSP wall will occlude everything that is outside the room, because the addition of the last Antiportal Volume totally obscures the doorway. While using Antiportal Volumes together may not work to occlude single meshes, using them with Zone Portals works very well to efficiently occlude entire zones as seen below.
Individual meshes can be turned into antiportals themselves by converting the mesh into a brush and using the "Add Special" button,  or the "Add Antiportal" button. If they are not convex though, they will either slow the engine to a halt or just cause it to crash. Simple Antiportal Volumes are more efficient occluders than meshes assigned as antiportals through the "Add Special" tool. Antiportal Volumes occlude with their entire silhouette, while the other antiportals calculate occlusion for each of the triangles in the mesh assigned as an antiportal.
Distance Fog is the last of the tools a level designer has for optimizing his or her level, and it should be used last as well. A well optimized level should not rely on Distance Fog to make it playable. The effects of level optimization, when done right, should never be noticeable to the player other than to increase the smoothness of the game play. Distance Fog, if done poorly, will look fake and forced if the fog gets too dense too early. Because this can break a player's suspension of disbelief or affect gameplay, Distance Fog should be used judiciously.
The best places to use Distance Fog are in large outdoor environments. When used well, it can give an additional sense of distance and depth (as real fog would), and it will also help to hide far off geometry. How Distance Fog works to occlude objects from the renderer is that the further away things are from the player's perspective, the more saturated with the fog color they become. Once the geometry is far enough away to be at 100% saturated in the fog color, the renderer ceases to draw it with no noticeable popping for the player. The scenes below show this effect.
Now with Distance Fog...
To create Distance Fog within your level, you must first add a ZoneInfo to the zone in which you want to fog to affect. Then under the ZoneInfo tab in the ZonInfo Properties change bDistanceFog to True. To tweak the Distance Fog values, expand the ZoneLight Tab and you will see the following:
The values for Distance Fog control the following things:
- DistanceFogBlendTime
- information to be added later
- DistanceFogColor
- This allows you to either use the color picker to select a color from the view port (choosing from the background sky box is a good place to pick from), or select from the color palette. It is a good idea to pick a color that blends in the background of the environment so the transition to total fog is as gradual as possible.
- DistanceFogEnd
- This sets the distance from the player at which the geometry will be totally saturated with the fog color and is no longer drawn.
- DistanceFogStart
- This sets the distance from which the geometry will begin to get saturated with the fog color.
With the above setting the fog starts at 2,500 Unreal units from the player and beyond 13,000 Unreal units, geometry is totally occluded. Other than the aesthetic cautions in using Distance Fog, there are practically no optimization drawbacks to using it, as it puts less strain on the processor.
The aforementioned tools are everything necessary you will need to optimize your level. There are however, other tools that you can use to assist in using the above tools as well as locating trouble spots that require further optimizing.
The Viewport Display Modes are the easiest of these tools to use. The three most useful modes are Wireframe, Zone/Portal, and Depth Complexity.
Once you have the Realtime Preview button selected, you can see the editor's approximation of how your level is being rendered. In Wireframe mode, you can see geometry popping in and out as it gets occluded by Antiportals and Zones. In the Zone/Portal mode, you can make sure that the Zones you have created are actually being treated as separate Zones. Each separate Zone of BSP is rendered in a different color. The Depth Complexity tool shows the number of passes that the renderer has to calculate to correctly render the scene. If the texture distribution is well optimized everything in the scene should be green and yellow shaded, but if there are spots of red or if the depth complexity seems to have cycled back to green, then the number of textures used in that area should be reduced. This most commonly happens through using particle systems as well as in layering textures on terrain.
Another way to check the depth complexity of textures on terrains is through Terrain Editor. Using the Show Grid button (located under the layers tab), you can see which layers are being used where on the terrain. By toggling the layers on and off, you can see where exactly each texture is being drawn and track down the areas where a texture has been painted but where you don't want it to be.
Because the editor renders the level in a slightly different way from the way the level renders in game, you will not get a perfect representation of how your level will truly be optimized. You must play the level if you want to see how everything will be treated in game. You will not be able to change anything while playing the game, but by pressing "~" you do have access to the command line. Here are some of the more useful commands and their descriptions to facilitate your optimization process.
These console commands display text on the screen that reveals numerical statistics of what is happening within the rendered scene. They are also available in the editor and reflect what is rendered in each of the windows that have the Realtime Preview button checked. Note that if you have all four Realtime Previews turned on in the editor, the displayed statistics will include the geometry being rendered in all of the scenes. These stats can be toggled off by retyping the stat into the console command line.
- "stat fps": This displays both the current and average frame rate of the level. One should note that while a high frame rate in game is your ultimate goal in optimizing your level, you should not use this statistic to judge whether or not your level will run smoothly on all machines. This is just the framerate for the level on YOUR machine and will most likely vary from computer to computer, so it is best to use the other following statistics.
- "stat hardware": Most of the information displayed here is not critical to level optimization, but the first and third line show the total number of triangles and textures rendered in the scene respectively.
- "stat render": This displays a breakdown of everything that is being rendered in the given scene. The more useful sections to take note of here are the BSP, Terrain, Particle, and StaticMesh sections.
- "stat all": This shows all of the stats.
- "stat none": This hides all of the stats.
These allow you to alter the rendering style within game play giving you the same control as the Viewport Display modes. Below are the descriptions of the different rmodes:
- "rmode 1": Wireframe mode
- "rmode 2": Zone/Portal mode
- "rmode 3": Texture Usage mode (this only shows texture usage on BSP geometry)
- "rmode 4": BSP Cuts mode
- "rmode 5": Dynamic Light mode (this is the normal in game mode)
- "rmode 6": Textured mode
- "rmode 7": Lighting Only mode
- "rmode 8": Depth Complexity mode
There may be some cases in which you never want a mesh to be rendered if you are in a particular zone. This behavior can be set within the properties window of that mesh. First you must create a ZoneInfo in the one zone from which you want it to be seen, and give it a tag (under the "Events" tab of the ZoneInfo properties). Then in the properties window of the static mesh, open the "Display" tab and go down to ForcedVisibilityZoneTag.
In the above window, the static mesh is set so that it will only be rendered when the camera is in the zone labeled "OutsideZone." You can give multiple zones the tag "OutsideZone," and this will allow the static mesh to be rendered from each zone with that tag. The static mesh however will be occluded if it is hidden through some other means of occlusion. The ForcedVisibilityZoneTag only hides it from the zones with different tags contrary to what its name suggests. Normally, if a zone is not seen all static meshes within that zone are also hidden, but if the static mesh protrudes from that zone into another and you want it to hidden, then this setting is exactly what you want.
The biggest tip of all is planning ahead. Spending a little extra time just thinking about how you want to organize your level can save you hours upon hours of heartache and headache when it comes down to actually implementing the level optimization. Establish polygon budgets at the outset. Develop a plan for where you want to place your zones, portals and antiportals. And err on the side of caution. Beautiful levels will never see the light of day if they aren't playable. Planning ahead is what separates the amateurs from the masters of this craft.
| Attachment: | Action: | Size: | Date: | Who: | Comment: |
|---|
 Demolevel.zip | action | 34998 | 21 May 2002 - 14:00 | UdnStaff | |
| DemoLevel2110.zip | action | 394917 | 04 Feb 2003 - 16:22 | DemiurgeStudios | This is the Demo Level updated for the 2110 build |
|
|
