从虚幻 4 中采集 360 度立体电影

从虚幻 4 中采集 360 度立体电影

Gavin Costello, Lead Programmer, Ninja Theory Ltd 在 May 10, 2016 | 功能学习设计

• Share on Facebook 
• Share on Twitter 
• Share on Google+ 
• Share on LinkedIn

导言

早在放出《地狱之刃（Hellblade）》的“垂直切片”构建版供评测以前，咱们就一直在努力采集 360 度视频，而咱们完整采集的第一个 360 度立体视频被用在了咱们的第一个实机演示影片中。

 

 

 

最初咱们编写了本身内部的平面 360 度采集系统，它以立方体采集为基础，投影到球体上，再通过变形处理获得最终影像。

虽然这个系统效果尚可，但因为它的平面性质，影像中的一切都给人“巨大”的感受，并且它不能体现出视频主体的任何亲切感。哪怕影像呈如今您周围，您也会感受本身是遥远的旁观者，没有身临其境的感受。

（我认为平面镜头之因此会丧失尺度感，让人感受过于巨大，是由于人脑有一种从您自身角度出发进行评估的潜意识。它能够判断出您没有立体的会聚感，没有头部移动引发的视差，所以看到的那个物体确定很是遥远。而后它会把这个信息与那个物体占据了很大一部分视野的事实结合起来，从而让您感到那个物体很是很是大，又很是很是遥远。）

您能够本身试试，采集一帧立体影像，再采集一帧平面影像。来回切换这两帧影像，您会注意到本身不只丧失了深度感，还丧失了全部尺度感，看到的物体彷佛愈来愈大。

大概就在这个时候，咱们开始研究是否能生成具备相应偏移的左眼和右眼影像，从而获得真正的立体影像。在这个过程当中咱们发现了由 Kite and Lightning 开发人员提供的立体 360 度采集插件。

当时它刚刚出如今 GitHub 上，还不是 UE4 分发版的一部分，可是现在它已经成为虚幻引擎 4 的附赠插件，我强烈建议您试一试。:)

这篇文章的余下部分将谈谈咱们忍者理论（Ninja Theory）公司用来采集 360 度立体电影的具体设置和工做流程，咱们刚刚公开发布供你们观看的视频就是这样采集的：

原来的非 360 度预告片：

 

 

360 度立体版本：

 

 

这篇文章假定读者使用的是 UE4 的最新版本（在本文写做时是 4.11.2），不过咱们从 4.9 版开始就一直在使用这个插件，所以大部分操做是能够直接应用的（您可能只须要对代码稍做修正，我在结尾的疑难解答部分会提到）。

启用“立体全景电影采集（Stereo Panoramic Movie Capture）”插件，并执行一次快速测试采集：

首先，咱们须要确保启用了相应的插件。

在编辑器打开的状况下，转到“编辑（Edit）-> 插件（Plugins）”，而后选择左边的“电影采集（Movie Capture）”设置，确保对“立体全景电影采集（Stereo Panoramic Movie Capture）”选择“启用（Enabled）”。

而后须要关闭并从新启动编辑器。

注：您可能还须要再次快速“构建”，具体取决于您是否在分支中得到了本地更改，由于工具附带的插件 dll 可能已经“陈旧”。

当编辑器从新启动后，再次转到“编辑器（Editor）-> 插件（Plugins）-> 电影采集（Movie Capture）”，并再次检查其是否已启用。

这个插件有多个能够经过控制台命令切换的设置，可是在更改设置前，应该执行一次测试采集，以确保默认设置的工做效果符合预期。

打开命令控制台，用 SP.OutputDir 设置您但愿用于转储输出影像的合适文件夹，例如

SP.OutputDir F:/StereoCaptureFrames

注：每次加载编辑器或游戏时都必须进行此操做，由于此设置不会保留。

而后执行一次单帧采集，例如

SP.PanoramicScreenshot

此时系统可能会长时间无响应（估计有一分钟左右），而后将会有两帧影像转储到您在先前用 SP.OutputDir 指定的目录中（好吧，实际上是在该目录中的一个日期和时间目录下）；一个是左眼影像，另外一个是右眼影像。

快速查看一下它们，确保一切都符合预期。若是此时出现色带之类的失真，不用太担忧，由于咱们会在稍后设法解决（还有一些效果可能有问题，例如光轴不起做用，还有屏幕空间效果——咱们也会在更后面的部分解决）。

