OpenArena
Register
Advertisement
OpenArena's Mapping manual
Prologue /// Pre-mapping stage - Map gameplay /// Choosing an editor /// Your first map
Brush manipulation - 2D/3D clipping /// Curve manipulation /// Textures /// Introduction to Entities
Lighting - Advanced lighting /// Weapon/Item placement /// Triggers and movers - Dynamic features
Shaders /// Terrains and liquids /// Mapmodels /// Sounds /// Gametype support
Optimization and Troubleshooting - Hint brushes - Bot play - Troubleshooting
Final touches /// Compilation & packaging
Glossary of terms - Advanced features - Modelling a map - Editor differences - Default assets (Textures/Models/Sounds) - GPL

General tips[]

Initially taken from the Worldspawn Archive's article "Optimizing maps for the IdTech3 engine"[1], here's a list of some of the things which may help you to improve performance (framerate stability and count, compiling times) of your maps:

  • Use common/caulk for faces which can't be seen in-game. Starting with those facing the void.
  • Prevent overlapping brush faces. They can cause framerate drops and T-junction errors in-game.
  • Turn straight walls with many brushes and textures into a wall with one huge texture and one brush.
  • Before adding light entities to your map, check if the shaders and skies cast enough lighting. They look better than many light entities. Furthermore, a badly placed light may ruin the athmosphere of the map.
  • If you use doors in your map, it's a very good idea to place areaportals with the same size as the doors inside of them, so everything which isn't visible behind the door when it's closed won't be rendered by the engine. However, don't forget framerate drop may still occur when the door will open.
  • Turn every brush (patches and models are already detail) which isn't really a part of the level into detail brushes. This would make VIS compile time lower; however don't apply it to walls which should really block VIS, in order to keep the important in-game framerate optimization VIS allows. (See below)
  • Use hint brushes. (See below)

Mitering[]

Also called Polygon reduction, it's a simple way to decrease the number of polys where two brushes meet at an internal corner. A miter joint is formed by angling (beveling) the faces where two brushes meet.[2] This is an extremely simple, yet very overlooked, subject regarding OA mapping. Here's a simple three-step picture about how to solve this problem.

Mitering-tutorial

As simple as this appears, it represents a big gain because Q3Map2 doesn't have to split the BSP tree into more faces, and as a result, less polygons are rendered.

Detail brushes and VIS blocks[]

In the brush manipulation page, we have talked about the utility of detail and structural brushes and how they affected VIS and BSP. We've also mentioned that brush overlapping is bad except in one case. In this section we're going to see these topics in more detail.

First, with your map as it is built, run a test compile with the BSP and VIS stages. This latter stage must be run with the -saveprt switch, otherwise the .prt file will be deleted at the end of the VIS stage process, and we need it.

Open your map and filter anything except World, Caulk and Structural. If you haven't used any func_* brush entities, filter also Entities.

Then, load the .prt file.[3] You should see the portals in your 3D view.[4] Start with turning any decorative brushes into detail brushes. Save, recompile BSP and VIS, and reload the .prt file.

The next step is to make sure that the default cuts don't get in the way of your optimizations. Go to View → Show → Show Blocks. This shows you the default cuts. The default size is 1024x1024x1024, meaning that every 1024 units from the Origin there will be a cut.[5] Adapt your map as much as you can to the blocks grid so most of the walls get in line with the blocks. Once done, save your map, recompile, and reopen the .prt file.

Example 1[]

Suppose you have a room like this (top down view):

Speedupvis1

If that corner isn't large enough to block the player's view, or if there is just a flat surface to be occluded, while he/she is standing at the green dots positions, then there is no need for that corner to be structural.

You've just reduced the cluster count on that room from two to one.

Example 2[]

Speedupvis3

Suppose you have a corridor like that (front view), with some carved space on walls bottom where you place lights. If you do it with structural only, those carved spaces are going to be filled with a useless cluster, the player will never be there nor that thin space is ever going to occlude something.

In that picture you can split the polygon in 2 clusters, but since the carvings are small, q3map2 would probably create 3 clusters, one large for the corridor itself and two small ones where the light textures are. By using detail brushes you can reduce the cluster count to just one in the above case.

Example 3[]

Speedupvis2

See the teal colored rectangles up there? Suppose that you closed off the playable's area ceiling with some extra space, represented by the colored rectagles. If that space does nothing in regards to lighting, players won't go there or there is nothing but sky to be seen at that height, then they are just adding to cluster count and adding up to vis calculation. If possible, don't even extend the playable area's height to make the sky, directly make the playable's area ceiling brush the sky itself.

The good side of overlapping brushes[]

Making two brushes to overlap is generally a bad idea. It generates extra cuts, a bigger file size and longer compilation times. But there's one case where it's completely and absolutely legit to use this, and it involves drawing detail brushes and patches on top of structural caulked brushes. Caulk brushes aren't drawn in-game, and VIS only considers the structural brushes for calculations.

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 optimized. It's important, however, 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.[6]

Hint brushes[]

Hint brushes are brushes placed in maps to give "hints" to the compiler about where visibility portals should be placed. You can find more info in the hint brushes page.

Notes[]

  1. Optimizing a map for the IdTech3 engine
  2. Mitering (reducing polys) of a level
  3. In later editors (GTKR 1.5, 1.6 and NetR) this is done via Plugins → prtview → Load .prt file.
  4. Toggle them with Plugins → prtview → Toggle 3D view.
  5. The size of these cubes can be changed by modifying the "_blocksize" key with another power of 2 (512, 2048...) in the Worldspawn entity.
  6. LevelDK 3: Detail and structural brushes.

External links[]

See also[]

<< Previous (Additional gametype support) Mapping manual (Hint brushes) Next >>
Advertisement