前言

多普勒效应是一种物理现象，主要内容为物体辐射的波长因为波源和观测者的相对运动而产生变化，这种现象会出现在所有波的传播过程中，声波也不例外。随着游戏音频行业的发展，许多游戏引擎也都提供了自己的多普勒效应解决方案，比如Unity和虚幻系列引擎都加入了使音频产生多普勒效果的功能。但是这些功能都只适用于游戏引擎内部，无法和Wwise联动。如果我们的游戏音频部分使用Wwise进行开发，将无法享受这些效果。而Wwise内部目前还没有一套比较完善的多普勒效应解决方案，官方教程中也只写了可以使用相对速度值发送rtpc来解决，比较笼统。

笔者最近就使用Wwise制作多普勒效应的方法进行了一些研究，并使用虚幻4和Wwise相结合制作了demo工程来验证效果，将Wwise和虚幻引擎制作多普勒效应的效果进行了对比，现在将研究结果和大家分享。

一、Wwise实现多普勒效应效果展示及实现方案简述

首先我们来简单看一下有无多普勒效应、虚幻引擎制作多普勒效应和Wwise引擎制作多普勒效应的效果对比：

（国内观赏视频通道）

可以看到，有无多普勒效应对于声音的表现力影响非常大，无多普勒的情况下基本就完全感觉不到车辆的速度感。而通过Wwise引擎调制声音和虚幻引擎自带的多普勒节点所产生的多普勒效应的效果，在音色上几乎没有任何差距。唯一的差距是因为我修改了虚幻引擎发声时聆听者的位置，将位置从摄像机切换到了玩家角色身上，导致虚幻发声时的声像变的很窄。这样做是为了保持两个引擎在计算玩家位置的时候是统一的，且不会因为镜头的转动影响多普勒效应的产生。

那么这种效果是如何做到的呢？我们来分别看一下两个引擎对于车声的设置：

（图1.1 虚幻引擎内汽车声soundcue设置截图）

虚幻引擎内部很简单，只需要给声音加上多普勒节点，该声音就会产生多普勒效应。

（图1.2 Wwise引擎内多普勒效应设置）

Wwise引擎内的设置也并不复杂，只需要设置一个这样的RTPC，受该RTPC影响的所有声音也可以获得和虚幻引擎节点一模一样的多普勒效应效果。但是，这个曲线看起来略显神奇，接下来我们将详细说一下这条曲线是如何得到的，以及它的工作原理。

二、以RTPC驱动多普勒效应的工作原理

想要了解多普勒曲线的设置方法，我们就需要先理解多普勒效应的物理原理。此处为了避免产生歧义，和减少变量，我们先对相关情景进行限定，限定我们所研究的波为声波，其速度为340m/s，其传播介质为空气，且空气为绝对静止。所有发声体和聆听者相对于空气的移动速度均不超过音速（光波和洛伦兹变换对多普勒效应的影响不在本文讨论之列）。在这样的条件下，发声体和聆听者的运动所产生的多普勒效应的公式如下：

其中f’为聆听者所听到的声音的频率，f为发声源所发出的声音的频率，v为声速，v₀为聆听者相对于空气的移动速度，v₈为发声体相对于空气的移动速度。

通过观察该公式我们可以发现，发声体静止聆听者移动，和发声体移动聆听者静止。这两种情况产生多普勒效应的幅度是不一样的，而且区别很大。我们分别假设发声体静止和聆听者静止两种情况，分别将v₀=0和v₈=0两种情况带入多普勒的运算公式得到两个函数，然后画出这两个函数的曲线：

（图2.1 当v₈=0时v₀和f’函数关系的大致图像）

（图2.2 当v₀=0时v₈和f’函数关系的大致图像）

同时我们也可以实际听一下两种情况的多普勒效果：

（国内观赏视频通道）

可见这两种情况差别非常之大。忽略其中一个或者寻找两者之间的中间取值都不太行得通。我们必须同时计算这两个变量才可以获得拟真的多普勒效应，不过同时使用两个RTPC不太方便日后的工程维护，所以我们这里可以取个巧，不使用单个速度值作为变量，而是将f’/f的值作为RTPC变量，这样我们就只需要Wwise里设置一条曲线就可以了，维护和修改起来也更加方便。f’/f的值是产生多普勒效应后的声波频率和发声体发出的声波的基础频率的比值。我们知道音高和频率的关系是：频率每升高一倍，音高升高一个八度。用一个最简化的函数曲线来表示，就是y=2^x。但是这个曲线我们没有办法直接使用在Wwise里，因为Wwise里面只有音高可以作为y轴。所以我们需要交换一下y和x的位置，得到一个新的函数曲线x=log₂y。在已知音速是340m/s和Wwise中一个八度等于等于1200 Pitch值的情况下，我们就可以得到之前用来控制音高变化的曲线了，就是之前这个以2为底的对数函数曲线。

