Wwise 空间音频方案

在UE-Wwise中，有两种原生的方式可以去更新声障声笼参数值：

1. 基于射线检测
2. 基于空间音频组件AkSpatialAudioVolume

首先介绍射线检测方案。如果ak激活了声障声笼参数，由两种处逻辑会触发参数更新。

1. 调用PostEvent进行音频播放时，会进行一次计算更新，

UpdateObstructionOcclusion接口中，会计算ak和listener的阻挡情况，当存在阻挡时，会基于阻挡物体的BoundingBox，继续打24根射线，检测阻挡物对ak和listener的阻挡程度。CalculateObstructionOcclusionValues接口的最后一个参数bAysnc为false，表示这些射线检测都是在主线程中进行的。

        2.Akcomponent的TickComponent接口会更新声障声笼参数。

 由TickComponent触发的CalculateObstructionOcclusionValues接口的参数bAsync为True，表明是在异步线程中进行射线检测。

射线方案的主要有两个问题：1）射线数量多，检测消耗大。2）BoundingBox并不能很好的反应阻挡物的形状（没法反应中间存在较多空洞，可以穿过声音），容易导致参数更新误差较大。

基于空间音频组件AkSpatialAudioVolume方案：由音频负责在场景中布置代表声学空间的room和portal等组件。每个Room有Room Id，当Ak和Listener位于不同的RoomId房间时，他们之间的声音传播会受到阻挡。Portal组件可以连接两个Room，让声音透过Portal进行传播。

 room id的更新逻辑位于akcomponent的UpdateGameObjectPosition接口中。

有三处调用UpdateGameObjectPosition接口的地方

• 组件初始化
• 对于Listener，在tick中更新
• 对于emitter，在transform被更新时（比如设置Position），进行更新

 计算Roomid的算法：依据优先级降序对Room进行遍历（Room在生成时，根据优先级，被插入一个有序单链表中），判断Ak所在位置是否在Room的BoundingBox中。

这个RoomId更新方案可能会存在性能风险。原因主要有两点

• 每次获取RoomId 都需要遍历链表，判断是否在Room的BoundingBox中。当空间音频场景复杂，room数量较多时，这个性能消耗会比较大。
• 当一帧中触发更新的Ak组件较多时，也可能会有较大性能风险，比如混战场景。

 一些可能的优化方法：

• 更细致的场景加载控制
• 限制每帧的更新上限
• 限制每个Ak的更新频率
• 缓存Room的BoundingBox信息
• 修改Room的存储方式（用八叉树替代单链表。。。）