View source for User:Wormbo/Optimizing JB-Aswan-v2 (UT2004)

When I converted [[liandri:DOM-Aswan|DOM-Aswan]] to a Jailbreak map, people reported bad framerates. Until then I only paid attention to setting up the Jailbreak-specific actors and just "reused" the original optimizations. To achieve better performance, I started "from scratch" by removing all [[zone portal]]s, [[UE2:ZoneInfo (UT2004)|ZoneInfo]]s and [[UE2:AntiPortalActor (UT2004)|AntiPortalActor]]s, and disabling the [[anti portal]] flag of all [[BSP surface]]s.

For JB-Aswan-v2 I ended up using about all of the map optimization techniques UT2004 offers. This article will sum up their application and the ideas behind why they where applied this way.

==Optimized zoning==
The first step in successful optimization always is a proper zoning layout. Ideally the map doesn't have long lines of sight, but sometimes you don't really have a choice. In these cases it is important to make portal sheets between zones as small as possible, while still retaining a convex shape. Most importantly, zone portals do not need to overlap BSP geometry. It is enough if they fit the opening perfectly, and in fact, making them any larger is suboptimal for performance.

On Aswan this especially goes for the lower corridors from the side to the back rooms and for the exits of the side rooms. These originally used just square portal sheets that were quite a bit larger than the actually visible shape. An optimized shape would be a [[wp:isosceles trapezoid|isosceles trapezoid]] in both cases.

Another zoning consideration is whether to place just one portal in a small corridor or actually make the corridor a separate zone by using two portals. I decided to make the front entrances to the back rooms separate zones because there's enough chance that the second portal isn't visible from the first when viewing from an angle. If the portals were closer together this wouldn't happen often enough, and if only a small part of a portal sheet is visible, the entire portal is considered visible.

Other parts that got their own zones are the area below the upper walkway right outside the back rooms, the ramps between the back rooms and the lower corridors, and the top part of the back rooms which isn't visible from the outside. Those complex lightbox meshes in the back rooms are quite a performance hit, so best effort must be made to prevent them from being rendered if they aren't actually visible.

==Optimizing zone visibility==
For the next step, all zones should get their own ZoneInfo actor. Open the level in the game, fly around as spectator and use the command '''rmode 1''' to switch to wireframe mode. Now check the view through your zone portals. In this step you try to identify pairs of zones which are not actually visible from each other, yet the engine decides to render them.

For Aswan this is the case for the lower corridors from the side to the back rooms. They definitely aren't visible from each other, but because BSP doesn't occlude visibility, the zone portals "see" each other. This could probably be fixed with anti portals, but it is much cheaper and almost as efficient to just manually tell the engine that the zones aren't visible from each other by using [[manual excludes]]. (ZoneInfo property [[UE2:ZoneInfo (UT2004)#ManualExcludes|ManualExcludes]]) For example, the red flak cannon corridor and the blue rocket launcher corridor are set as manual excludes for each other. It turned out that the engine also considers the red jail to be visible from either of those corridors, so the red jail zone is also added to the corridors' manual excludes.

Other manual excludes are the lower front entrance areas, which aren't visible from each other because the Double Damage pedestal in the middle blocks the view. The engine still renders them because their front portals are in the same zone.

If a zone doesn't have any zone portals or fake backdrop surfaces, it should be flagged as lonely zone. (ZoneInfo property [[UE2:ZoneInfo (UT2004)#bLonelyZone|bLonelyZone]]) This allows the engine to skip any considerations about rendering the zone when it renders other zones and about rendering other zones when it renders this zone. JB-Aswan-v2 uses this for the arena zone, because it is entirely separate.

==Forcing actor visibility zones==
Actors that are not entirely contained in a single zone are often considered visible from other zones even though other geometry or meshes block the view. On Aswan this mostly affects the lightbox meshes in the back rooms and some of the pillars on the front wall of the bases. For these large actors it makes sense to match their [[UE2:Actor properties (UT2004)#ForcedFisibilityZoneTag|ForcedFisibilityZoneTag]] with the ZoneInfo Tag of the zones the actor really is contained in. For the lightboxes this is the red/blue backroom zone, and for the pillars it's the "outside", i.e. the outside zone and the front entrance zones. Similarly, the fluid surfaces are set to use their corresponding corridor as visibility zone.

==Using anti portals==
The final step of optimization is placing [[anti portals]]. Good locations for these are e.g. large pillars that block much of the player's view. Anti portals should always have a simple shape, yet fill out as much space as possible because they are only considered separately for visibility occlusion.

On Aswan, the front row of pillars in front of the bases use six-sided cylinders as anti portals, the blocks between the jail bars contain upside-down four-sided pyramid shapes, the middle one cut off because it would reach into the escape tunnel. The entire wall with the escape tunnel door contains a large anti portal sheet that is tied to the escape door mover, the side walls of the middle area contain sheet anti portals, and finally the Double Damage pedestal contains an eight-sided cylinder anti portal. Additionally, some BSP surfaces are marked as anti portals, for example the upper walkway in front of the bases, which occlude the portals to the lower entrance areas.

[[Category:Mapping tutorials|Optimizing JB-Aswan-v2]]