（图2.3 f’/f和音高变化之间的对数函数曲线）

所有的音频设计师小伙伴们，看到这里就基本掌握了使用Wwise制作多普勒效应的方法，接下来只需要给程序哥哥们提一下需求：“我需要计算玩家和发声体之间实时的相对速度，并将这两个相对速度值带入多普勒效应的计算公式计算出声音的频率变化倍率，然后将这个倍率值作为一个RTPC发送给Wwise。”

然后我们就得到了可以随意互动的多普勒效应效果。

（国内观赏视频通道）

当然，这是在我们有一位专业程序小哥哥帮忙的情况下。。。

如果我们暂时得不到程序小哥哥的帮忙，或者跟笔者一样想要自己搭建一个demo场景随意折腾验证功能，那该怎么办呢？

接下来我们来讨论下如何设置RTPC吧。

三、如何从游戏引擎获取我们需要的RTPC变量

先来梳理一下取值运算的逻辑和流程，大概是这样的：

（图3.1 RTPC获取流程图示）

由于笔者自己并没有多少C++基础，这里就无法展示代码了，只能使用虚幻引擎的蓝图功能来简单展示数据的获取流程和原理。另外，笔者制作的蓝图只为实现基础效果，且展示得到所需参数的运算过程，其程序逻辑并不一定严谨，请大家酌情参考。根据我们之前梳理的运算流程，我们大概可以得到这样的蓝图：

（图3.2 获取RTPC的蓝图架构图示）

不过这么做会遇到一个小问题。虚幻中获得组件速度的节点只能读取有速度值设定的组件的速度。比如我们虚幻4第三人称游戏demo自带的小白人组件。

（图3.3 虚幻4第三人称游戏demo玩家角色的速度设置界面截图）

如果不是这种拥有速度值设定的组件发生了移动，或者组件没有通过自身产生速度进行移动，比如我们使用场景变换等方式使一个场景物体发声了强制位移，这种强制移动所产生的速度，“获得组件速度”节点是无法读取的。遇到这种情况就需要我们自己计算物体的移动速度。可以采用如下蓝图：

（图3.4 通过场景坐标计算移动速度获取RTPC的蓝图架构）

也可以这样：

（图3.5 另一种通过场景坐标计算移动速度获取RTPC的蓝图架构）

这两种蓝图的原理差不多，都是通过每帧读取玩家和发声体所在位置，得出前一帧的速度向量，然后将向量投影到玩家和发声体之间连线上，得出相对速度，再带入公式计算获取RTPC值，区别是前一种蓝图通过计算每一帧发声体或聆听者自身位置坐标的变化得到相对速度，后一种蓝图是通过计算每一帧发声体或聆听者相对于对方的距离变化得到相对速度。通过这两种方式计算获得的值的差异几乎可以忽略不计。

四、调整系统负载和多普勒强度的方法

我们之前提到的所有的rtpc计算方式，对于系统平台的负载其实都非常的小，这个浮点运算的量级相比于图像领域来讲，真的是非常的小。但是也许会出现我们不需要这么高精度的多普勒效应的情况。这种情况下我们可以通过直接减小取值和运算频率减小系统负载。在我提供的蓝图中是使用事件tick驱动rtpc取值运算的，事件tick的取值频率为帧，如果我们不需要如此高的精度，那么只需要另外设定一个循环事件来驱动rtpc的取值即可，事件循环间隔可以随意制定，然后后续运算rtpc数值时不要再带入事件tick提供的Delta second，而是带入自己设定的循环间隔就可以。不过该取值范围不宜设置的太大，否则移动物体速度变化幅度较大时，会听出来声音的跳变。

关于调整多普勒强度的方法，我也已经在我个人的demo工程中制作了出来，但是没有展示在蓝图截图中，因为不想让基础功能的蓝图因为各种扩展功能而变得更加复杂。为了方便大家判断声音频率变化的幅度，我把UFO的引擎改成了螺旋桨。。。。

（国内观赏视频通道）

