Version

menu_open
Wwise SDK 2021.1.14
Advanced Topics in Rooms and Portals

Combining Rooms and Portals with Obstruction and Occlusion

In the context of Wwise Spatial Audio, sound propagation from other rooms is entirely managed by the Rooms and Portals abstraction. Rooms with at least one propagation path to the listener via open Portals will simulate diffraction using either Obstruction or the Diffraction built-in game parameter. Additionally, rooms will utilize Wwise Occlusion to model transmission of sound through walls.

If you wish to implement your own solution for obstruction (for example, one driven by game-side raycasting), in conjunction with obstruction set from Spatial Audio, the game may use the sound engine API AK::SoundEngine::SetObjectObstructionAndOcclusion. For the occlusion of portal openings, the game may use the Spatial Audio API AK::SpatialAudio::SetPortalObstructionAndOcclusion. You can also apply obstruction on the sound path between an emitter and a nearby portal, a listener and a nearby portal or a pair of consecutive portals with the help of AK::SpatialAudio::SetGameObjectToPortalObstruction and AK::SpatialAudio::SetPortalToPortalObstruction. Under no circumstances should the game call AK::SoundEngine::SetObjectObstructionAndOcclusion with a room ID as the game object parameters, as the results are undefined. Refer to section Modeling Obstacles Within a Room for more detail on how to use same-room obstruction with Spatial Audio.

Refer to Spatial Audio Concepts for a review of these acoustic concepts.

Modeling Obstacles Within a Room

Obstruction of sound emitted from the same room as that of the listener can be handled by using Geometric Diffraction (see Using the Geometry API for Simulating Diffraction and Transmission and Combining the Geometric APIs with Rooms and Portals) but it is not covered by Spatial Audio Rooms and Portals alone. If one does not wish to send geometry to Spatial Audio for the purpose of obstruction calculation, obstruction in the same room must be handled on the game side. The representation of geometry, methods, and the desired level of details for computing in-room obstruction is highly game-engine specific. Games typically employ ray-casting, with various degrees of sophistication, to carry out this task. This section provides some tips on how to implement obstruction on the game side in conjunction with Rooms and Portals.

With Spatial Audio Rooms and Portals though, you don't need to do this for all emitters, but only those that are in the same Room as the listener. This is beneficial because ray-casting is usually much more expensive than the algorithm used by Spatial Audio for computing propagation paths. Since in-room obstruction between an emitter and the listener happens in the same room, by definition, we assume that the obstacle will not cover the listener or emitter integrally, and that the sound will reach the listener through its reflections in the room. This can be properly modeled by affecting the dry/direct signal path only, and not the auxiliary send, which means that Obstruction is the proper mechanism. For this purpose, the game should call AK::SoundEngine::SetObjectObstructionAndOcclusion.

Furthermore, Portals to adjacent rooms should be considered like sound emitters in the listener's Room. Therefore, games should also run their obstruction algorithms between the listener and the Portals of the Room in which it is. Then, they need to call AK::SpatialAudio::SetPortalObstructionAndOcclusion for each of these portals in order to safely declare in-room obstruction with the listener.

Modeling Rooms With No Portals

Consider a meadow surrounded by a forest. This space with no trees likely has reverberation characteristics that are different from deep inside the forest. It could be implemented as a separate room, but it has no door. Therefore, it cannot rely on portals and portal diffraction to propagate sound. Instead, it must rely on transmission. You can create such a room by ensuring its transmission loss represents the occlusion at the interface. In this case it would be zero, or close to zero. The key is that Spatial Audio needs to be told explicitly that the meadow and the forest are connected, and this is done by connecting them with a disabled portal. This is achieved as follows:

paramsRoom.TransmissionLoss = 0.f; // We want sound to flow from one room to another unoccluded.
paramsRoom.strName = "Meadow";
paramsRoom.ReverbAuxBus = AK::SoundEngine::GetIDFromString("Meadow_Verb");
AK::SpatialAudio::SetRoom(MEADOW_ROOM, paramsRoom);
// Connect the meadow room to the forest explicitly using a mock portal, so that Spatial Audio knows that it needs to compute
// sound propagation between these two rooms. Make it "disabled" so that sound does not propagate/diffract through this portal.
AkPortalParams mockPortal;
mockPortal.bEnabled = false;
mockPortal.BackRoom = MEADOW_ROOM;
mockPortal.FrontRoom = FOREST_ROOM;
AK::SpatialAudio::SetPortal(MOCKPORTAL, mockPortal);

Implementing Complex Room Reverberation

It is possible for the game to use AK::SoundEngine::SetGameObjectAuxSendValues in conjunction with Spatial Audio rooms. The game's sends will be added in addition to the send to the room object's auxiliary bus, as defined by AkRoomParams::ReverbAuxBus.

Additionally, it is possible to use AK::SoundEngine::SetObjectObstructionAndOcclusion or AK::SoundEngine::SetMultipleObstructionAndOcclusion with Spatial Audio emitters, even though Spatial Audio also uses obstruction and occlusion for modeling diffraction and transmission, respectively. In any case where a API-driven occlusion/obstruction value competes with Spatial Audio driven values, the maximum of the two will be used in the sound engine. Refer to section Modeling Sound Propagation from Other Rooms and Modeling Obstacles Within a Room for more details on obstruction and occlusion and how to use them with Spatial Audio Rooms and Portals.

The sound engine API AK::SoundEngine::SetGameObjectAuxSendValues may be used to add additional Auxiliary Sends to the ones that are set by Spatial Audio. This may be useful when designing complex reverberation within the same room, for example, if there are objects or terrain that call for different environmental effects. A Room's AkRoomParams::ReverbAuxBus can also be left to "none" (AK_INVALID_AUX_ID), so that its send busses are only managed by the game via AK::SoundEngine::SetGameObjectAuxSendValues.

See also
Parameters passed to SetPortal.
Definition: AkSpatialAudio.h:336
AkRoomID FrontRoom
Definition: AkSpatialAudio.h:393
AKSOUNDENGINE_API AKRESULT SetPortal(AkPortalID in_PortalID, const AkPortalParams &in_Params)
AkRoomID BackRoom
Definition: AkSpatialAudio.h:400
AKSOUNDENGINE_API AkUInt32 GetIDFromString(const char *in_pszString)
AKSOUNDENGINE_API AKRESULT SetRoom(AkRoomID in_RoomID, const AkRoomParams &in_Params)

Was this page helpful?

Need Support?

Questions? Problems? Need more info? Contact us, and we can help!

Visit our Support page

Tell us about your project. We're here to help.

Register your project and we'll help you get started with no strings attached!

Get started with Wwise