UDN
Search public documentation:

MotionBlurSoftEdgeCH
English Translation
日本語訳
한국어

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

UE3主页 > 后期处理特效 >运动模糊柔和边缘后期处理特效功能
UE3 主页 > 过场动画制作人员 >运动模糊柔和边缘后期处理特效功能

运动模糊柔和边缘后期处理特效功能


SoftEdgeFan.jpg
SoftEdge(柔和边缘)使得运动模糊出现在运动物体的外面。

概述


推荐阅读: 运动模糊

使用SoftEdge可以进一步提高运动模糊的质量,使它变得更像影片那样的效果。在影片相机中,所谓的快门会保持打开一段时间来捕获更多的光。运动的对象沿着它们运动的方向呈现出模糊的外观。我们的运动模糊是基于通过平均多个贴图样本来模糊图片内容的后期处理特效的。获得像电影图片中看到的对象外部的模糊是可以实现的,但需要额外的消耗。我们这个问题的解决方案称为运动模糊SoftEdge功能。

知道这个功能的技术属性,使得您可以根据应用程序需要来调整运动模糊的外观及性能。

激活SoftEdge功能并设置正确的参数


SoftEdge功能可以在uber后期处理节点中的后期处理链中激活。

EditorSetting.jpg
0保持SoftEdgeg功能为禁用状态 (速度较快), 较大的值指定了半径 (1..10 是一个很好的范围)

当使用SoftEdge功能时,您可以增加最大速度,因为在启用这个功能时较强的运动模糊效果看上去会更好。

结果


MotionBlurSoftEdgeNumbers.jpg
左侧: 仅在对象中产生模糊
中间: 使用这个功能来使得对象的外面发生模糊
右侧: 使用较大的半径来完全地扩展这个效果。

使用这个功能会有一些性能消耗。半径越大性能消耗越多(在模糊过程中需要更多的样本)。如果多个不同的运动对象彼此离得太近,较大的值也容易使得这些对象的运动变形。正如中间图片所显示的,值太小运动对象会呈现出剪辑的外观。我们的经验证明即时小的值也能产生好的效果(比如 1)。对于比较强烈的运动,值可能需要设置为5或10。我们应该基于最大速度来计算值,但是我们更喜欢选择较小的值来控制性能和外观效果。

在运行时修改值


控制台命令 MotionBlurSoftEdge 允许覆盖在后期处理链中指定的强度。请使用没有参数的命令来获得帮助文本。这个命令最好在某些冻结状态中使用(比如,当使用 freezeframe 命令或游戏暂停时)。注意,MotionBlurSkinning(运动模糊植皮)不能被冻结,因为目前的实现在每一帧都会更新,如果某个对象被冻结,那么最后每个骨骼信息都会丢失。

console.jpg
控制台命令的帮助如下所示。

经过一些试验后,您应该可以找到一个较好的值,然后可以在后期处理链中使用这些设置。

实现


我们的运动模糊实现是在后期处理过程中完成的,在这里场景在运动的方向上产生模糊。运动方向由速度贴图(屏幕空间的2D运动向量是作为颜色编码的)和相机运动决定的。这个在MotionBlur(运动模糊)中已经解释了。图形硬件在聚集方法(正常的贴图映射)方法中比发散方法(分布数据到多个目标)中运行速度更快。对于运动模糊,我们需要知道当前像素从哪个邻接像素接收内容。

没有 SoftEdge功能,我们仅假设当前像素的运动和邻接像素是一样的。为了避免颜色渗透,我们丢弃没有运动方向或具有不同运动方向的像素。这个解决方案看上去很干净,但没有使对象边缘的外面产生模糊。

使用 SoftEdge功能,我们使用简单的高斯模糊来模糊中间的速度贴图。使得运动向量发生模糊会导致运动向量的长度丢失。为了弥补,我们也对另一个通道进行了模糊(0代表没有对象模糊,1代表有对象模糊)。我们可以通过这个通道的划分来弥补运动强度损耗。

以下图片显示了内部缓冲的样子(颜色是不同的,因为运动向量的编码是不同的)。

MotionBlurSoftBlurredVelocity.jpg
左侧: 速度贴图
中间: 模糊的速度贴图(小半径)
右侧: 模糊的速度贴图(大半径)

注意,模糊的图片的分辨率很低。在运动中这些细节的丢失是察觉不到的,并通过双线性过滤贴图进行了进一步的隐藏。

在后期处理过程中,我们使用模糊的速度向量来获得我们用于采样的对象方向。我们也在相机运动方向上进行采样并把结果结合起来。

性能


我们认为当前的实现还不是最终版本,但是它对于应用来说已经足够的快。对于强烈的运动,它的性能或许变得更糟糕,因为贴图缓存对这个数值的影响很大。我们正在想法优化它。