使左右眼影像自动组合成单一影像的代码更改

在咱们的内部工做流程中，咱们但愿每“帧”只转储一个完整的上/下分格影像。这能够大大方便咱们“把全部帧构建成一段电影”，而没必要在这个过程当中手动组合左右眼影像。

若是这个方法对您也适用，并且您愿意更改代码，下面就是一小段用于在输出影像前组合左右眼影像的代码（未做专门优化）。

1. 打开 SceneCapturer.cpp

2. 定义一个控制变量，以便在已组合和未组合的影像之间切换。咱们内部始终但愿输出已组合的影像，所以咱们只设置了一个全局常量布尔值。

- const bool CombineAtlasesOnOutput = true;

3. 在 USceneCapturer::SaveAtlas 的底部有条件地禁用当前对应每一个眼睛的输出（CombineAtlasesOnOutput 检查是惟一的新代码）。

IImageWrapperPtr ImageWrapper = ImageWrapperModule.CreateImageWrapper( EImageFormat::PNG );

if (!CombineAtlasesOnOutput) //*NEW* - Don't do this here if we're going to combine them.

{

ImageWrapper->SetRaw(SphericalAtlas.GetData(), SphericalAtlas.GetAllocatedSize(), SphericalAtlasWidth, SphericalAtlasHeight, ERGBFormat::BGRA, 8);

const TArray& PNGData = ImageWrapper->GetCompressed(100);

FFileHelper::SaveArrayToFile(PNGData, *AtlasName);

}

请注意，这也会揭示出下面“GenerateDebugImages->GetInt() != 0”分支中的一个代码错误，它输出的是 PNGData，可是它应该输出 PNGDataUnrpojected…因此也要修正该错误。

4. 而后添加一些用来组合双眼影像并输出单一影像的新代码；在 USceneCapturer::Tick 中，找到此行：

“TArraySphericalLeftEyeAtlas = SaveAtlas( TEXT( "Left" ), UnprojectedLeftEyeAtlas );”

插入下列代码（我加上了先后的一些代码，以便您肯定插入位置是否正确）

TArraySphericalLeftEyeAtlas = SaveAtlas( TEXT( "Left" ), UnprojectedLeftEyeAtlas );

TArraySphericalRightEyeAtlas = SaveAtlas(TEXT("Right"), UnprojectedRightEyeAtlas);

//*NEW* - Begin

if (CombineAtlasesOnOutput)

{

TArrayCombinedAtlas;

CombinedAtlas.Append(SphericalLeftEyeAtlas);

CombinedAtlas.Append(SphericalRightEyeAtlas);

IImageWrapperPtr ImageWrapper = ImageWrapperModule.CreateImageWrapper(EImageFormat::JPEG);

ImageWrapper->SetRaw(CombinedAtlas.GetData(), CombinedAtlas.GetAllocatedSize(), SphericalAtlasWidth, SphericalAtlasHeight * 2, ERGBFormat::BGRA, 8);

const TArray& PNGData = ImageWrapper->GetCompressed(100);

// Generate name

FString FrameString = FString::Printf(TEXT("Frame_%05d.jpg"), CurrentFrameCount);

FString AtlasName = OutputDir / Timestamp / FrameString;

FFileHelper::SaveArrayToFile(PNGData, *AtlasName);

ImageWrapper.Reset();

}

//*NEW* - END

// Dump out how long the process took

FDateTime EndTime = FDateTime::UtcNow();

FTimespan Duration = EndTime - StartTime;

UE_LOG( LogStereoPanorama, Log, TEXT( "Duration:%g seconds for frame %d" ), Duration.GetTotalSeconds(), CurrentFrameCount );

StartTime = EndTime;

这就好了！（也许 Epic 或 K&L 会把这些代码作到插件里。）

注：咱们还在上面把输出格式设置成了 JPEG，这是由于在每秒 60 帧的状况下输出 PNG 格式的 4096x4096 帧将会占用许多硬盘空间！

如前文所述，设置 SP.OuputDir，而后调用 SP.PanoramicScreenshot，您应该会看到像这样将左右眼影像组合而成的上下分格影像：

若是您有立体 360 度影像查看器，直接播放该影像，您就会有身临其境的感受。真是个激动人心的开头！

