從虛幻 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