如何評價Epic Games今日公布的虛幻引擎5？
（摘自官網）就在不久之前，我們剛剛揭開了虛幻引擎5的神秘面紗。我們對於次世代的願景之一就是讓實時渲染細節能夠媲美電影CG和真實世界，並通過高效的工具和內容庫讓不同規模的開發團隊都能實現這一目標。
演示視頻請見（翻譯來自 @游研社 ）：
更多背景請見：
http://unrealengine.com/blog/a-first-look-at-unreal-engine-5
很多專業回答了，別的就不多說了，補充一點兒（竊以為的）Nanite背後的核心要素技術（之一）的細節。不是科普文，只適合有一定渲染基礎的人看。
https://devblogs.nvidia.com/introduction-turing-mesh-shaders/?devblogs.nvidia.com解釋幾個常見的誤解：
- 3D scan或者Z brush的模型（幾千萬或者上億面）可以直接用：對也不對。可以直接扔進遊戲引擎編輯器。但是並不能直接扔進渲染管道。中間有個meshlet的剖分預計算過程。簡單來說，烘培（或者模型導入）的時間更長了。（所以我覺得今後美術和關卡之間還會有一個雲伺服器的距離）而且，對於複雜模型，meshlet的自動剖分不見得理想，有時候還是需要手工輔助調整；但是低模-LOD-法線烘培流水線的確可能是要被淘汰了。（well，在移動端還沒有追上來之前，其實也不會淘汰，而是更加分裂）
- 模型存儲高達*TB：對也不對。製作環境當中的原始文件（3D掃描結果或者zbrush）的存儲開銷的確會很大。所以採用這個新工作流的團隊要考慮用中心存儲替代開發人員的本地存儲，並且要上萬兆網。但是經過meshlet剖分計算之後的頂點存儲，因為meshlet剖分，每個碎片的頂點索引可以被控制在16bit，這就可以大大壓縮存儲容量。
（以上回答基於技術原理推測，不代表UE5或者任何商用產品實際表現）
5/16 更新
先貼兩篇很有見地的分析：
https://zhuanlan.zhihu.com/p/140943267?zhuanlan.zhihu.com
為什麼UE5支持的多邊形面數一下子提升了這麼多？?www.zhihu.com
不管猜中沒猜中，能夠快速給出自己的模型，甚至付諸實踐去驗證，真的是非常了不起的。
在這個基礎上，從我的角度點評幾句。一樣只是一家之言，而且也是靠猜，所以隨便看看就好。
Nanite這個技術的重點是實現了高模的渲染。也就是原汁原味地渲染原始的高模，這應該是一個前提條件。無論是Tess，還是用頻域變換的方法，這其實都是在低模上模擬高模，並不是也不能原汁原味地還原原本的高模。也就是說，添加出來的細節其實和原版有很多偏差。
尤其重要的是UV。Tess技術之所以沒有大流行，就是因為UV極難控制。從各位大神分享的Tess的結果mesh上大家也可以看到，哪個3D模型師敢那樣切割多邊形，我覺得無論哪家公司都會讓他第二天捲鋪蓋走人。
所以，我相信Nanite所存儲的是原始的模型。它所解決的是如何根據屏幕自適應載入模型的問題。而不是如何從低模添加細節模仿高模的問題。
我覺得有一個細節很有意思。視頻當中提到貼圖基本都是8k。8k貼圖的像素數是64M。這看起來好像沒啥？但是視頻當中還提到有個模型是3300萬面。這就很有意思了，因為3300萬（33M）差不多正好是64M的一半。
熟悉渲染的同學應該知道，雖然一個三角形需要3個頂點才能描述，但是對於連續的三角形，如果用triangle strip，那麼理想情況下每增加一個頂點就可以增加一個三角形（另外兩個頂點與別的共享）。而在實際項目當中，當然不會那麼理想，但是2:1這個比例是比較常見的。
所以我們不妨大膽假設如 @ycz 所說的那樣，頂點是存儲在貼圖上的。那麼8K貼圖差不多正好能存儲33M三角形。也就是說，3300萬面的模型頂點數據，差不多一張8K貼圖就可以存完。（當然，因為頂點還有頂點屬性，如UV等，可能還需要配套的一張或者幾張8K貼圖）。
那麼這個貼圖多大一張呢？對於高模，我們保守估計頂點坐標需要fp32才行。在這種情況下，一個頂點是12個位元組。當然因為GPU的對齊關係，恐怕實際按照16位元組排列會效率更高。當然多出來的4個位元組也不必浪費，用來存存PBR要的粗糙度金屬度啥的，或者乾脆就是頂點所在的三角形編號（面序號），都可以。
這樣的情況下，非壓縮紋理：64M x 16 = 1GB。很恐怖是吧，但是在PS5的5GB/s+的SSD帶寬下，整體的載入時間也在200ms以下。況且這是非壓縮的情況。
結合VT技術，根據實際需要載入這個紋理當中的一小塊，那麼就更快了。
然後這張紋理還可以做Mips。如果巧妙地在這張圖上排列頂點，使得在3D空間上相鄰的頂點在圖上也排列在一起，那麼Mips實際上就等於求相鄰幾個三角形的退化三角形。也就是自動實現了減面的效果。
當然這有個前提，就是要將模型正確地剖分成小碎片，避免跨越邊界（導數不連續或者激變的地方）。否則Mips會將這些邊緣給平滑掉。我想，Epic也有提到對導出模型的DCC工具有要求，應該也是指這個意思。可能導出的模型當中不僅僅要有mesh，還需要有子表面的分組信息，以便引擎正確將其分割到不同的VT小格子當中。
Anyway，所有一切在UE5正式公布的時候，隨著文檔以及源代碼可見，自然會有確定的答案。但是看到即便是知乎這種並不專業的地方也能有那麼多有見地的分析，十分受鼓舞，對國內數字媒體的將來發展，至少在技術層面，更加感到有信心。
順便再說一下Lumen（對GI自身修養不夠所以就只說一句）：看到有回答調侃數mm到數千米的說法，其實我倒是覺得可能。這種說法其實恰恰是在暗示Lumen的GI是基於屏幕空間（像素）的，而不是基於場景坐標尺寸的。無論是幾mm還是幾千米，只要顯示在屏幕上，就是那麼點兒像素，是吧。所以它們的確是可以都被cover掉的。
Karis在奠基了UE4的PBR管線後，轉身在UE5實現了革命性的virtual geometry。真鬼才！
這套out-of-core系統對未來的適應性很強，但是如果你要把這套管線發揮最大化利用的話，驚艷之餘，冷靜過後，我們來算算這個帳，先不說運行時，如果一個遊戲全用8k貼圖，上百MB的單模型資源，這遊戲最後包體有多大？1T遊戲不是夢！反過來，對CG來說這就不是問題了。
有同學開玩笑說，這不就是個mesh shader嗎？當然不是。你考慮下virtual texture，本質不是靠暴力算的，所以VG如果繼承的是VT的精神，那麼他必然可以做到控制消耗，設定一個規定的大小，流式傳送需要的頂點數據。
相比較Nanite是Karis的親兒子，Lumen乍看起來很像Enlighten，熟悉UE的同學一定知道Daniel Wright，Lumen就是這位大神操刀的
補充更新：5/15
Nanite使用基於cs的軟光柵。（鏈接文章原本有鏈接後來被刪）
lumen使用的是非三角面的Ray tracing，場景數據結構採用SDF，voxel和height map。使用screen space技術處理微細節，sdf處理中等粒度細節，voxel處理粗粒度的細節。這些配合temporal技術來達到優化性能的目的。
ref：https://www.eurogamer.net/articles/digitalfoundry-2020-unreal-engine-5-playstation-5-tech-demo-analysis
感謝評論的反饋，發現打臉了。
因為之前並沒有看到官方人員關於Lumen的官方解釋，所以憑視頻猜測是Lumen的實現依然基於rtx的這套方式去做。直到看到這篇採訪，Brian Karis和Daniel Wright兩個大佬親自現身說法
Inside Unreal Engine 5: how Epic delivers its generational leap
確實證實了：Lumen是光追，但不是像rtx這樣的三角面精確光錐，也不依賴硬體加速。
眾所周知，光追直接將光描述為射線，模擬這些射線在空間里不斷反彈、折射、傳播。
而這裡最大的計算壓力，在於要計算每一條射線到底擊中了哪個三角面。因為光追考慮的並非屏幕中的三角形，而是整個場景的所有三角形，大型的場景可能是上億起算。
rtx給的思路是：我用硬體幫你加速這個計算。
而Lumen用了一個非常有意思的思路去實現：
既然找到擊中哪個三角形的計算量那麼大，那麼我乾脆不去搜索三角形，而是用其他更簡化的數據結構表達這個場景。
Lumen用了三種方式去做ray trace
1.對遠距離傳播，使用voxel去計算
2.對中距離傳播，使用distance field去計算
3.對短距離細節，使用屏幕空間計算去修正。
有趣的是，這三個方案，其實unreal都做過，分別對應SVOGI、DFGI、SSGI
SVOGI（基於voxel的GI）當年原本是UE4欽定的方案，使用voxel表達場景，搜索方式也類似BVH，只是對象是體素而不是三角形，有一定程度的簡化。但這個方案，因為PS4實在跑不動而放棄，sweeney也是公開表示過鬱悶之情。事實上Nvidia也做過類似的方案，叫VXGI。其實效果還算不錯，但因為RTX的出現，當然是被拋棄的節奏，畢竟老黃要賣顯卡。
DFGI（距離場GI）是基於距離場的實現，同門師弟還有DFAO（用距離場算AO）和DFRTS（用距離場算陰影），結果後面兩個保留下來了，但DFGI因為精度實在不行（其實DFAO精度也不行，但很多情況下可以接受），有諸如漏光、臟（插值不勻）等問題，最後默默的從代碼庫里屏蔽了。
距離場的問題在於，一個模型，最多只能用64 * 64 * 64的volume texture去表達。你想像一下把一輛車切64刀，每一塊下來其實都很大，根本不能精確到車身上每一個細節。在這樣低精度的環境下進行raymarch，漏光的問題就很容易出現，同時一些比較細的結構產生的光照反彈、遮擋也很難表達。
另外，DFGI基於raymarch，而raymarch發射出去的射線，是有長度限制的，如果通過增大步長來提高最大距離，精度就下降；反之最大距離就不夠。所以DFGI也不太適合計算長距離的GI。像視頻開頭那道陽光可是打亮了整個大山洞。
至於SSGI，目前是公開可用的GI功能。既然冠名screen space，那麼就只能計算屏幕里能看見的光傳播。但是，這種方法，不但忽略了屏幕外的光照反彈（一盞紅燈照亮的區域離開了屏幕，那麼SSGI會完全忽略它的亮度貢獻），還無法計算屏幕中遮擋的部分（箱子後面藏一個紅燈，遮擋的部分同樣被忽略），結果就是這個GI的效果非常不正確。在我們的實踐中，SSGI用於現代建築的環境下還不錯，但有豐富植被的自然環境效果就一般般，因為植被的層次負責，有很多像素被遮擋在後，SSGI無法對其做計算。
而Lumen，非常聰明地結合了這三個方案：
Voxel計算較慢，但可以支持遠距離的搜索，那麼我用來處理遠距離的傳播，彌補距離場raymarch的距離限制
而距離場就用來計算中距離的傳播，這樣raymarch的步長也可以縮短，提高精度
Voxel和距離場完成了主要的空間級傳播，解決了屏幕空間沒法表達整個立體空間的問題。而距離場的精度問題最後用屏幕空間的信息修正一下。
除了Lumen，採訪中也提到，Nanite基於自己的compute shader實現軟光柵化，Mesh shader和Primitive shader都只是備胎。
這對老黃的N卡來說，可不是好消息。
Lumen這個方案有優秀的跨平台性且開源，各大廠可能紛紛效仿。
RTX雖然提供了精確三角面碰撞計算，但問題是性能又遠達不到支撐完全GI的程度，使用降噪方案，畫質上未必有絕對優勢，但性能卻也是剛剛及格，硬體卻貴的要命。
老黃的顯卡可還怎麼賣~
當時看到Turing架構的時候，雖然覺得牛逼，但隱隱也會想，把需要高度自由定製的關鍵演算法做到硬體里，到底是不是一個好的選擇。畢竟，軟體可以迭代，硬體是固化的。如果硬體滿足不了演算法的需求，那這個就變成了擺設。
接下來Nvidia怎麼推動技術標準的演化，拭目以待。
（A卡：？？？）
（原答案，大的結論被打臉，可以看上文，但是幾個分析還是有效的，新的Lumen方案是否能解決，我們依然需要觀察）
來聊一下視頻里沒有提到的光追坑
目測lumen大概率就是現在rtx光追的威力加強版（支持了AMD平台），因為目前UE4.25有的坑似乎一個沒少。
1.在光照劇烈變化的時候，暗部的GI噪點依然存在，這個是由於目前GI都是分幀疊加再去噪，所以光照變化的時候由於疊加歷史不正確而出現噪點。平時有直接光照所以看不大出來，但暗部因為只有GI就會比較明顯。
（仔細看暗部，會發現有一種模糊感，建議直接看原視頻1080p，知乎圖片壓縮比較難看清）
（之前測試使用final gather模式的RTGI照亮暗部，因為精度和雜訊的緣故，產生的光照也具有這種難以描述的模糊感，但性能確實輕鬆達到30fps+的水平，1080p+rtx2060）
2.視頻規避了植被，因為目前光追需要持續構建BVH，靜態物件可以只構建一次，但畫面中有海量帶頂點動畫的植被就需要每幀都刷新海量的BVH，是性能硬傷，目前似乎也還沒有人提出比較完美的解決方案。4.24提供的頂點動畫支持也是針對單物件且需要手動開啟，足見這個功能存在的性能風險。
（植被加入頂點動畫後如果沒有刷新BVH，那麼光追陰影就會出現部分面發黑的問題，因為真正的頂點和BVH里的頂點已經匹配不上，此外牆上的投影也不會動）
3.視頻里透明物件不多，透明/alpha test投影的支持目前也是一堆堆的坑，不過這些隨著時間應該會逐步解決。
4.至於為什麼沒有順道炫一下4.24新增的毛髮系統，目前估計是對光追管線的整合不完善。這也是光追管線一個比較大的痛點，就是老的各種shading model、vertex factory都需要針對其做適配，還要考慮BVH的構建。另外這套毛髮系統目前還非常非常不穩定（正在深受其害中的路過:P）
（插片實現的頭髮，無物理）
不過好消息是，PS5的光追性能看來是杠杠的，實時光追普及化指日可待。
至於nanite，真心的牛逼技術，應該是結合了virtual texture的思想並用mesh shader實現。其他答案里也說了不少這裡就不再贅述。
不過大家千萬不要覺得產品里真的隨便用zbrush高模，看著紅紅的硬碟空間還有慘烈的導入、構建時間，我覺得大家還是會老老實實該減面減面、該烘焙法線就烘焙，畢竟virtual texture出現都有10年以上了，也沒見哪個遊戲真的8k貼圖的隨便往裡塞。但是影視方面的同學確實是製作規範上解放了不少。
至於其他方面，預計UE5本質其實還是UE4.30，也就是一個功能更新比較大的迭代版本，但是大的已有模塊並不會一下子都來個大翻新（比如藍圖、sequence、mobile管線等）。但即使這樣，隨著niagara和chaos這些東西正式化，再加上nanite這樣的神級系統，你還是不能不說，UE5超香的。
就在不久之前，我們剛剛揭開了虛幻引擎5的神秘面紗。我們對於次世代的願景之一就是讓實時渲染細節能夠媲美電影CG和真實世界，並通過高效的工具和內容庫讓不同規模的開發團隊都能實現這一目標。
歡迎觀看 「Lumen in the Land of Nanite」，這是一個在PlayStation 5上實時運行的實時演示：
該演示展示了虛幻引擎5的兩大全新核心技術：
Nanite虛擬微多邊形幾何體可以讓美術師們創建出人眼所能看到的一切幾何體細節。Nanite虛擬幾何體的出現意味著由數以億計的多邊形組成的影視級美術作品可以被直接導入虛幻引擎——無論是來自Zbrush的雕塑還是用攝影測量法掃描的CAD數據。Nanite幾何體可以被實時流送和縮放，因此無需再考慮多邊形數量預算、多邊形內存預算或繪製次數預算了；也不用再將細節烘焙到法線貼圖或手動編輯LOD，畫面質量不會再有絲毫損失。
Lumen是一套全動態全局光照解決方案，能夠對場景和光照變化做出實時反應，且無需專門的光線追蹤硬體。該系統能在宏大而精細的場景中渲染間接鏡面反射和可以無限反彈的漫反射；小到毫米級、大到千米級，Lumen都能遊刃有餘。美術師和設計師們可以使用Lumen創建出更動態的場景，例如改變白天的日照角度，打開手電筒或在天花板上開個洞，系統會根據情況調整間接光照。Lumen的出現將為美術師省下大量的時間，大家無需因為在虛幻編輯器中移動了光源再等待光照貼圖烘焙完成，也無需再編輯光照貼圖UV。同時光照效果將和在主機上運行遊戲時保持完全一致。
這一品質上的飛躍得益於無數團隊的努力和技術的進步。為了使用Nanite幾何體技術創建巨型場景，團隊大量使用了Quixel的MegaScans素材庫，後者提供了具有成百上千萬多邊形的影視級對象。為了支持比前世代更龐大更精細的場景，PlayStation 5也大幅提升了存儲帶寬。
該演示還展示了現有的引擎功能，包括Chaos物理與破壞系統、Niagara VFX、卷積混響和環境立體聲渲染。
虛幻引擎4與5的上線時間表
虛幻引擎4.25已經支持了索尼和微軟的次世代主機平台。目前Epic正與主機製造商、多家遊戲開發商及發行商密切合作，幫助他們使用虛幻引擎4開發次世代遊戲。
虛幻引擎5將在2021年早些時候發布預覽版，並在2021年晚些時候發布完整版。它將支持次世代主機、本世代主機、PC、Mac、iOS和Android平台。
我們正在設計向前兼容的功能，以便大家先在UE4中開始次世代開發，並在恰當的時機將項目遷移到UE5。
我們將在次世代主機發售後，讓使用UE4開發的《堡壘之夜》登陸次世代主機。為了通過內部開發證明我們行業領先的技術，我們將在2021年中將該遊戲遷移至UE5。
虛幻引擎的分成門檻提升至遊戲總營收達到100萬美元
大家仍然可以一如既往地免費下載並使用虛幻引擎開發遊戲。但從今天開始，分成門檻提升到了遊戲總營收首次達到100萬美元時。全新的虛幻引擎許可條款將給予遊戲開發者們遠比其他引擎的許可模式更慷慨的待遇，且其效力可追溯至2020年1月1日。更多詳情，請參見常見問題。
Epic在線服務上線！
好友、匹配、遊戲大廳、成就、排行榜與賬戶：我們為《堡壘之夜》開發了這些服務，並使其登陸了7大主流平台——PlayStation、Xbox、Switch、PC、Mac、iOS和Android。現在，Epic在線服務將免費向全體開發者開放，只需一套簡單的多平台SDK即可！
將你自己的賬戶服務、平台賬戶或Epic賬戶系統與這些服務混合搭配使用，就能直通由超過3.5億玩家以及他們的22億好友組成的龐大跨平台社區，覆蓋超過5億的設備。
聯繫我們
UE反饋需求：https://trello.com/b/NvJrWDb7/ue-request
虛幻引擎官方QQ群：1018846968
虛幻引擎官方B站：https://space.bilibili.com/138827797
官方社區郵箱：[email protected]
官方社區經理：大釗([email protected]，QQ:2722937652)
投稿聯繫：知乎上私信或聯繫小輝輝-社區管理（QQ:258327199）
我來講講UE5對電影行業的影響吧。
我是電影學院攝影系的研究生，我畢業論文寫的正是虛擬製作（Vitural Production），媽呀，這正準備雲答辯，馬上論文里三分之一的東西就要被淘汰了，我的內心是一陣崩騰。
原來這種技術的更新，一般只有CG行業的人才會格外關注，但是昨晚的朋友圈刷屏里，我身邊認識的大量的攝影師、導演、電影后期製片都紛紛轉發，電影人們瞬間被驚醒——什麼？現在遊戲都能到這個畫質了？
唯一沒轉發的是我認識的一後期公司的老闆，他只是默默得轉了一句，後期公司太難了。
下面我來講講為什麼UE5會對電影行業產生顛覆性的影響。原來電影人對於利用遊戲引擎進行電影的製作的有點嗤之以鼻的。
你要是跟一個電影人說，你這個片子拍得很遊戲啊！那絕對是在罵人。
但是在UE5這一波過後，你再跟電影人說你的電影拍得很遊戲啊！那導演估計會覺得你把他捧得有點高了。因為目前在電影特效領域渲染的畫面，還沒有這個UE5demo渲染的質量高呢！
不過從行業的發展看來，UE5今天的發布，其實主要是補上了其在超高模型解析度和實時全局光照中的最大短板。
但UE在電影行業上的布局其實早就已經開始了。
過去幾年裡，我一直在研究如何用引擎來輔助電影創作。在之前的行業應用中，遊戲引擎主要被用於電影的預覽製作。
在2017年的時候，我就作為引擎技術指導參與了電影《鼠膽英雄》的預覽製作中。我們當時用了UE和Unity完成了《鼠膽英雄》超過100分鐘的預覽畫面。
當時，我們就用到了激光掃描掃描和場景重建的技術進行預演的製作。
我與技術團隊前往了多個實拍取景地，利用激光三維掃描和航拍照片建模的方式，對場景進行三維掃描。並利用這些數據進行了場景的三維重建。為《鼠膽英雄》的虛擬勘景提供了數字資產。
激光掃描儀的基本原理與激光測距儀一樣，它利用不斷旋轉的反射鏡向外不斷發射激光，並計算激光反射回來的時間差，從而得之該點到掃描儀之間的距離。當激光掃描儀旋轉一圈之後，則可以獲得周圍一切物體與掃描儀之間的距離，形成點雲文件。激光掃描同時也會拍攝全景照片，通過將點雲和全景照片進行像素和點的位置的一一對應，就可以得到帶有色彩信息的點雲文件。
因此，可以將無人機拍攝的照片映射在激光掃描的模型上，最終生成帶有高清貼圖的模型文件。
當時，我們利用這樣的製作流程，將完全物理精確的場景信息，通過激光三維掃描還原到虛擬場景中，這樣後期就可以進行VR虛擬堪景和虛擬拍攝了。
但在2017年的時候，我們僅僅能利用這個技術進行虛擬預演。但因為引擎的畫質還是離影視級差距太大，這些預演數據只是可以進行參考作用，而無法進行實際電影的拍攝。事實上我們當時壓根就沒想到用這個東西能拍正式的影片。
但現在UE5更新之後，我們可以直接導入數以億計的三角面，也就是說，我們利用激光掃描儀和照片建模出來的毫米級精度的數據，如今可以經過處理後直接變成引擎內的資產。（當然，實際上還需要去除光照信息，進行補面和優化等看起來很美，實際很麻煩的過程），但這至少是能在引擎內復現真實世界的一大步。 這實在是讓我們做電影CG行業的太興奮了！
想像一下，剛剛我們掃描的場景數據，可以被精確地在引擎中高質量地還原。然後我們還能製作高質量的數字角色。然後我們擁有了動作捕捉和表情捕捉技術，我們再扛上一個虛擬攝影機，我們就可以在虛擬空間內進行拍攝了！
未來虛擬攝影師這個行業將成為攝影行業的必備技能，傳統的攝影師也必須掌握虛擬拍攝技術，才能在虛擬電影製作行業內找到一席之地。
推薦閱讀：