关于采集过程的超简要说明

下面很是简要地说明一下在您进行采集时发生的事情，主要目的是介绍下面的设置所发挥的做用……若是您须要，能够在网上查到更详细的信息，不过您没必要了解更多信息就能使用插件。

您须要了解的一个要点是：若是要以正确方式从 2D 左/右眼影像中采集立体信息，对于任何给定的方向，场景中真正显示正确立体视觉的只有屏幕中央附近的一小部分（也就是“两眼之间”的那一部分），至少对于采集来讲是这样。采集器在后台渲染整个标准游戏视图（只不过使用了提供的另外一个 FOV），而后丢弃其中的大部分。

在现实中，这一小块区域的宽度取决于 HorizontalAngularIncrement 和 CaptureHorizontalFOV，可是对于“高质量”采集设置，这个宽度是很是小的！

所以，当插件渲染 360 度视图时，它实际上会进行屡次不一样的采集，每次将摄像机转动一点角度，仅提取中央的一小部分供稍后使用。能够这样理解：采集的样本越多，对于任何一个给定点的立体视觉信息就越精确。

有两个变量控制此过程：

- SP.HorizontalAngularIncrement 控制各次采集之间水平转动多大角度。

- SP.VerticalAngularIncrement 控制每次完成 360 度水平一周旋转后垂直旋转多大角度（从一极到另外一极）。

在这两个变量中，尤为须要把 HorizontalAngularIncrement 调整为很低的值。比方说，若是您将它设置为 10 度（完成一次 360 度旋转总共须要进行 36 次渲染），您就会发现影像的深度消失了，看到的是一个个“色带”……不过这里不是字面意义上的色带，而是感知的深度信息呈带状。

配置插件设置以得到最佳质量

要得到更优质的采集结果，除了 SP.OutputDir，您还须要配置该插件的另几个 CVar 控制的设置；这些设置控制的对象包括您要渲染多少水平视图和垂直视图来生成帧（后者生成看上去更准确的立体视觉），您但愿目标输出有多大，您但愿各个视图有多大（这和您的输出分辨率无关），等等。

我会在这里说明咱们使用的具体设置，不过在 StereoPanoramaManager.cpp 顶部也能够找到完整的列表。

咱们使用的设置是：

SP.OutputDir F:/StereoCaptureFrames

SP.HorizontalAngularIncrement 2

SP.VerticalAngularIncrement 30

SP.CaptureHorizontalFOV 30

SP.ConcurrentCaptures 6

SP.CaptureSlicePixelWidth 720

SP.ShouldOverrideInitialYaw 0

对于 4096x4096 采集（每一个眼睛 4096*2048）

SP.StepCaptureWidth 4096

或者对于 6144x6144 采集

SP.StepCaptureWidth 6144

您能够看到，咱们使用的 HorizontalAngularIncrement 值很是小，所以每完成一次 360 度旋转须要分别渲染场景 180 次（每一个眼睛）……取更小的值质量会更好，不过渲染每一帧的时间也会加长，咱们发现 2 是“甜点”，也就是说取更低的值所带来的质量改进是肉眼察觉不到的。

咱们给 VerticalAngularIncrement 设置了一个大得多的值。咱们发现垂直方向上的立体视觉信息的差别没有那么大，至少对咱们要采集的场景来讲是这样（其中包括了人物模型，也就是说并不是都是平板墙！），30 是咱们的甜点。

这里有必要提醒一下，每帧要渲染的视图总数就是由这两个参数决定的。

事实上，您作的事就是朝头顶上方看，采集一个场景，转动 HorizontalAngularIncrement 度，再次采集，再转 HorizontalAngularIncrement……如此反复，直到转满 360 度。而后向下转 VerticalAngularIncrement，把前面的整个过程重复一遍，而后重复以上过程，直到您看着脚底下为止。

因此实际上，要生成一个立体 360 度采集帧，您须要进行的总渲染次数是：

(360 / HorizontalAngularIncrement) * (180 / VerticalAngularIncrement) * 2（由于它是对应每只眼睛的）

因此这意味着按照以上设置，仅仅为了采集一个立体 360 度帧，您就须要渲染 2520 帧！再说得明白一点，若是您为 60hz 的游戏渲染 2520 帧，一般会生成 42 秒的输出，而上面这种方法生成的输出仅仅是前者的 1/60（假如进行采集是为了生成 60fps 的电影的话）。

