Antiportals are a new concept in version 2 of the Unreal Engine, UT2003 and onward. For more information on the transition from older versions, see Occlusion changes for UnrealEngine2.
They aren't a type of portal, and in fact shouldn't really be called "antiportal" at all. They are occluding planes: they prevent the rendering of things behind them.
Contents
Two flavours
AntiPortal Surfaces
There are two ways you do this:
- define special planes with a special kind of Antiportal brush
- label particular BSP surfaces as antiportals, which causes them to occlude
AntiPortalActor (the volume-ish kind)
This type of Antiportal is a type of brush. It is placed with the special toolbox button and shows up as brown wireframe model, similar to a volume. Hiding volumes (key O by default) will hide AntiPortalActors as well.
Behavior
An Antiportal speeds up the rendering of a view by occluding (hiding) everything (geometry, actors etc) behind itself. This has the effect of reducing the polycount (the number of polygons visible) from a particular location and therefore speeds the level up.
Although Antiportals can be placed in solid space (that is outside of the level) they must be touching some subtracted space in order to be considered by the rendering engine – this is so the engine knows which zone the antiportal affects. Also, an Antiportal will only be considered for occlusion if the zone(s) the Antiportal exists within is visible within the current viewport. If an Antiportal is used by the rendering engine then the entire Antiportal is used, whether it be in solid or substracted space.
| Not true for recent builds at least: |
Antiportals are always treated as a cube. Though you can use a convex (see warning section) brush of any shape and size to make an AntiPortal, the resulting area it occludes will always be a box based on the extents of the original brush. This box rotates with the brush, so you can have diagonal boxes for occlusion. |
AntiPortalActors may use any convex brush as their source geometry. However, to make their processing fast you should only use extrmely simple brushes, such as sheets.
An Antiportal will occlude different parts of the Unreal World in different ways:
- BSP on a node by node basis
- if the bounding sphere of a static mesh is visible the entire mesh will be rendered.
- an Antiportal will occlude terrain in 16x16 blocks. So even if a small part of a 16x16 block is visible the whole block will be rendered.
An Antiportal should never be substantially visible to the player - it should always be hidden within a static mesh or other "solid" part of a level. It's usually OK if the corners stick out a bit as it's unlikely that the player would notice any occlusion errors that small (but test from a wide range of angles to make sure it looks OK). It is, however, critical that the player not be allowed to (even for an instant) get their camera inside the anti-portal volume. If this happens the world stops rendering (even objects intersecting with the antiportal) and a Hall Of Mirrors rendering errors will occur until they move back outside of the antiportal.
Zone Antiportals
The game Devastation adds a new type of Antiportal – the Zone Anitportal.
Zone AntiPortals are used to cut down on the number of AntiPortals needed for a single building. The idea is if you have a building with a room inside it, that building should occlude what's behind it. With UT2k3, that means added a number of AntiPortals around the building, making sure not to cover up any of the inside of the building or the doorway. This means for a single building you're using maybe 6 AntiPortals for a building that may only be a basic box. Zone AntiPortals let you select the ZoneInfo of zones you don't wish the Zone AntiPortal to occlude. This means you can have a big building with a room inside, and only one big Zone AntiPortal that occludes everything behind the building, but doesn't occlude the room.
There are some quirks around using the Zone AntiPortals as they cannot cover the Zone Portal which looks in to the zone you don't want it to occlude, as the Zone Portal actually exists in the zone you're in, and not in the zone you're trying not to occlude.
There may also be some issues with listing multiple ZoneInfos in the Zone AntiPortal's ZoneInfo list where only one or some of the zones are not occluded. Sometimes it works, sometimes it doesn't. Some of the bugs with this were fixed near the end of the development of the game so it might work now.
The map SP3M5-Bukko is a good example of the different occlusion techniques as that uses zone occlusion, AntiPortals, and Zone AntiPortals together. The small store the troopers use as their first spawner base is a Zone AntiPortal, and there are regular AntiPortals on both sides of that street.
It is not known whether Zone Antiportals have now been integrated into the main Unreal Engine.
BSP Surface Anti-portals
note: I'm calling these Anti-portals (with a hyphen) as the Surface Properties window calls them that.
Anti-portals work very similarly to AntiPortalActors. They occlude objects entirely behind them. The advantage with BSP surface Anti-portals is that if you already have BSP in the right places you don't have to add new objects to the map. There are several issues with BSP surface anti-portals however.
Most significantly, the original brush geometry is used, not the geometry exposed in the map. This means you can't flag a wall that you cut a doorway through as an anti-portal because the original polygon (without the doorway cut out of it) will be used for occlusion.
The second issue with BSP surface Anti-portals is that each surface is treated as a separate anti-portal. Because an object is only occluded is if is entirely hidden by one anti-portal, if an object is behind the seam between two BSP anti-portals it will be visible.
In general you should stay away from BSP surface Anti-portals unless they precisely fit the needs of your map. A significant number of the standard and bonus pack maps use BSP surface Anti-portals, but I believe this may be because AntiPortalActors only became available shortly before UT2003 shipped.
Triggerable AntiPortalActors
Note: Only tested in UT2004, but should work in UT2003 as well.
This combination is a great way to use AntiPortalActors for doors or Destroyable Objective SMs. For example, you have a nice decorated tunnel, with a destroyable door or a standard door at the entrance of it, you want to occlude the decorations, but placing AntiPortalActors to the entrance will hide most of the tunnel, even if the entrance door is opened or destroyed. Triggered AntiPortalActors are here to solve this problem. AntiPortalActors are always activated, but they are deactivateable (and reactivateable)!
!Now let's create it!:
Destroyable Doors
- Add an Actor >> NavigationPoint >> JumpDest >> JumpSpot >> GameObjective >> DestroyableObjective >> DestroyableObjective_SM, select a cool static mesh for it, and move it into the needed place
- Place the AntiPortalActor to the correct place (inside or behind the DestroyableObjective_SM), and set the following properties:
- Events -> Tag = MyTriggeredAP
- Object -> InitialState = TriggerToggle
- Select your Destroyable Objective SM, set the following properties:
- DestroyableObjective_SM -> AntiPortalTag = MyTriggeredAP
Our DestroyableObjective will deactivate the MyTriggeredAP tagged AntiPortalActor, when the objective is destroyed
- Check it in-game!
Standard Doors
- Create the whole door (including Movers, Triggers, but NavigationPoints don't affect our AP)
- Place the AntiPortalActor to the correct place (inside the door), and set the following properties:
- Events -> Tag = MyDoorAP
- Object -> InitialState = TriggerControl
- Select one of your Door's mover (only 1 mover if 2 movers for 1 door), set the following properties:
- Mover -> AntiPortalTag = MyDoorAP
The door will deactivate the MyDoorAP tagged AntiPortalActor, when the door starts opening, and will reactivate it when completely closed.
- Check it in-game!
Examples
Power Station Access Door - AS-Glacier
Suprise Door at Power Station - AS-Glacier
An Example
Imagine a level that has many static meshes that are "possibly" in the field of view, but most of them are obscured by a single mesh in the center of the level. A static mesh does not cause other meshes behind it to be discarded from the rendering queue as it will not occlude anything behind it. This means that all meshes within the field of view are rendered.
By placing an Antiportal into the center of the large static mesh in the middle of the level we force some occlusion to occur. The performance of the level would be increased as all of the static meshes completely behind the Antiportal would not be rendered.
Antiportals are particularly useful within maps that are based "outdoors" or have large areas of terrain. In these environments creating zones becomes problematic because of the ceiling height.
A Warning
AntiPortals are slow, and should be used sparingly in most cases. Once the number of Antiportals in use starts to increase, the number of AntiPortals starts to negate the rendering benefit of having those areas occluded. Also, it should be mentioned that though AntiPortals are created from brushes (that includes both 3d shapes and 2d sheets), they are not brushes themselves. In fact, though you can use brushes of any shape and size to make AntiPortals, the resulting area they occlude will ALWAYS be a box based on the extents of the original brush. This "box" rotates with the brush, so you can have diagonal boxes for occlusion.
Wormbo: That can't be correct. If AntiPortals were boxes, you'd see a lot more HOM effects. Can anyone confirm this, please? Category:Legacy Answer Needed
EntropicLqd: That is correct. Anti-portals are always hidden in other brushes or within mountains and stuff - which is why you don't see the HOM effects - there is always geometry in front. It'll be interesting to see if they are supported by UE3.
Wormbo: I used pyramid-shaped (square base, tip down) antiportals in JB-Aswan-v2 and both real-time wireframe view in UEd and rmode 1 in game suggest that they really occlude stuff behind the pyramid (i.e. not a box) shape.
EntropicLqd: Interesting. I've not done any mapping with the 2K4 editor - it's entirely possible that Epic improved their behaviour to make it more intuitive. I would expect rmode 1 to be the "arbiter of truth though". Certianly the description fits with how I remember it working in Devastation (although that was a long long time ago, and before 2K3 & 2K4).
The CPU overhead for occlusion with boxes and sheets are actually the same, as AntiPortals treat sheets as infinitely thin boxes. The CPU overhead for 8-sided cylinders is about 50% higher than for boxes, but this might be worth it if you only have a handful of complex static meshes up for occlusion.
If an Antiportal volume is not convex it will cause the game to hang as soon as the offending concave Antiportal is in view. (actually this is not true, last I tried it with the latest version of UT2004 it will just cause the antiportal to stop working entirely) A convex shape is one where the angle from any vertex to any other vertex is <= 180 degrees. A simpler way to think of it is that a straight line drawn between any two points on the surface of the shape must not go outside the shape.
Finally Sheets created in the 2D Shape Editor will not work as AntiPortalActors. I'm not exactly sure what the deal is, but if their in the view frustum they occlude EVERYTHING. You can use them as BSP surface Anti-portals just fine however.
Seeing the Antiportal Effect
Within UT2003 (works in devastation too) type RMODE 1 into the Console (see Console Commands for more information). This will place the renderer into wireframe mode. Static meshes and brushes will not be shown within this view if they are fully behind an Antiportal.
In UnrealEd, do the following in a 3D viewport:
- activate realtime preview
- Toggle Viewport Caption Context Menu -> View -> Show Volumes to show volumes
- view complexity mode (last button, funky green->red color ramp) can be useful to see if your antiportals are working. Turning off terrain (hit 't') and BSP (hit 'q') will let you see static mesh overdraw.
Related Topics
See the following pages for more information on level optimization.
- Map Optimization
- Zoning
- udn2:LevelOptimization - The UDN's level optimisation page.
- udn2:VolumesTutorial - the AntiPortalActors section at the bottom.
Discussion
Foxpaw: Above it refers to the "bounding sphere" of a static mesh. Is that referring to the collision data of the static mesh or something else?
inio: Bounding spheres are used for visibility (GetRenderBoundingSphere) and probably also for the first pass of collision tests. Spheres are used because plane/sphere and sphere/sphere tests are extremely fast.
inio: I added some info on Anti-portal BSP surfaces and expanded the AntiPortalActor section a bit. Also, all the bits about the bounding box being used for AntiPortalActors seem to be entirely incorrect (under no circumstances did I ever see the bounding box used instead of the actual geometry).
My testing methods for collecting data about what works, what doesn't, and performance:
- Make a 8k square cube
- by recursive duplication, spread about 4000 EffectMehses.DirtChunk_01aw static meshes around about say 4k square on the floor and scale them up a bit (drawscale = 3)
- for various antiportal setups, place 64 identical antiportals above this, with the camera locked in place at the top of the center of the 8k room looking straight down.
Tarquin: Roughly how many APs is ok – is there any rule of thumb, say, for the number of zones in the map, of the number of static meshes in total, or something?
EntropicLqd: Its going back a bit (and I've lost the original email due to a HD crash) but I remember the guy from the Devastation dev. team saying that once the number of AP's got above 9 they tended to become prohibitively expensive. That's on an earlier version of the engine though so some optimisation has almost certainly taken place.
Ragdoll:Ive seen devastation maps with way more antiportals than that. Im not sure sure if theres a limit to the number of zone antiportals you can have before it starts to become too costly though.
MythOpus: But do any of the Devestation maps use the newer level area occlude methods too? I forget what it is and how to do it. There's a page on the wiki but it involves telling the renderer to just not render certain parts of the map based on where the player is. Its different from the Anti-Portals and if you use both in conjunction it would probably ignore the limits and run better. Perhaps they've used that?