Acoustics and Reverb Management for AAA Shooters
Wwise Spatial Audio architecture: acoustic lifecycle, generated data and bounded runtime work in UE5.
A large multiplayer shooter can contain thousands of modular buildings across multiple maps, varied outdoor environments and structures that change during play. The challenge is choosing which acoustic objects exist for the listener now, keeping their data correct and bounding runtime updates.
This paper documents an architecture Flutu developed during an acoustic R&D study in 2026. It is written for technical audio directors, audio programmers and level teams working on streamed worlds.
It presents architectural decisions and a validation strategy, rather than a completed performance benchmark. Client and project details are omitted.
TL;DR
- 01
The architecture combines generated descriptors, a listener-relevant working set and a single Wwise adapter for acoustic ownership.
- 02
Runtime work is bounded through query and mutation budgets, cache invalidation and explicit lifecycle management.
- 03
Streaming, listener relocation, destruction and different environment types require deliberate update and fallback policies.
- 04
The manuscript defines architecture and a validation strategy. It does not supply source code, retained profiler captures or target-hardware measurements for this UE5 + Wwise design.
Why scale breaks the default setup
Rooms and Portals describe buildings. They do not, on their own, manage the population of acoustic objects across streamed maps.
The source considers a world-scale workload potentially approaching a million volume and portal records across the content estate. This is a planning scale, not a measured count of simultaneously registered objects.
Three problems drive the architecture.
Cost can track placed count
When each placed acoustic component schedules its own recurring work, updates can accumulate even when most objects are irrelevant to the listener. Listener resolution, neighbor checks and service dispatch can become significant alongside propagation itself. The distribution of those costs must be established in the actual integration version and project capture; it is not a universal profile of Wwise.
Correctness depends on repeated manual work
Hand-placed content can produce orphan portals, portals embedded in walls, volumes leaking into streets, overlaps and missing rooms. Across frequently revised maps, manual walkthroughs alone struggle to keep acoustic data aligned with level geometry.
Environments need different models
Interiors, cities, open terrain, forest and jungle expose different weaknesses in a single tracing or room recipe. Destruction and sudden camera relocation add lifecycle changes that a static placement workflow does not resolve.
The architectural target is therefore a bounded active set, controlled update cadence and a data pipeline that regenerates and checks acoustic content as the world changes.
Wwise Spatial Audio: from world data to runtime state
At editor time, authoritative level data is sampled into compact Room or Region Descriptors. Runtime selects the relevant descriptors, schedules bounded queries and state changes, then sends the resolved result through a single Wwise adapter. Validation reads the same data used by runtime.
| Stage | Input | Output or responsibility |
|---|---|---|
| Acoustic Probe | Topology, structural geometry, materials, biome data | Acoustic measurements and descriptor candidates |
| Room / Region Descriptor | Probe output and authored overrides | Bounds, class, materials, reverb, topology, destruction metadata, references and source hash |
| Acoustic World Subsystem | Streamed descriptors, listener and relevant emitters | Active working set and streaming state |
| Acoustic Query Scheduler | Relevant pairs, priorities and cached state | Budgeted terrain, dynamic-boundary and fallback queries |
| Dynamic Acoustic State Manager | Gameplay boundary events | Invalidation and coalesced topology mutations |
| Wwise Spatial Adapter | Resolved ownership and acoustic state | One translation path into Wwise |
| Validator | Descriptors, source data and runtime records | Data errors, lifecycle checks and regression reports |
- Authoritative world dataTopology, geometry, materials and biome data
- Acoustic ProbeEditor-time sampling
- Room / Region DescriptorGenerated acoustic contract
Validator ↔ descriptor: data errors, lifecycle checks and regression reports.
- Active working setRelevant Rooms, Portals and Geometry
- Query Scheduler + Dynamic State ManagerBudgeted queries and state changes
- Wwise Spatial AdapterOne translation path
- Wwise Spatial AudioResolved propagation
Five principles
- Bound runtime work by relevance. Registration, queries and reverb should follow the listener, relevant emitters and their paths. World size can still affect memory, streaming and discovery cost; bounded acoustic work is the design target, not a demonstrated constant-frame-time result.
- Generate per building type, then validate. A repeated building gets one reusable description. Custom hand-authored exceptions use the same validation path.
- Subscribe to change. Streaming, doors and destruction provide events. Periodic work belongs in a central scheduler over the active set.
- Use environment-specific models behind one contract. Rooms and Portals handle interiors; structural proxies, terrain queries and vegetation fields address other environments.
- Resolve ownership per boundary. The custom layer and Wwise must not independently apply the same attenuation to the same boundary.
The game team remains responsible for authoritative level topology, collision, material metadata, destruction state and gameplay priorities. The acoustic layer consumes those inputs; it does not infer production intent reliably from rays alone.
Generate per type, not per instance
A battle royale map is not thousands of unique buildings. It is a few dozen building types instanced thousands of times. That is the fact the whole data model is built on.
Hand-placing a reverb volume and two portals in every instance of the same farmhouse is how a map ends up with orphan portals, portals embedded in walls, volumes that leak into the street and rooms nobody placed. Tracking those errors after the fact is a losing race against a level that keeps changing.
Instead, each building type is described once at editor time and the description travels with the Level Instance. Volumes and portals are derived from it wherever the building appears. The hero building with the custom interior still gets hand-placed data, through an override workflow, and that data runs through the same validator as generated content.
The descriptor
The unit of acoustic data is a Room or Region Descriptor, stored with the streamed content it describes: bounds, acoustic class, material summary, reverb configuration, known portal topology or candidates, destruction metadata where the production exposes it, and the references runtime needs to activate it. It carries a hash of the source geometry and metadata it was computed from; if the level changes and the descriptor is not regenerated, the validator flags the drift.
The descriptor is the contract between editor tooling and runtime. Everything downstream (registration, environment classification, reverb selection, destruction response) reads it. Nothing downstream rediscovers it.
What the Probe is, and is not
The Acoustic Probe is the editor-time sampler that produces descriptors. It is worth being precise about its role, because the obvious version of it is wrong.
The obvious version shoots rays from inside a candidate room, finds where they escape and calls those portals. That fails on L-shaped rooms, stairwells, mezzanines and anything with a hole in the ceiling. A ray that escapes is evidence of an opening candidate, not a portal definition.
The proposed Probe treats production data as authoritative. If the level pipeline already knows doors, windows and room boundaries, the Probe enriches that topology with acoustic measurements: distances, enclosure, material summary, reverb parameters. If Physical Materials exist, it reuses them rather than inventing an audio-only taxonomy. If Wwise already estimates something at editor time (Reverb Parameter Estimation on AkLateReverbComponent), the Probe consumes or validates that rather than recomputing it. Structural geometry is sampled separately from movable props, so a sofa never redefines a room.
Geometric inference stays available as a fallback where no metadata exists, and the validator reports the gap rather than pretending the inference is intent.
How many Rooms
The descriptor hierarchy region → building → room does not mean three nested Wwise Rooms. Wwise handles irregular Room shapes, so an L-shaped space is not split for being non-convex. The rule is behavioral: one Room where the space behaves as one, several Rooms and Portals only where distinct areas need distinct propagation. Exterior space uses the Outdoors Room or a coarser region model. Portal count per room is governed by the measured path budget, not by a geometric decomposition rule.
Runtime mechanisms
The working set, listener lifecycle and environment models define which acoustic state is active and how it changes.
Register the working set
Not ticking is necessary. It is not sufficient. A Room or Portal registered with Spatial Audio costs audio-thread time whether or not its component ticks, so the second half of the problem is deciding what exists for Wwise at all.
Static objects do not Tick
The design calls for a versioned integration-source patch where configuration alone does not remove unnecessary static updates. Each Wwise upgrade must revalidate it. Static Rooms and Portals in the active working set remain registered without scheduling individual per-frame Tick. Dirty topology changes are consumed through explicit events or a central acoustic subsystem. Obstruction cadence and any other periodic work run from that subsystem over the active working set, not from every placed Portal. Per-component Tick remains only for objects whose runtime behavior genuinely needs it, at a controlled interval.
Two integration settings deserve an A/B on the real project before anything else: Is Dynamic on Rooms and Portals, which recomputes connections when an object moves and which Audiokinetic documents as expensive in worlds with many of them, and Obstruction Refresh Interval on Portals, which can be set to 0 where Spatial Audio Geometry already supplies diffraction and transmission. Neither value is visible in a trace, so they are configuration checks, not confirmed causes.
The set is not a radius
The tempting rule is "register what is within N meters of the listener." It silences the gunshot that matters. A player firing inside a building 150 meters away is perceptually relevant, and for that shot to sound right the Room and Portal graph of that building has to be alive even though the listener is nowhere near it.
The rule is therefore: listener + relevant audible emitters + the acoustic paths those emitters need. The spatial index is the project's World Partition grid, not a custom structure. Three tiers, by audible distance rather than visual:
| Tier | Scope | Registered state |
|---|---|---|
| 1 | Listener's cell, its neighbors, and any cell holding a relevant emitter | Rooms, Portals, Geometry; full behavior |
| 2 | One ring further | Rooms and Portals; Geometry unregistered; state updates at reduced interval |
| 3 | Everything else | Nothing; descriptors stay in memory, ready to activate |
Portals in tier 2 stay registered because they serve emitters, not only the listener.
Keeping the set stable
- Hysteresis at cell boundaries, so a player standing on an edge does not register and unregister rooms every frame.
- A registration budget per frame with an async queue. Crossing into a dense city cell cannot register 200 rooms in one frame; the budget is what keeps frame time flat, and flat is the requirement.
- Symmetric register and unregister across every streaming cycle. If a cell streams in and out five times, Wwise sees five of each. Nothing leaks, and a long-session test must establish that registered counts and costs do not drift upward.
- Client-local. The server runs none of this; each client evaluates its own listener.
The intended effect is that the number of registered objects becomes a function of density around the relevant points, not of map size. The validation design checks registration symmetry and runtime budgets.
When the listener relocates
Most acoustic optimization assumes a listener that walks. A shooter listener drives at 120 km/h, falls from a plane, respawns, switches to a teammate's camera in spectator mode and jumps across the map in a kill-cam cut. Any system that passes on a walking path and fails on a camera cut is not shippable, so the listener model is a design requirement from day one, not an edge case handled at the end.
What that changes:
- Pre-warming or an honest bad frame. When the listener relocates abruptly, the destination cell's working set is not loaded. Either the cut is known in advance (kill-cam, spectator switch) and the destination is pre-warmed before the camera moves, or the system uses a conservative default acoustic state during a bounded convergence window while the new set converges. The acceptable delay must be established in project tests. One of them has to be chosen deliberately and documented.
- Relocation is a cache-invalidating event. Every async trace in flight carries a listener epoch. Results that arrive after the epoch changed are discarded, so a trace cast from the old position never lands on the new one.
- Nearby first. On relocation the subsystem prioritizes the listener's immediate environment, then relevant emitters, then the ring. A few frames of coarse exterior reverb while a building's rooms load is tolerable; a few frames of the wrong building's reverb is not.
- No privileged path. With 100 players there is no route to optimize around. Budgets are dimensioned for the worst representative case: a dense city block, a firefight with twenty emitter pairs, a vehicle crossing three cells in two seconds.
The proposed runtime validation harness must replay: traversal, vehicle, cell crossing, spectator switch, kill-cam cut, respawn.
A model for each environment
A line trace answers one question: is there something between A and B, and what is it. That is enough geometric evidence for an obstruction decision. It is not enough to tell obstruction from occlusion (which depends on whether emitter and listener share a Room), not enough for diffraction (which needs edge and path information) and not enough for reverb (which needs a description of the space). Ask more of rays and the count stops being bounded.
The environments in a battle royale make this worse, because the same raycast recipe fails in opposite ways in each one. So the runtime has one contract (a fixed-budget query scheduler that classifies the direct path, the surface that blocked it and whether terrain intercepts it) and a different model behind that contract per environment.
City
The densest and the most expensive per ray. Every trace hits something, and building collision is complex. Sound crosses several portals between emitter and listener, each path with a cost. The city is vertical: a sniper on the sixth floor and a listener on the street are not resolved by a horizontal ray. The street itself is a semi-enclosed space that needs its own reverb or it sounds too dry. And the city is where emitter spikes happen: a firefight in a square with twenty players is twenty trace pairs at once.
The model: static structure belongs to Wwise. Rooms, Portals and simplified Spatial Audio Geometry carry propagation for buildings; the street or block is the coarse parent region for the rooms inside it. Between buildings, runtime queries trace against simplified structural proxy collision, never render meshes or incidental props, with transmission data read from the same material source the rest of the game uses. Custom queries are reserved for dynamic objects and boundaries that the static model does not represent: vehicles, doors in motion, breached walls.
Interiors
The simplest case, and the one that justifies Rooms and Portals. Emitter and listener inside the same room: clean direct path, preset reverb, no structural trace at all. Listener outside: sound passes the portal with diffraction, reverb leaks through the portal, the rest passes through the wall with the material's transmission loss. Wwise does all of that.
Dynamic objects inside a known room are a direct-path obstruction problem; the room model supplies the reverberant context around them. The one rule is that the probe queries structural geometry separately from movable props so that furniture never redefines the room itself.
Open field and terrain
Inverts the city. There is little structural geometry to hit, so query cost is low, but terrain becomes the dominant occluder and long audible distances multiply the number of relevant emitters. A single terrain hit says nothing about whether a ridge is a shallow bump or a hill that should bury a gunshot.
The model: terrain stays outside the room and portal graph in every outdoor biome and is queried through the cheapest current-state representation the project exposes, usually landscape collision or height data, with an eye-height ray as the baseline. High-priority emitters may justify a few extra samples to distinguish a shallow ridge from a real obstruction; distant emitters stay on the cheap model. Exterior reverb and ambience send are explicit design parameters; an open field is not acoustically dry just because it has no walls.
If terrain is deformable, the query has to see current local state or the affected terrain cache has to be invalidated on deformation. A global rebake is not an option.
Forest
The environment where per-instance tracing stops being a model at all. Foliage is instanced and collision-heavy. Treating every trunk and leaf as a binary occluder produces both unstable cost and the wrong sound: hit a leaf and the enemy goes silent.
The model: no per-tree raycasts. At editor time the Probe derives an acoustic vegetation field from whatever reliable environment data exists (foliage density, instance maps, biome tags). At runtime the emitter-listener pair samples that field along the path. Accumulated density drives partial obstruction, spectral roll-off and ambience response, calibrated by listening tests rather than treated as literal hard occlusion. Terrain remains a separate query underneath. The acoustic weight of vegetation is a gameplay and listening decision, not a geometry one.
Jungle
Forest with two aggravations: dense foliage at every height and a canopy that closes overhead, plus uneven terrain, water and ravines. Visibility is very low but sound must carry, or the player does not hear the enemy at fifteen meters and the biome becomes unplayable.
Same mechanism as forest, with canopy and enclosure information in the descriptor where the environment data supports it and denser vegetation parameters. The mechanism stays bounded; only the descriptor and the calibrated mapping change.
Transitions
If each biome runs a different model, the boundary between them is its own problem. Without blending, the sound changes personality in one step as the player leaves the treeline. Environment classification is interpolated with a few meters of hysteresis, and reverb or send changes are smoothed, so the move from room to street to field to forest reads as one continuous world.
Environment matrix
| Environment | Dominant problem | Model | Excluded shortcut |
|---|---|---|---|
| City | Dense collision, verticality, emitter bursts | Wwise Rooms and Portals plus structure proxies between buildings | Tracing against render meshes or props |
| Interiors | Room topology | Wwise Rooms and Portals; traces only for dynamic objects | Structural traces inside a known room |
| Open field | Terrain, long audible distances | Terrain query outside the room graph; eye-height ray | Treating a terrain hit as a full occlusion |
| Forest | Instanced foliage | Preprocessed vegetation density field sampled along the path | Per-tree raycasts |
| Jungle | Foliage at all heights, canopy, water | Same field, denser parameters, canopy descriptor | Letting a leaf hit silence a source |
| Transitions | Model boundaries | Interpolation and hysteresis | A one-frame switch |
Destruction as acoustic state
This is the requirement that breaks precomputation. Rooms, Portals, geometry sent to Wwise, baked reverb, cached trace results: all of it assumes the walls stay where they were. When a wall falls, a room stops being closed, a portal that did not exist now exists and every cache for that space is stale.
The naive responses both fail. Recomputing Wwise geometry on every destruction event across a large map is a spike generator. Re-checking every wall every frame to catch changes is worse. The cost of destruction has to be proportional to the number of destruction events, not to the number of rooms.
Destruction is state, not geometry
Destruction is one case of a broader dynamic acoustic boundary system that also covers doors, windows, gates, elevators and moving structures. The principle is the same for all of them: the gameplay system already knows when the boundary changed, so the acoustic system subscribes to that change instead of discovering it.
Where the production exposes predefined destruction states, a wall moves through a small number of acoustically meaningful states, Intact → Breached → Collapsed, rather than updating on every bullet hit. Each state has its acoustic consequence precomputed in the descriptor: which opening becomes active, which transmission loss applies, whether the room still behaves as a room. A transition is a lookup, and it invalidates only the emitter-listener caches that cross that boundary.
Openings that did not exist
When destruction creates a passable hole, the propagation model has to represent it. If the possible openings are predictable (which is the common case with modular building kits) the cheapest answer is pre-created disabled Portal candidates baked by the Probe at the positions destruction can produce. Enabling one is a state change on stable topology, not a runtime Portal creation. Their registered footprint counts against the same working-set budget as every other Portal, and the validation design checks state coverage and opening candidates where a state requires an opening.
Continuous resizing of a Portal as a hole grows with each shot is avoided; a few states cover it.
The fallback window
Between the frame a wall falls and the frame the new Spatial Audio topology is ready, the system does not need a perfect answer. The changed boundary temporarily falls back to a local direct-path obstruction and transmission model driven by the custom query layer, and the Room or Portal update follows once it is evaluated. For arbitrary destruction with no predictable states, this fallback is the steady answer: the event still provides the invalidation boundary even when no precomputed opening exists.
One ordering rule matters: the acoustic update runs after the collision representation the query uses reflects the new gameplay state. Otherwise a correct invalidation faithfully recomputes the old wall.
Keep the Room
When a wall falls and a room opens on one side, retaining the Room while opening the relevant boundary is a design option to compare with an exterior transition. Its cost and sound require project-specific validation. The Room is deactivated only when destruction effectively turns the space into exterior.
Mutation budget
A destruction burst (a grenade in a hallway) can dirty several portals and geometry sets at once. Issuing every SetPortal and geometry call in the destruction frame simply moves the spike from Unreal collision into the Wwise command queue, which Audiokinetic documents as capable of blocking the caller when it fills. The Dynamic Acoustic State Manager therefore owns its own budget: dirty boundaries are coalesced, prioritized by proximity to the listener and relevant emitters, and spread across frames. SetPortal has no fixed cost; it depends on the active graph, so it is profiled on the real map and rate-limited from the measurement.
What this needs from the game
Three inputs change the design and have to be known before it is built: whether a runtime-accessible destruction state exists and at what granularity (wall, floor, building); whether terrain is static at runtime or can deform; and whether destructible pieces carry the same material metadata as the rest of the world. With those answered, destruction becomes a state machine the audio system reads, not a geometry problem it solves.
| State | Descriptor decision | Runtime check |
|---|---|---|
| Intact | Closed-boundary transmission and topology | Current collision and ownership match intact state |
| Breached | Known opening candidate where available; revised transmission | Activate the applicable opening after collision changes |
| Collapsed | Determine whether the space still behaves as a Room | Retain an open Room or transition to exterior according to the descriptor |
These are acoustic states from the source design. They do not imply that every state creates a Portal. An intact wall may require no active opening, and arbitrary destruction may have no predefined Portal candidate.
- Intact
- Breached
- Collapsed
Boundary state changes trigger the acoustic update path below.
- Boundary event
- Collision state ready
- Invalidate affected caches
- Exclusive fallback ownership
- Budgeted topology update
Bound reverb per listener
One authored reverb per room does not scale, operationally or technically. A map with five thousand rooms is not a map with five thousand reverb settings to maintain, and it is not a map that can afford five thousand reverb instances to exist.
The design invariant is a per-listener cap on active reverb work, separate from the number of loaded descriptors.
Reverb is classified from the descriptor at bake time, not solved from rays at runtime. Each room references one of a small shared set of reverb configurations (shared Aux Busses, or a shared dynamic reverb model where the project's mix architecture prefers it). The Probe contributes the room parameters that select the configuration; runtime modulates only what genuinely changes, usually send level, with an enclosure or density RTPC where it earns its place. Very small spaces inherit or blend with a parent configuration rather than owning one.
The active set per listener is hard-capped from target-hardware profiling. The working model is the current space, the relevant adjacent space through the nearest portal, and the coarse parent or exterior context. What matters for cost is active sends, effect instances and propagation paths, not the number of authored rooms. The exact size of the shared set is a profiling and listening outcome, not a number chosen up front; the validator refuses any room assignment outside it.
Two diffraction paths
Diffraction, reverb and transmission have different responsibilities in this architecture. Diffraction models a path bending around an edge; the material mapping separately controls transmission and absorption. It is direct sound bending around an edge: a shot in a room whose door is open but around the corner reaches the listener slightly muffled and from the direction of the corner. Material governs two other things, transmission (how much passes through) and absorption (how much reflects back).
Computing diffraction properly needs edge and path information that a straight emitter-to-listener ray does not carry. The design gives it two execution paths, selected by who owns the boundary.
Tier A, Wwise-owned. Inside buildings and wherever a Room and Portal graph is active, Wwise computes portal-edge diffraction and exposes the diffraction value and apparent path that drive the authored filtering. Rooms and Portals cover the common interior case without Spatial Audio Geometry on every wall. Simplified geometry is added only where multi-edge diffraction or early reflections are needed, and only after proxy quality and the path limits (uMaxDiffractionOrder, uMaxDiffractionPaths, uMaxGlobalReflectionPaths) are bounded.
Tier B, custom single-edge approximation. For boundaries outside the active graph, which is most of the outdoors: building exteriors, terrain ridges, destruction fallbacks, biomes running without Rooms. When the direct ray is blocked, the scheduler evaluates a small bounded fan of candidate rays, four to six, or edge candidates the descriptor already knows, and picks the lowest-cost valid path with hysteresis so the choice does not flicker. Bend angle drives level and low-pass; a virtual-source proxy drives apparent direction without replacing the true emitter position used for distance and gameplay. Tier B resolves one edge and produces no reflections, by design. It is the bounded fallback, not a second simulation.
Where a boundary needs more than one bend, ownership goes back to Tier A with simplified geometry, and the two results are compared side by side on agreed reference scenarios before either ships.
| Path | Ownership | Representation | Limit |
|---|---|---|---|
| Tier A | Wwise | Active Room / Portal graph; simplified geometry where needed | Path, order and reflection limits require profiling |
| Tier B | Custom query layer | Bounded candidate rays or descriptor edge candidates | Single-edge approximation; no reflections |
Integration and ownership
One owner per boundary
Wwise already provides Rooms, Portals, transmission and diffraction. Adding a line trace system on top as an independent layer produces two answers for the same emitter-listener pair, and they disagree. The gunshot behind the wall is attenuated by Wwise's transmission loss and then again by the custom trace that hit the same wall. The problem is not choosing one system; it is making both consume the same data and never the same boundary.
The adapter
The Wwise Spatial Adapter is the single boundary between the runtime model and Wwise. Ownership is resolved before any value is sent:
- A static boundary represented by Wwise Rooms, Portals or Geometry is owned by Wwise for diffraction, transmission and room propagation.
- A dynamic or temporary boundary not represented in Spatial Audio is owned by the custom query layer, which sets the direct-path modifier.
- The same boundary is never processed by both at the same time.
Where the custom layer owns obstruction for an emitter, the integration's periodic line-of-sight checks for that emitter are disabled (refresh interval 0) and the scheduler writes the result directly through the obstruction and occlusion API. Room, Portal, transmission and geometry data go through their own Spatial Audio calls. RTPCs are reserved for values with no native channel: the vegetation field, a Tier B bend angle.
Environment-specific logic terminates before the adapter. Whatever biome the listener is in, Wwise receives the same bounded state.
Two budgets, not one
Stable performance requires controls on two independent processing axes. Moving cost from one to the other is not an optimization.
| Budget | What it bounds | Controls |
|---|---|---|
| UE acoustic query budget | Custom traces per frame for terrain, dynamic geometry, Tier B diffraction | Emitter priority, distance, update class, cache age; a maximum stale age per class so nothing starves |
| Wwise Spatial Audio budget | Ray and path counts, diffraction and reflection order, room sends, load balancing, CPU ceiling | uNumberOfPrimaryRays, uMaxDiffractionOrder, uMaxDiffractionPaths, uMaxGlobalReflectionPaths, uLoadBalancingSpread, fCPULimitPercentage |
Emitters are scheduled by update class as well as priority. A gunshot gets an event-time evaluation. A vehicle gets periodic updates. A static persistent emitter reuses cached state. Distant ambience is descriptor-only. Async traces return on a later frame, so every request carries a listener epoch, descriptor revision and emitter generation, and a stale result is discarded.
Runtime ownership
Four responsibilities, not one monolithic acoustic actor:
- Acoustic World Subsystem: active descriptors and their streaming state.
- Acoustic Query Scheduler: priority, cadence, cache age and the UE budget.
- Dynamic Acoustic State Manager: destruction, doors and moving boundaries; invalidation and the Wwise mutation budget.
- Wwise Spatial Adapter: the one translation layer into Wwise.
The objective is not perfect acoustic simulation. It is a system whose quality degrades predictably before either budget becomes unstable.
| Emitter class | Update policy in the design |
|---|---|
| Gunshot | Event-time evaluation |
| Vehicle | Periodic updates |
| Static persistent emitter | Reuse cached state until refresh or invalidation |
| Distant ambience | Descriptor-only response |
Registration and Wwise topology mutation also require their own per-frame limits. They are lifecycle controls alongside the UE query and Spatial Audio processing budgets. All limits must be selected from target-hardware profiling, not copied from the illustrative scenarios in this paper.
Validation and listening QA
Inventory without opening every Level
Placed AkSpatialAudioVolume and AkAcousticPortal are Level Actors, not Content Drawer assets. Auditing them by opening every Level and Level Instance in the editor is how nobody audits them. The inventory tool separates discovery from inspection.
For World Partition content with One File Per Actor, FWorldPartitionActorDesc exposes actor identity, class, bounds, Data Layers and parent relationships while the actor is unloaded, and the external package path resolves the source Level. That supports discovery; coverage still depends on the project’s storage and Level Instance conventions. It is not enough to read Ak component settings, so the tool selectively loads the smallest unit that holds a missing field (the external actor package where possible), reads it and unloads. For a production inventory, the audit-critical fields (Is Dynamic, Priority, Initial State, Obstruction Refresh Interval, aux bus) are materialized into actor metadata on save, so later passes load nothing at all.
Ownership is recorded as two fields, not one, because a source Level can be instanced many times: Actor → Source Level → Level Instance placement → Parent Level Instance. One C++ core, exposed as a CI commandlet, an Editor Utility and a Python entry point, writes one searchable schema.
What automation can check
The useful distinction is not "data can be automated, sound cannot." It is: deterministic invariants, consistency, lifecycle and performance are rule-checkable; perceptual quality and ambiguous intent are not.
Deterministic rules to check in the validation pipeline:
- Every Portal resolves to two distinct acoustic spaces, which may include the Outdoors Room. One sample point on each side of the Portal box must resolve to a different space; both resolving to the same Room signals a topology or orientation error to investigate.
- The Portal box straddles a boundary. Embedded in one Room or floating in nothing is an error. Sides in different streaming cells are flagged unless the runtime re-evaluates the connection on stream in and out.
- Geometry sanity: non-finite vertices, degenerate triangles, unresolved acoustic textures, broken edge continuity where diffraction is enabled.
- Overlapping Rooms have distinct priorities, because Wwise does not guarantee which equal-priority Room wins.
- Every reverb assignment is inside the shared set; every destructible boundary covers its supported states and has an opening candidate wherever that state requires a predictable opening; every material tag exists in the material table.
- Descriptor hash matches source geometry; a source change re-validates adjacent Rooms and Portals, not only the modified file.
- Registration is symmetric across streaming cycles; nothing stays registered after an unload.
- Listener relocation invalidates listener-local cache.
- UE query count, Wwise path complexity, active object counts, cache age and mutation spikes stay inside budget; gates are set above measured run-to-run variance, on p95/p99 across representative routes, on target hardware.
- Required Wwise resources and acoustic data survive cook and package.
Not rule-checkable: whether the reverb sounds convincing for the space, whether diffraction feels right around a specific corner, whether the treeline transition feels natural, whether footsteps stay readable under fire, and whether a geometrically plausible opening was ever meant to be a Portal.
The validation plan has five layers: editor validation on save, the same rules headless in CI on submit (changed content plus its acoustic dependencies) and on scheduled full-world builds, a runtime scenario harness on packaged builds, a separate performance regression run with minimal instrumentation, and a packaged-build check. The runtime adapter is designed to keep a shadow registry of every Room, Portal and Geometry call sent to Wwise, because no single API returns the full registered state. CI reports or fails; it never silently rewrites content.
Listening QA
A volume that exists, is correctly oriented, inside budget and sounds wrong passes every check above. Listening QA, with reference recordings per space typology and a pass over every generated region and every new system, is the measure the profiler cannot take. It is a seat on the team, not a phase at the end.
Check the mix before adding DSP
Acoustic work at this scale changes how much direct sound, room send, transmission and reverberant energy reaches the master, and the symptoms show up in the mix: compression pumping when weapons enter, abrupt ambience transitions, masking under fire. They read like a missing DSP feature. A mix diagnosis is needed before attributing these symptoms to a missing DSP feature.
Playback Priority is not compression. Priority, playback limits and virtual voices decide which voices stay physical, go virtual or get stolen; the audible gain movement has to be found separately in HDR, auto-ducking, Meter-to-RTPC side-chaining, bus dynamics or the master chain. Wind that appears and disappears on an altitude trigger is state behavior.
So the order is: a mix health pass first, combining Wwise Profiler telemetry (voice counts and stealing, HDR window movement, bus levels, RTPC rate of change, send levels before the master) with active listening on the same stress scenarios the validator replays. Then voice management, then routing and HDR and ducking, then spatial contribution, then the native master chain, each step measured and listened to again. A custom Wwise Effect plug-in enters only when a precise requirement survives all of that, with a frequency band and a number in it. "The mix pumps" is a symptom. "Weapon energy between 1.5 and 4 kHz needs to reduce the same band in ambience while preserving low-frequency environmental energy" is a DSP requirement.
A profiler can say that a bus is ducking. It cannot say whether the player should perceive that ducking.
What the evidence establishes
The supplied manuscript describes the R&D architecture and reports experience from an earlier Unity + FMOD system. It does not include source code, profiler captures, retained test logs or target-hardware measurements for this UE5 + Wwise architecture. The following boundaries apply to the claims in this paper.
Runtime bounds
- Available support
- Working-set, scheduling and ownership rules in the manuscript
- What it establishes
- A concrete strategy to implement and test
- Limit
- No measured CPU, memory or frame-time result supplied
Generated descriptors
- Available support
- Per-type descriptor and override workflow
- What it establishes
- The repeated authoring step addressed by the design
- Limit
- No measured time saving or error reduction supplied
Lifecycle and validation
- Available support
- Boundary states, listener epochs, descriptor revisions and emitter generations
- What it establishes
- The proposed invalidation contract
- Limit
- No retained execution log confirms all transitions
- Available support
- Inventory and validation specification
- What it establishes
- A rule set and test strategy
- Limit
- Validator implementation and CI coverage are not independently evidenced
Production provenance
- Available support
- Source author reports a shipped Unity + FMOD predecessor
- What it establishes
- Reported provenance of the scheduling and caching questions
- Limit
- It does not validate UE5 integration or Wwise-specific behavior
About this paper
This paper documents architecture Flutu developed during an acoustic R&D study in 2026 on a UE5 + Wwise battle royale test project. It builds on a listener-centric raycast obstruction and occlusion system Flutu designed and shipped earlier in Unity + FMOD, which went through a full architectural revision as that game scaled; the trace budget, caching and recompute questions here are the same questions at world scale. Client, project, team and commercial details are intentionally omitted.
Trade-offs and limits
The architecture moves work into tooling, data ownership and lifecycle management. That is a production investment. A compact level with modest acoustic density may be better served by the standard integration workflow and careful configuration.
Model fidelity and tooling
A versioned integration patch introduces upgrade work. Descriptor generation requires dependable source data and a policy for authored overrides. A vegetation field trades geometric detail for stable, tunable behavior. Tier B diffraction resolves one bend without reflections and needs reference listening tests before it can be accepted for gameplay.
Budget trade-offs
Hard budgets introduce latency or reduced detail when demand exceeds capacity. Camera cuts, streaming stalls and destruction bursts need a deliberate fallback and a measured convergence window. The source does not establish that a single fallback frame is sufficient.
Boundary ownership
Ownership transfer is a correctness requirement. Falling back to the custom layer while stale Wwise geometry still represents the same wall can produce double attenuation. The adapter must suppress the old contribution or otherwise make the transfer exclusive before applying the replacement.
Execution scope
The lifecycle design is client-local for the listener considered here. Dedicated-server execution, split-screen listeners and multi-listener ownership need separate requirements. This paper does not establish their implementation.
Applying the method
- Capture a baseline on target hardware. Record the UE, Wwise and integration versions, active object counts, component updates, query cost, Spatial Audio cost and representative audio output.
- Audit existing content and configuration. Check Is Dynamic, obstruction refresh behavior, Room priorities, Portal orientation, material assignments and reverb routing before patching the integration.
- Choose a repeated building type and one custom exception. Produce descriptors, source hashes and overrides, then test regeneration after a level change.
- Implement a small working set. Exercise audible remote emitters as well as listener proximity. Verify symmetric registration over repeated stream-in and stream-out cycles.
- Assign boundary ownership through the adapter. Test a static wall, a dynamic obstacle and a destruction transition for duplicate attenuation and stale state.
- Add query classes, cache invalidation and bounded mutation queues. Include listener epochs, descriptor revisions and emitter generations in asynchronous results.
- Calibrate the environment models and reverb set through reference listening tests. Keep terrain and vegetation responsibilities distinct.
- Replay traversal, vehicle movement, cell crossings, spectator switches, kill-cam cuts, respawns and destruction bursts in packaged builds. Compare p95/p99 timing, active counts, cache age and audio output against the baseline.
- Set regression gates above measured run-to-run variance. Keep a minimally instrumented performance run separate from detailed diagnostic captures, and verify required resources after cooking and packaging.
Advance from one representative area to a whole world only after the data, lifecycle and listening checks agree. A passing counter is useful; it does not establish whether an enemy remains readable through the treeline.
Glossary
| Term | Meaning in this paper |
|---|---|
| Spatial Audio | Wwise's Room, Portal and Geometry propagation framework (AkSpatialAudio) |
| AkPortalComponent | The Wwise component connecting two Rooms acoustically; its recurring updates are a profiling candidate in large integrations, rather than a confirmed bottleneck here |
| Is Dynamic | Room/Portal setting that recomputes connections when the object moves; expensive at scale |
| Obstruction Refresh Interval | Portal setting controlling line-of-sight checks; 0 disables them |
| World Partition, OFPA | UE5 cell-based streaming and One File Per Actor storage |
| Actor Descriptor | FWorldPartitionActorDesc; actor metadata readable while the actor is unloaded |
| Level Instance | A reusable Level placed one or more times in the world |
| Acoustic Probe | Editor-time sampler that enriches authoritative topology with acoustic measurements |
| Room / Region Descriptor | Generated data stored with streamed content: bounds, class, materials, reverb config, portal topology, destruction metadata, source hash |
| Working set | The Rooms, Portals and Geometry active for the listener, relevant emitters and their paths |
| Acoustic vegetation field | Preprocessed density and enclosure data sampled along a path in forest and jungle instead of per-tree traces |
| Dynamic acoustic boundary | Any boundary that changes at runtime: destructible wall, door, window, gate, moving structure |
| Wall state | Intact, Breached, Collapsed; each with its acoustic consequence precomputed |
| Wwise Spatial Adapter | The single ownership boundary translating runtime acoustic state into Wwise calls |
| Tier A / Tier B diffraction | Wwise-owned portal-edge diffraction versus a custom single-edge approximation outside the active graph |
| Shadow registry | Application-side log of every Room, Portal and Geometry call sent to Wwise |
Questions We Can Answer
Why does Flutu publish technical whitepapers?
Around 99% of our projects are covered by strict non-disclosure agreements. That limits how much we can share through named case studies, project footage or internal production material.
Whitepapers give us a way to document how we have helped AA and AAA teams develop working methods, implementation standards and validation workflows, while respecting those confidentiality commitments. We focus on the methods, technical reasoning and evidence we can share without exposing protected project details.
This gives prospective partners a clearer basis for technical evaluation and due diligence: how we investigate systems, structure production work and check results. Each paper distinguishes what was implemented, what was observed and what remains unverified.
How do you manage Wwise Rooms and Portals in large streamed worlds?
The proposed approach generates Room and Region Descriptors from authoritative level data, maintains a listener-relevant working set, and schedules registrations and updates under explicit budgets. It still requires target-hardware profiling; this paper does not report a measured UE5 and Wwise performance result.
How should destruction update a game's acoustic state?
Door, window and destruction events should invalidate affected acoustic data and paths. The architecture coalesces changes, uses explicit fallback behavior during transitions and assigns one owner per acoustic boundary before applying updates through Wwise.
What is the difference between reverb, diffraction and transmission?
Reverb describes reflected sound energy within a space; diffraction describes sound bending around an edge; transmission describes sound passing through a boundary. The design keeps these responsibilities separate so a custom layer does not attenuate the same boundary twice.
What evidence is needed before this architecture ships?
Validate data generation and lifecycle rules, measure query and Spatial Audio costs on target hardware, and compare packaged-build stress scenarios. Listening QA remains necessary. The study defines these checks but does not provide retained profiler captures or benchmarks for this UE5 and Wwise design.