SP.ConcurrentCaptures 是上面另外一个须要考虑的重要设置，主要是由于若是把它设置得过高（它的默认值就是 30！），就会遇到 VRAM OOM 问题。

这个 CVar 控制的是同时建立和渲染多少采集元件，每一个元件都须要与之关联的渲染目标内存，所以会严重消耗 GPU 存储资源。我前面说了“同时”，但实际上 GPU 一次只会处理一个元件，所以在某个时刻，您会遇到在 CPU 上处理渲染帧和用 GPU 帧运行之间的平衡，而这极可能在远低于 30 的状况下出现。咱们发现“6”是咱们的甜点，若是将它进一步增大（最高可达 30），基本上只会让一帧的渲染时间缩短几秒，考虑到耗用的 VRAM 和长达几天的采集过程当中死机（因为 OOM）的可能性，这并不合算！

最后，SP.CaptureSlicePixelWidth 也是须要在这里谈一下的重要设置。咱们在很长一段时间里都让它保留默认值，一般是 2048 左右。这个值表示您渲染的“每一个视图”的大小（每帧须要渲染 2520 个视图！），所以下降这个值会对总渲染时间形成产生重大影响。它实际上与最终的输出影像无关，您应该根据本身须要作多少垂直“步骤”（180/VerticalAngularIncrement） 以及要为最终影像进行多少多重取样来肯定它的大小。

实际上，假设缓冲区是 2048，而您要作 6 个垂直步骤，那么您实际渲染的是一个高 12288 像素的影像。假设最终输出的是每一个眼睛 4096x2048 的影像，那么您能够看到，实际上一开始的高度不须要达到那么多像素；有 6xFSAA 就够了！咱们在这里实际上只考虑垂直分辨率，您可能还记得上文的影像，咱们不会使用全宽影像，只采集中间的一小部分，所以宽度在这里不过重要（只要宽度足以让咱们从中央提取足够像素便可）。

相比之下，若是将值设置为 720，而后要渲染实际高度大约 4320 的影像而且将其下降取样至 2048，仍然至关于 2xFSAA（咱们发现这确定已经够好了），那么您对于这 2520 个视图的渲染时间就大约是 40 秒，而原来是 3 分钟左右（并非严格的线性关系，但效果仍是很好的）。

在蓝图中设定全部设置

好，上文已经说过了，这些设置在每次引擎/编辑器运行之后都不会保存。它们都是临时的，每次启动都要从新设置，这真的很麻烦。

所以咱们内部的工做方式是写一条控制台命令，它能够替咱们设置好全部这些参数，每次采集前调用它就好了。

或者，您也能够把控制台命令输入蓝图中；很抱歉，下图用了表格式的布局，咱们只是但愿把内容塞进一幅可读的图像中！

有了这样的蓝图，您就能够执行“ce NTCaptureStereo”，它会在开始采集前处理全部参数的设置。这不只是更方便的工做方式，也会大大下降出错几率，若是要开始持续大约两天的采集，您确定不但愿本身不当心忘记设置某个参数！！！

采集一段电影

好，咱们已经讲过了全部重要的设置，还介绍了一个好方法：使用一条控制台命令从蓝图设置并触发采集。

在采集电影时，首先必定要记住的最重要的事情是：要按固定的时间步长运行。

采集一帧须要 40 秒以上，因此您要告诉引擎，必须按固定的时间步长使时间流逝，除非您但愿 80 秒的电影只有 2 个输出帧。

多亏了虚幻引擎，这个操做很简单。您只须要提供如下命令行

-usefixedtimestep -fps=

例如，假设您将帧率设置为 60，那么就会在每生成一个完整的帧之后按 16 毫秒的时间步长更新，所以每过一秒钟时间，您就会采集 60 帧。若是您只打算生成 30hz 的电影，那么理论上能够将这个参数设置为 30，不过咱们一直是按 60 来采集的，这样咱们就能够选择从采集到的帧来生成 60hz 或 30hz 电影。

另外，此时使用 -notexturestreaming 关闭纹理流也是个好主意；若是您花了一天采集电影，而后发现地板纹理全都模糊了，那您确定会很恼火 ;)

