為什麼Unreal 4引擎能輕易實時渲染出vray要花半天才能渲染出的場景？
這不是真的！This is Unreal！
看了這個文章，大為感慨。如果有人以unreal 4為基礎開發渲染軟體，和rhino、su、revit等常用建築軟體對接，畫面太美不敢想。
我來通過對比兩張圖片來答一下。下面兩幅圖，同樣的場景素材，同樣的光源，非常接近的材質模型，但用的是完全不同的渲染方法。
第一幅是我自己的渲染器用基於光線追蹤的無偏全局光照演算法渲染，第二幅是用虛幻引擎（版本4.7）的渲染引擎渲染。
首先說明一下，第一幅圖片中椅子的扶手和桌子底部是塑料材質（漫反射加光滑鏡面反射），而第二幅中是金屬材質（粗糙鏡面反射）。原因是UE4導出的時候沒有把整個素材弄成一個材質了，我也懶得再編輯。然後桌上的雕塑第一幅是毛玻璃，第二幅是平滑玻璃。其餘材質都一樣了。
接下來點評一下兩幅圖中的不同之處。第一個最抓眼球的區別就是場景底部平面的鏡面反射，兩個都是用粗糙參數為0.25^2的GGX模型 描述的粗糙鏡面，上下圖的差異很大。上圖是完全基於對BRDF和光源採樣的無偏結果，可當做參考，下圖則是可以說暴露了虛幻引擎4對輕微的粗糙反射的一個缺陷。虛幻引擎4中的反射解決方案是屏幕空間反射（Screen Space Reflection，SSR）加環境貼圖。對於非常平滑的表面，當它在場景中的反射剛好在屏幕上存在時，虛幻引擎4會使用SSR。當表面變的粗糙，或者反射部分在屏幕邊緣時候，反射會變成SSR和環境貼圖的加權和，直到對特別粗糙的表面完全變成使用環境貼圖。（其實這裡我只要再把粗糙度調高一點，SSR就完全沒有了，不過那樣就完全看不出反射了因為環境貼圖的反射特別粗糙，不利於比較）所以下圖中的結果可以說是一個平滑鏡面反射和粗糙鏡面反射的加權和，當然無法真正模擬出輕微的粗糙反射。（這個問題用最近的Stochastic Screen-Space Reflections可以得到一定的解決，不過很多時候不那麼robust）
第二個比較細微的區別則是下圖中桌椅黃色部分的鏡面反射有信息丟失了。這個便是因為SSR演算法本身無法處理反射物體在不在當前屏幕上的情況。這個Artifact其實在現在的遊戲中也非常常見，相信很多人都注意到了。SSR另一個細微的錯誤則是反射中的鏡面高光會是錯誤的，因為高光的計算取決於視線入射方向，直接從根據相機方向計算的屏幕上取是不對的。不過這個問題比前一個丟失信息的問題小多了，沒人care。。
第三個差別是底部平面的高光區域在下圖比上圖分散很多，看起來下圖底部的屏幕比上圖更加粗糙。這個是由於兩種完全不一樣的Image Based Lighting的方法導致的。上圖還是一切基於環境貼圖的能量分布採樣光源，虛幻引擎4則使用了Split-Sum，將渲染方程的光照部分和BRDF部分拆開分別積分，再對於兩個積分的結果球積。具體可以看這個鏈接http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_slides.pdf
其中光照部分的積分又使用了Prefilter Cube Map的方法。再講細一些，UE4的環境貼圖是128x128x6的解析度，7層MipMap。每一層的每一面都用1024個樣本採樣不同粗糙度的GGX去Filter。這裡有幾個產生誤差的原因，第一是誤差是採樣GGX的入射光線永遠是等於表面的法線方向，所以沒辦法模擬出上圖那樣在入射角和法線角夾角大的時候那種拉長的高光。另一個誤差則是只採樣了7個離散的粗糙度，並且不同的粗糙度使用的不同Mipmap，這樣做對性能更有利，但是這種粗糙度和Mip層的映射完全是Epic的人「發明」出來的，完全不是基於物理。我自己試過同樣的BRDF在UE4中做Image Based Lighting都會比真正的離線參考看起來粗糙許多。當然只要結果 Artists用著舒服，粗糙度看著有變化，也沒有什麼不好的。
第4個差別是下圖中桌子下面的部分和上圖比明顯偏亮。這個誤差則是因為環境貼圖的遮擋信息只有在capture的那一點才是正確的，例如這裡環境貼圖是在桌子上面capture的，桌子下面的部分大部分入射光被桌子遮擋，應該會比較暗，這裡則變成桌子下面接收到的光照和桌子上面一樣，所以和上圖比偏亮了。解決辦法就是應該在桌子下面人工多capture一個單獨的環境貼圖。
除了這些區別，色調的不同，以及背景模糊度的不同，都是不同渲染系統的post processing參數以及其他工程性的小問題，就不細說了。
除了這些渲染本身的區別，實時渲染系統往往也需要更多的artists work才能hack出接近真實的畫面，例如在場景不同的地方放置probes，提前烘焙光照貼圖等。
最後，現在別說是用UE4做建築可視化，就連做低成本動畫電影的都有。畢竟快速的迭代可以降低很多的成本，也就有可能出現一些非Pixar那種一定要男女老少都能看才能保票房的題材的片子。
而且要不是我這樣把UE4脫光了衣服拿出來比較，大家直接看著也不會覺得有任何問題。甚至我相信很多讀這個答案的人盯著這兩張圖看不出差別的。搞圖形的就是這樣。。廢了半天勁很可能是自娛自樂，真的搞的真實好看了，看得人也認為是理所當然。。算是自己開發實時渲染引擎，所以想關於這個問題談論下自己的看法。
我覺得樓主的問題出現了三個很大的誤區，有必要糾正一下。
第一，從光影的效果來說，Unreal並非是一個全實時計算的引擎，而是實時計算+預渲染。遊戲引擎中為了呈現出以假亂真的效果，很多時候都會使用預渲染的技術，所謂預渲染的技術，其實就是把一些複雜的中間計算結果緩存在貼圖之類的存儲結構里。這樣的技術非常常見，大部分的核心思想是演算法裡面的空間換時間的策略，或者是簡化問題的模型，減小計算規模，所以現在單機遊戲越來越大，很大一部分資源是被這些東西佔用了。我簡單列舉一些常見的為了逼真效果而做的預渲染：
light map，這個東西應該是最廣泛使用也最早使用的東西了，簡單的說就是把光強度在整個場景中的分布用貼圖存儲下來，配合第二UV，在真正實時計算光照的時候就省去了計算光強這部分的計算量；對於一些複雜形狀的光源，在很難對它的光強在任一點的積分求數值解或者計算量過大的情況下，一般這類光強分布會被緩存在一張貼圖上，叫法可能各不相同，或者是environment map，或者是image based lighting，或者是IES light，但是這類東西我覺得本質上是一樣的東西，都是光強分布函數的離散化存儲，計算是離線的。在實際應用中，比如局部的反射策略可能是environment map + SSR（屏幕空間反射），比如為了繪製天空的色彩，會把大氣散射係數，介質濃度之類的參數引入，預計算一個參數索引的離散數組用來模擬實時的天氣效果（陰晴或者早晚），複雜形狀的光源可以考慮用光域網（IES LIGHT），整個場景中的複合的多光源的光強疊加分布模擬可以考慮light probe的線性組合，這類預計算往往都有一個特性，就是光源位置，受光物體的位置之類的往往是不能動的，這也就間接說明了Unreal其實不是全實時渲染的。當然有些預渲染方案能做到和光源位置之類的無關，比如說球諧係數這樣的預計算方案就不要求光源位置固定，但是即使如此它還是會有一些明確的參數固定限制，比如光源數目一定是固定的。
第二，從光影效果上來說，Unreal的效果絕對是不如Vray之類的好的，之所以會有Unreal看起來效果和Vray一樣的錯覺，是因為在很多領域都會存在類似邊際效應。也就是說，並不是我花兩個小時渲染一張圖，得到的效果就一定比你花一個小時渲染出來的圖的效果好一倍。這其實是個很簡單的道理，當效果好到一定程度的時候，想要細微的提高也要大量的計算量，就拿這兩年比較流行的GI問題來講，理論上講間接光照是可以無限遞歸下去的，但實際上間接光照經過三到四次的反射，它對一個物體表面的點的顏色的貢獻就微乎其微了，所以當你使用光線追蹤技術來渲染一張圖，遞歸次數調成10和調成4在其他參數不變的情況下可能效果也不會有肉眼明顯可見的區別。而這兩年流行的許多新的實時GI演算法，就是相當於處理了一個多項式的高階部分的近似而捨棄了低階部分，同時它也一定程度上降低了問題規模。譬如Unreal用到的voxel cone tracing，按我的理解實際上就是蒙特卡洛方法的一個近似版本，這個近似版本能夠很好的模擬出間接光照的主要貢獻，至於那些次要的貢獻，像樓主這樣可能美術專業出身的童鞋也不一定看得出，何況是一般的遊戲玩家在眼花繚亂的場景里。更早一些的時候，還有SSVO用來模擬間接光照造成的局部明暗，或者是有light shaft來模擬介質的散射效果，更早以前的時候的天空盒來模擬大氣。所以任何引擎肯定都會在單位性能對畫面的提升效果上力求性價比最高。
第三，Unreal終歸是一個遊戲引擎，它的設計目的不單單是為了渲染畫面如何優秀，更多的是針對遊戲的一些特殊功能的開發和應用，以及如何簡化遊戲開發的工作流，而Vray這類是專為渲染而生的，它們之間或許在渲染方面有交集，但是並不存在互相替代的關係，甚至可以說不太相干。
以上是就我懂的來簡單稱述，如有不對的請指正。
baking過lightmap了唄，背後花的時間也未必就比vray花的時間少了。
遊戲渲染和動畫渲染是一條從兩頭挖掘的隧道，會越來越相像。
遊戲渲染的光影效果如果是要實現GI,基本都是有前期baking的工作，做完之後，在posteffect上疊加了ssao ,甚至ssdo等等的效果上去，以盡量絢麗，但是減少渲染工作量的方式，實現實時渲染。
當然題主用vray比較，其實不公平，vray還是太老了，gpu對渲染的加速效果沒被考慮進去，用過octane和unreal比較，好像更能體會兩個領域的不同技術發展。 octane即使犧牲一部分質量，效果也是跟接近物理真實的光照感覺。
當然unreal也不錯，lightmass還是效果相當好的。
但是用unreal4做效果圖是個腦殘行為，我私下跟朋友解釋過多次，遊戲引擎是龐大的，渲染模塊是非常小的部分，如果用於效果圖，那所有的模型導入材質簡化等等的工作，就沒有必要，而這部分工作其實是巨大的工作量，（我還沒跟你算投入和產出呢，不划算）， 如果真要做，就做互動式的程序，才有點用處，（其實還是沒卵用，客戶壓根不想做這種操作，除非你提供功能性進去，但是光擅長效果圖的製作者，哪裡顧得上功能）。
Lumion其實也是個腦殘玩意，對建築效果圖的需求來說，需要的是一個渲染神速的渲染器就好了，Octane做渲染，redshift做動畫渲染是大趨勢，只不過國內這方面技術的討論非常落後，大家還以為lumion什麼的還多新鮮，還以為cryengine的渲染比unreal強， no no no, 那些早老土了:D來補充些內容，讓這個事情說得更明白一些：
先上視頻：我和余德傑都是建築學的，愛好CG，做這件事情，就是想學一下UE4，視頻什麼的都是學習過程的副產品，學了半天總得做個小成果展示一下啊。
樓下說軟文的先生 @haisenberg ，你確實是誤會了，不過也不怪你，因為這個問題看起來確實很像軟文！（笑）為啥咧？因為這是建築系的同學問的，搞引擎和遊戲的專業同學不會有這樣的誤解。
要知道建築學這邊的學生一般都是拿Vray之類的渲效果圖的，也沒人教，都要很苦逼的自己摸索，突然看見這麼好的實時效果，自然會冒出這樣的困惑。
所以，要認認真真的的回答這個問題的話，還要按知乎的規矩來：先問是不是，再問為什麼。
不存在題主所說的情況：UE4並不能輕易實時渲染出寫實場景。
想要一個好的UE場景，前期需要大量的優化，模型的優化，貼圖的優化，然後還需要光影烘培「Build」的時間，而這個時間，就類似於Vray在渲圖的時間。參考這個問題下的幾個專業人士的回答，拿Vray渲染器和UE比其實是不公平的。
但是UE的間接光線不像Vray渲染的精度那麼高，在能容忍的粗糙範圍內，小場景的Build的時間也不需要太長。
以我們這個場景為例，因為模型用的是現成的Evermotion高精度模型，未經優化，最終整個小沙盒的Build時間是2小時左右。配置是：i7 5820k。如果模型優化得好，Build時間會大大降低，但是優化的時間要數倍於為Build節省的時間，但是別人運行起我們這個場景來就會更流暢。我們要是把周邊的牆斷開成四個小面的話，牆的光影貼圖面積就不用那麼大了，牆上的光影精度會大大提升，Build時間也會下降。
你發現了嗎？就像等價交換一樣，一切效果都要代價，效果好則時間肯定相應增加，無論你是離線還是實時渲染。處處要取捨。
我個人一直主張在學習設計的過程中把建築的可視化技術前置，結合到方案推敲過程中，而不是方案做完了畫張效果圖交差，那樣對建築學習沒啥意義。我們看中的是實時渲染沙盒的自由度，以及模型搭建出來以後，推敲材料的方便性。
所以這裡提醒各位建築系同學，好工具要用對了地方，不要看視頻效果好就拿UE做效果圖，最後很可能吃力不討好。這事情不是這麼個玩法的。
當然了，如果是專業做效果圖的公司，自己優化好大量的模型庫，那做起效果圖來效率也是非常高的。
Lumion就是想做這方面的嘗試，我之前搞錯了，我之前以為是ue3，經評論提醒，Lumion是基於quest3d引擎開發的。
但是之前的Lumion效果還是有點假，不知這次的新Lumion怎麼樣，有沒有突「假與真」的臨界點。
現在UE4效果更上一層樓了，如果有人用UE4做一個供建築設計專業使用的軟體，那確實會很有助於空間材質效果的推敲。
下面簡單說說光影烘培技術的思路。
實時引擎的光影烘焙利用的一個事實就是漫反射物體的光照和光線反彈是「攝像機無關的」。
比如下面這個簡單的場景，立方體、球體、光源的空間位置一旦敲定，每個點的著色就不會隨著觀察者位置的移動而改變了。說白了就是，我攝影師扛著相機圍著你亂跑，模特臉上的顏色不會跟著變來變去的。
如果場景光照條件固定，那麼這些光影信息就沒必要參與實時計算了，只需要預先計算出來，在UE4里叫「Build」。然後把這些光線的明暗著色「烘焙」到物體表面就好了。
所以物體表面的貼圖著色就變成這樣了：
如是製造了光影著色的錯覺。
所以雖然叫實時渲染，但是很多時候並不是「實時」計算的，而是預先計算的。
UE4里的lightmass還不簡單的是一個光影貼圖，而是一個立體的陰影區域，Build好以後，只要物體挪到了影子里，也會變黑。很棒的技術。
剛才說了光照是「攝像機無關」，反射效果就是「攝像機相關」的：
要補一句，這裡的反射是狹義的像金屬之類物體的光亮的反射，不包括漫反射，昨天有位同學問我漫反射也是反射啊，把我提醒了。
一旦涉及反射折射等效果的著色，那麼就和攝像機的位置關係很大了（不同角度反射到的內容自然是一直在變），這種東西就要靠實時的顯卡計算，但是在實時渲染中，這裡面trick很多，能滿足視覺效果，但是不科學。
科學的還是maxwell那種物理模擬計算，需要離線渲染，需要很多時間。
知乎圖形學大神太多，我這個壓力還是很大的。
嚴格地說，引擎的效果圖輸出在絕對質量讓上沒辦法跟傳統渲染器對比，只不過好在最終客戶那裡不追求絕對的精度，，只是感覺對了就可以了，而且國內客戶龜毛得多，不改個幾十次肯定不甘心。
為了提升引擎的處理效率，GPU的功勞很大，這跟傳統的只吃CPU的vray效率高很多，然後是PBR材質的廣泛使用。在你看得到的地方展示細節，你看不到的地方就省資源。多方面的結合，才有看起來初步多好的效果圖。
很多時候多倍的時間消耗帶來的素質提醒並沒有時間這麼大。 簡單說，你用三個小時渲染的圖，UE4裡面一個小時出來的圖不一定只是你的三分之一的畫面質感。對於最終用戶來說，對於絕對精確的追求者很少，大部分人只是看結構，色調，搭配感覺舒服了就可以了。所以以引擎為代表的GPU渲染模式才逐漸的被人廣泛接受，想當年Vray之前的Brazil渲染器，慢的令人髮指，還有一個叫lightscape的（拼寫好像不一定正確）都以追求物理級別反射真實性著稱。但是隨著時代進步，硬體效率提升，人們更加註意到在畫面之外的重要性，所以效率成了很重要的部分不用做光線跟蹤的快都是耍流氓。
屏幕空間反射還好吧。
屏幕空間折射很容易穿幫。UE4 能渲染面對面的鏡子么？
渲染器如vray等和遊戲引擎如虛幻4等在渲染原理上有什麼不同？為何建築渲染不用又快又好的遊戲引擎渲染？ - 三維渲染
這個問題其實已經有人問過了。
我覺得之所以遊戲引擎不能替代vray之類的渲染引擎，主要得問題在於對材質上可能性的差距。
既然是遊戲引擎，為了提高載入速度一定會採用大量的預渲染。換句話說，遊戲引擎看起來能輕易實現常見材質的渲染效果，是因為這些材質的參數被預先設定在了程序裡面，在你選定組件的時候，它在畫面上的表現直接從參數表裡拖出來就是了。所以類似的lumion這種原理類似的渲染器也是一樣，庫里選一顆樹，拖進去畫面里就出現一顆樹，非常快。
但是
如果我要改變這個樹的顏色呢？改變樹皮的紋理呢？改變樹葉的透明度呢？增加葉脈的細節呢？
如果每一個變化我都要在資料庫里做一個預設，那麼這個渲染器的體積就會不可避免地龐大下去，最後根本沒辦法載入了，因為沒有電腦的硬碟和內存能夠儲存這麼多的數據。所以這種時候還是得需要vray這樣的渲染引擎，儘管慢，但它可以讓你創作現實中任何（當然在引擎的理論範圍內）有的或者沒有的效果。
但是如果你希望以渲染圖來推敲不同材質導致的氛圍變化，自然還是得需要vray這樣的渲染器。
預渲染和渲染器精度問題。現在流行使用PBR渲染。遊戲引擎只是表面的工具，其實如果你把遊戲引擎的幀率降下來，把渲染器集成上去，把shader加上去，完全可以和建模軟體渲染器一樣的。
本質上來說，傳統光柵化演算法是挑選最有用的一部分光線的最有用的一段傳播過程進行模擬，其它的光線或者傳播過程敷衍了事（說好聽點叫近似處理，其實一點都不近）
而vray是無差別對所有光線的整個傳播過程進行模擬。
光柵化演算法=ray tracing的精簡
所以，怎麼可能出現光柵化=ray tracing這種情況？你想太多了，隨便找張高端點的效果圖那都不是ue4能實現的
個人覺得遊戲引擎裡面有很多方便的工具能提高效率，比如unity裡面的terrain可以快速建造地形，刷草坪，刷樹
推薦閱讀：
※如何證明行列式值能表示一個平行六面體的體積？
※如何對球體和長方體進行碰撞檢測?
※謝爾賓斯基三角形能用編程寫出來么？該怎麼寫？
※使用目前的高配GPU 如何實時渲染一顆黑洞？
※你寫過什麼有趣的程序？