|
Wwise SDK 2024.1.1
|
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 through open Portals simulate diffraction. Additionally, rooms model sound transmission through walls. Diffraction and Transmission Loss values are applied to the emitter game object. In the Wwise Authoring application, you can choose whether you want these values to attenuate the sound using the attenuation curves or using built-in game parameters instead. If a sound doesn't have an attenuation instance (either custom or ShareSet), the project diffraction and transmission curves are used to attenuate the sound.
If you are using built-in game parameters to drive RTPCs, any obstruction and occlusion values set on a Portal do not affect the RTPC values. This behavior is intentional and occurs because RTPCs only provide one value per game object, but a single game object can have multiple paths through different Portals, each with different obstruction and occlusion values.
If you want to implement your own solution for obstruction (for example, one driven by game-side raycasting) in conjunction with diffraction set from Spatial Audio, the game can use the AK::SoundEngine::SetObjectObstructionAndOcclusion sound engine API. For the occlusion of portal openings, the game can 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.
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.
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 already uses diffraction and transmission. 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.
Questions? Problems? Need more info? Contact us, and we can help!
Visit our Support pageRegister your project and we'll help you get started with no strings attached!
Get started with Wwise