举一个完整的示例：咱们在内部要进行采集时，都会在启动游戏/编辑器时传递如下命令行

-usefixedtimestep -fps=60 -notexturestreaming

那么，实际进行电影采集时要怎么操做呢？

我前面提到过 SP.PanoramicScreenshot，不过若是您仔细查看上面的蓝图截屏就会发现还有一个办法能够直接采集一些帧，那就是：

SP.PanoramicMovie

这里的帧数确实就是“从您发出命令时起引擎已运行其更新循环的次数“，好比，若是您以 fps=60 运行，而且将 startime 设置为 120，将 endtime 设置为 240，那么在命令执行后它将等待 2 秒（120 帧），而后采集至关于 2 秒的帧（也就是 120 帧），而您能够再将它们编码为 2 秒长度的 60hz 视频……以此类推。

咱们倾向于就从这里的 matinee 采集（毕竟按照固定的时间步长和 40 秒来采集每一个帧并非真正的“实机运行”帧率）,所以咱们在触发 SP.PanoramicMovie 命令的同时老是会启动 matinee，而后根据咱们但愿开始和中止采集的 matinee 中有多少秒就能够轻松得出起始帧和结束帧（只要乘以 60 就能获得答案）。

在采集到帧以后

当采集完成后，在您的 your SP.OutputDir// 文件夹中会有一系列标注为 Frame_00000 -> Frame_EndFrame 的帧和一个 Frames.txt 文件。（看到这些您就知道采集完成了！）

若是您使用了上文的自定义代码，这些帧会合并为上下分格的影像，随时能够编码。

而后您可使用不少方法将它转成电影，不过咱们倾向于只使用 ffmpeg 把这些帧编码为 h264 60hz 视频。注：ffmpeg 在网上能够免费下载。

例如，下面的命令行把指定目录中的全部帧编码为一段名为 MyMovie.mp4 的 h264 60hz 电影：

“ffmpeg.exe -framerate 60 -i F:/StereoCaptureFrames/2016.04.26-13.04.34/Frame_%%5d.jpg -c:v libx264 -profile:v high -level 4.2 -r 60 -pix_fmt yuv420p -crf 18 -preset slower MyMovie.mp4”

我不想在这里介绍 ffmpeg 的细节，网上有许多文档，我只知道大多数人会但愿使用别的编辑软件来编码。

这时输出的电影基本上就可使用了，不过您还须要混入音频才能将它发布出去。:)

这就好了！

恭喜……假如个人文章写得还不坏，但愿您如今已经知道了如何设置并采集能够在 GearVR 上播放或上传到 YouTube 或 Facebook 的 360 度全立体影像。

关于上传到 YouTube 的说明：必须附加元数据并按合适的分辨率/长宽比输出，例如“4K/UHD/(3840x2160, 16:9)”，在这个例子中不是 4096x4096。不然它在流式播放时会显得很是很是模糊。源帧能够是 4096x4096，可是在编码影片时（无论您用的是什么程序）要记住输出“标准”UHD 分辨率和 16:9 长宽比，而不是 4096x4096 1:1 长宽比影像（虽然这能够用在 GearVR/Oculus360 播放中）。

其余问题和说明

还有几个问题我以为能够在这里谈一谈。其中有些是一直都有的，有些已经在 4.11 中修正了，但在较早版本的引擎中有。

1. 不是全部效果都有用

这条很重要，我但愿读者能够综合上面的信息来理解。您的场景其实是被分红一块块“方砖”来采集的（使用了放大的 FOV），您要执行一系列水平步骤，而后在一系列垂直步骤中重复全部水平步骤。所以，应该应用于整个“场景”的屏幕空间效果（例如晕映）不会起做用，应该关闭。

并且这意味着光轴也不会起做用。您可能会获得一系列有轴源在屏幕上的“瓷砖”，而在下一个瓷砖上由于屏幕上没有轴源，因此就没有光轴。这会使最终的影像中出现开启光轴和关闭光轴的部分，而不会达到您须要的效果。所以很遗憾，光轴也不能使用（虽然这是很精彩的效果）。

若是您不明白为何咱们的电影中光轴效果很正常，那是由于咱们有一个自定义的全局空间参与媒体解决方案，使全局空间效果都能起做用。:)