可以修改多普勒强度的方法有两个，一个是调整Wwise里边函数曲线的曲率，另外一个是调整rtpc的取值，让运算所得的速度值乘上一个你希望的系数即可随意控制多普勒效应的强度，但是请注意这个系数并不能直接代表多普勒效应的倍率，因为多普勒效应和速度之间的强度关系是不遵循正比例函数关系的，它遵循的是反比例函数关系。所以，这种设置方法和虚幻引擎设置多普勒效应强度的方法略有不同，至少他们的取值不是相同的。

这一节的最后，我们说一下声音可以个别修改多普勒强度的意义。虽然理论上现实生活中的多普勒效应的强度是固定的，游戏里也应该是固定的，除非有人可以改变声音传播介质的种类或者密度。我们无法排除未来可能会出现需要有类似表现的游戏。而且另外一个最大的好处是在相同的关卡内可以使用不同的距离单位值。假如我们有一款主角可以自由变大和变小的游戏，那么当主角变小后，其移动速度和他可以交互的道具的移动速度都非常的慢，那么游戏的互动过程中声音就会丧失一定的表现力，比起给变小后的玩家角色启用一套新的距离值，还是直接调整多普勒的强度更加容易一些。

五、可互动多普勒效应效果的适用范围

游戏引擎提供的可以产生互动效果的多普勒效应效果虽然很好，但是并不能适用于所有的场景，需要视游戏开发的需要和其他制作方法相结合。

可互动的多普勒效应通常使用在长时间存在且连续发声的亚音速发声体上，如汽车、直升机等各种载具；过山车之类的连续移动且发声的机械；玩家发射的rpg等会连续发声的亚音速抛射物等。

如果出现了接近音速，或者超音速移动的物体则不能简单的通过该方式解决。因为发声体达到音速以后，其发声规律会发声改变，且其发出的声音大部分将不再来自于自身的声音，而是来自于强烈的空气摩擦和声波叠加后产生的激波，这部分将涉及更加复杂的声学原理，已经超出多普勒效应的范畴。而聆听者超出声速以后，将无法再听到后方发出的声音，此时聆听者自身也成为了新的发声体。所以，只靠模拟多普勒效应是无法满足对于超音速物体发声的表现的。

对于游戏中遇到的超音速物体通常则会采用传统的素材制作模式，即声音素材本身就带有多普勒效应的效果，通过调节声音的触发时机来模仿真实的超音速物体发声。这种情况在游戏中最常见的就是子弹，只要判定子弹有从玩家身边经过，就会播放子弹呼啸的声音，因为子弹的速度很快，触发时机以及强度出现轻微的偏差，玩家一般也无法察觉。

还有固定时常和固定触发时机的声音，为了保证效果，此时也可以触发固定的素材来对应场景表现，而无需实机运算声音的特殊效果，比如1p玩家使用弓箭射出箭矢，通常会将箭矢呼啸飞出的效果直接做在弓箭发射的样本里，而不会单独计算箭矢的多普勒。根据具体问题具体分析，真假结合，方能获得更好的效果。

六、关于Wwise集成多普勒功能的建议

通过前文的论述我们可以知道，在游戏中实现多普勒效应只需要获得发声体和聆听者的相对速度换算成的rtpc值，然后利用该值控制音高变化就可以了。而换算rtpc值需要的数据只有两个，那就是可连续获取的发声体和聆听者的坐标信息。在游戏的运行过程中Wwise本体无时无刻不在监视和获取这些数据，因为Wwise本身就需要连续获取玩家和所有发声体的坐标信息来运算attenuation、spatial audio等信息。那么其实Wwise本身已经具备了直接进行多普勒运算的条件，就像运算每个发声体的distance参数一样，多普勒只是进行了一个比distance略微复杂一点点的浮点运算，也依然没有超出简单四则运算的范围。而对于不同工程的适配问题，完全可以靠调节多普勒强度的参数来解决。比如虚幻的基础单位是厘米，而其他游戏开发引擎可能会以米为单位，那么我们只需要把计算rtpc时带入的34000的音速取值换成340即可。或者有人使用虚幻开发游戏，但是他游戏内的距离单位和现实世界的并不是1；1的比例，那么它是多大比例，我们让换算时的速度值乘以多大比例就可以了。这基本上和上文调节多普勒强度的原理是差不多的。

所以，我个人一直比较疑惑Wwise引擎为何在完全具备前提条件的情况下，没有集成自己的多普勒运算功能，也许可能是有什么以我个人的水准还无法明白的技术原因，但是个人还是希望未来可以使用到直接集成在Wwise引擎内的多普勒效应工具。