一样的，若是您使用了屏幕空间扭曲，它也不会起做用。由于您在每一个点上只截取屏幕中央的部分，因此只有屏幕中央会出现扭曲，周围不会。

请注意，全局空间扭曲仍然有效，因此在粒子之类对象上的扭曲效果仍是会很棒。:)

通常而言，屏幕空间效果不会起做用，因此在考虑内容时要注意这一点。

2. 并非全部东西都遵循固定时间步长

在制做垂直切片场景的过程当中，这个问题很早就困扰咱们了。咱们在游戏中放了一段表现一张脸的过场剧情电影，可是不知为何咱们只能获得大约 2 帧的视频，而后就没有了。这是由于系统是按“正常”速率处理视频的，而不是按咱们所须要的每次渲染 16ms 的固定速率，也就是说咱们每采集一帧就会跳过大约 40 秒的视频！

与此相似，在 GPU 上每帧使用真实 Δ 计算（而不是“游戏时间”）的项目也不会遵循这个设置。咱们过去遇到过一些有趣的例子，好比使用普通材质的火焰看上去很不错，而火焰中的 GPU 粒子“燃屑”却以难以想象的速度乱飞，这是由于它们的更新速度没有相应地绑定。可使用粒子系统中的一些设置来设定固定的更新时间，以绕过这个问题。

3. 默认设置下（出厂设置）采集不会拾取后期处理体积！

咱们解决这个问题的办法是让采集视图使用来自播放器的后处理设置。

举一个简单的例子，若是您转到 USceneCapturer::InitCaptureComponent 而后添加下列代码（在调用 RegisterComponentWithWorld 前），它就会使用播放器的后处理设置。

//*NEW* Set up post settings based on the player camera manager

if (GetWorld())

{

APlayerController* PlayerController = GetWorld()->GetFirstPlayerController();

if (PlayerController && PlayerController->PlayerCameraManager)

{

CaptureComponent->PostProcessSettings = PlayerController->PlayerCameraManager->CameraCache.POV.PostProcessSettings;

CaptureComponent->PostProcessBlendWeight = PlayerController->PlayerCameraManager->CameraCache.POV.PostProcessBlendWeight;

}

}

// Disable effects that we don't want for capture

CaptureComponent->PostProcessSettings.bOverride_GrainIntensity = true;

CaptureComponent->PostProcessSettings.GrainIntensity = 0.0f;

CaptureComponent->PostProcessSettings.bOverride_MotionBlurAmount = true;

CaptureComponent->PostProcessSettings.MotionBlurAmount = 0.0f;

CaptureComponent->PostProcessSettings.bOverride_ScreenSpaceReflectionIntensity = true;

CaptureComponent->PostProcessSettings.ScreenSpaceReflectionIntensity = 0.0f;

CaptureComponent->PostProcessSettings.bOverride_VignetteIntensity = true;

CaptureComponent->PostProcessSettings.VignetteIntensity = 0.0f;

//*NEW*

注：为了让某些后处理效果（例如材质效果）起做用，您可能须要强制设定采集元件具备 ViewState。

固然，初始化只会进行一次，所以若是您要在各类体积之类中穿行，那就须要提取这段代码，而后每帧调用一次，或者改写 FScene::CreateRenderer 以复制播放器的后处理（每帧、每一个采集视图都进行）。

4. 个人输出文件变绿了！帮帮我！！

咱们在使用较早版本的引擎时遇到过这个问题。这是由于您有多个采集元件（别忘了 SP.ConcurrentCaptures），可是它们的名称都相同，所以系统只是反复使用其中的第一个，而后却依次读取它们。由于绿色是“透明”的颜色，因此您看到的就是从您没有渲染的帧中读取的结果。

解决这个问题的办法就是在 USceneCapturer::InitCaptureComponent 中给它们各起惟一的名称

在 4.11 中这是经过 MakeUniqueObjectName 调用完成的，可是若是您使用的是较早的版本，能够用您喜欢的其余任何办法操做（咱们是设了一个静态索引，让它经过增量方式生成惟一的名称）。

5. 阴影只出如今一个眼睛的影像中！帮帮我！！

好吧，咱们也遇到了这个问题，它在 4.11 中彷佛已经被修正了。这个问题是立体渲染路径的优化形成的，这个优化让您只生成一次阴影缓冲区，而后将这些缓冲区用于双眼的影像。

目前咱们的解决办法就是强制它为每一个眼睛从新生成阴影。

也是在 USceneCapturer::InitCaptureComponent 中，只要注释掉设置 CaptureComponent -> CaptureStereoPass 的那一行，就能解决这个问题。

这意味着您要多作一些阴影深度渲染，不过渲染原本就已经很慢了，您也许不会注意到它的影响。

6. 场景跟我预计的相比转了 180 度！帮帮我！！

我认为这个问题也已经在 4.11 中修正了，不过咱们也遇到过。咱们的解决办法就是手动加 180 度。在 USceneCapturer::Tick 中，找到这一行：

“Rotation.Yaw = (bOverrideInitialYaw) ?ForcedInitialYaw :Rotation.Yaw;”

把它改成：

“Rotation.Yaw = (bOverrideInitialYaw) ?ForcedInitialYaw :Rotation.Yaw + 180.0f;”

7. 跨多台机器分散采集

这绝对是缩短渲染整段过场剧情的最佳方法。

可是请记住，并非全部效果都是肯定性的，例如粒子可能有一些生成随机起始位置的节点，使粒子显得多样。若是您用两台机器采集一个场景，那么当您从一组帧切换到另外一组帧时，可能会看到画面突变，由于这些元素不是在同一个位置。

能够在粒子系统中“播种”，使他们每次运行时都生成相同的粒子，不过您须要很是仔细地考虑到每一种状况，不然您可能作了很长时间的采集，仍然发现某个效果出现突变。

咱们在传统上不是这样作的，而是找到场景中的“天然切割点”，也就是摄像机镜头跳转的地方，淡入淡出的地方，或者观看者不会注意到内容突变的任何地方，而后把在这些地方切割的影片放在不一样机器上采集。

不过要注意，若是要采用这个办法，必定要在切割片断的头尾额外采集一点“缓冲”部分。若是您不当心过早地中止采集某切割片断，或者在 matinee 中采集下一切割片断时开始得过晚，那么您可能须要从新采集整个切割片断，这会耗费大量时间……特地将切割片断提前/延后一秒左右，能够保证获得您须要的全部帧。

有一点很好，那就是若是 matinee 在一个大的 matinee 中，那么帧编号会与之相应。若是在不一样的帧开始和中止，不一样切割片断的帧的名称 (Frame_StartFrame->Frame_EndFrame) 也会不一样，您能够把它们放到同一个文件夹中，没必要另外将它们组合成影片。

8. 弹出了一些窗口，把个人编辑器/采集拖延一整晚，恨啊！

在“编辑（Edit）-> 编辑器首选项（EditorPreferences）-> （常规）其余（(General)Miscellaneous）”下面有一个很方便的设置，叫作“在后台运行时减小对 CPU 的使用（Use Less CPU when in Background）”。

把它关了……（在采集的时候）。这样一来，若是您离开机器，让它整夜采集，当有人给您发送一条消息致使弹出窗口时，不会使编辑器暂停，延误您的采集。

9. 极点的深度不正确

很遗憾，这是这个技术的局限性之一。通常说来，当您直视上方时不会注意到这个问题，不过当您“站”在地上时，确定会在看地面时注意到。

咱们解决这个问题的办法是，经过消退遮蔽每一个帧中的底部行，因此看上去就好像您脚下有个黑圈同样。这也许不能让全部人满意，不过咱们以为这实际上可让人们不肯意看那里或体验不正确的深度，这仍是有好处的！

10. 单眼/双眼影像中有些几何体消失了

咱们解决这个问题的办法是禁用遮蔽查询。我不记得这个问题具体是怎么回事，不过它和引擎使用上一帧的遮蔽结果的方式和更新“上一帧遮蔽”信息前进行了多少渲染有关，是帧更新间隔中的并发采集数形成的。

在采集前把 r.AllowOcclusionQueries 设置为 0 就能够解决这个问题。

好，如今真的说完了！

我知道这篇博客很长，不过我但愿不管您是刚开始采集，仍是采集了一段时间但遇到了上面提到的一些问题，都能找到有用的信息。

祝您进行本身的采集时好运。获得大量优质的立体 360 度镜头确定是好事！！:)

~Gav

一些供试看的《地狱之刃》帧 (6K)

单击每一个图像可访问 6K 版本。

 

再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！但愿你也加入到咱们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow