什麼是實時光線追蹤技術?它可能出現在當前的次世代主機上嗎?

實時光線追蹤(Real-Time Ray Tracing)一直是很多圖形技術發燒友心中的夢,該技術一旦實現就將徹底顛覆現在的光柵化渲染技術,成就真正電影化的遊戲圖形應用。包括英特爾、英偉達和AMD等在內的多家行業公司都曾在其中投入巨大的努力,但光線追蹤技術極其消耗資源,此前多數只能在低解析度、低幀率下模擬。


而就在近期,微軟工作室全球副總裁Phil Spencer在其個人推特上回答網友提問時,證實微軟正在自家的次世代主機上測試實時光線追蹤技術,如果這項極具潛力的圖形技術能夠在Xbox One上實現,那麼Xbox One近期以來的畫質爭議毫無疑問將得到根本性的改變。


http://www.wpdang.com/archives/102314.html


多年搞各種實時、離線渲染,我來說說看法。

首先對於題主的問題,實時光線追蹤在遊戲里的應用,我的看法是當前次世代主機真不可能。未來3-5年也許一些內基於光線追蹤的非全局光照演算法出現,例如鏡面反射等,主要用來彌補或者增強現有演算法的缺陷。光線追蹤的真正普及則會是一個漫長的過程,要整個industry一起努力。至於真正的無偏的全局光照,要做到實時所需要的計算量在可預見的未來都還是太大。

關於光線追蹤介紹不少人都解釋了,我原來也寫過些答案提到過:如何根據數學或者物理程式寫一個特效軟體?例如星際穿越中的黑洞。 - 文刀秋二的回答 我在這裡補充一些自己的觀點。一提到光線追蹤,許多人第一反應就是圖形渲染的聖杯,實現以後遊戲的畫面就會和好萊塢大片一樣震撼。這其實是很不實際的主觀假設。
誤點1:把光線追蹤等價於全局光照,甚至一系列牛逼的特效例如焦散,雲霧,次表面散射,基於物理著色。其實光線追蹤單純就是指的計算出三維空間中一個給定射線和一群三角形中的焦點的過程。這是一個邏輯上非常簡單的操作。基於這個操作,我們可以衍生出許多全局光照的演算法。為什麼這個操作如此有用的本質原因是因為渲染方程
L_{o}=L_{e}+int_{}^{} L_{i}(l)f(l, v)cos	heta _{l}dl
是一個表面法線周圍半球上的積分。這個半球方向上的東西無論是光源還是各種奇怪形狀,材質的其他東西都會對這個表面上的顏色有影響。在不知道這個半球方向範圍內有什麼辦法的情況下,發射光線去對周圍採樣是最通用,但是很低效的方法,如下圖。但是光線追蹤本身除了用來採樣場景也可以用在碰撞檢測,尋路等和渲染無關的地方。

誤點2:認為有了光線追蹤遊戲畫面就電影化了,並認為基於光柵化的方法就是做不好光照計算,需要被推翻。這簡直是忽視了過去20年圖形學界和遊戲開發者們所積累的各種技術,技巧和優化。我先舉兩個例子。下面的圖片是用虛幻引擎4製作的建築可視化(視頻:UNREAL PARIS)。對於這種靜態場景來說,光照貼圖(Light Map)就一下把最難搞的漫反射部分通過預計算搞定了,運行時沒任何overhead。UE4用Photon Mapping算Light Map,這是個一致(如何理解 (un)biased render? - 文刀秋二的回答)的全局光照演算法,也就是說最後的結果加上SSR和Probes做鏡面部分的話和你離線渲染結果就基本沒有什麼差別了,小場景60Fps跑起來無壓力。開口就要顛覆光柵的,打臉啪啪啪。

另一個例子是Unreal的風箏demo(視頻

另一個例子是Unreal的風箏demo(視頻Unreal Engine 4 Kite Demo)。它使用的地形是Epic在紐西蘭實地掃描的,目標大概是要創造Pixar類型的電影化體驗。這個Demo我不能說他有上面那個那麼精確的光照計算。雖然用了些基於Signed Distance Field的Ray Traced Shadow,但是也只是陰影,而且精度和傳統的ray tracing也有差別。但我會告訴你這個Demo我用兩個980+64G內存+1TB SSD+12 Core CPU跑起來都不能60Fps么,任務管理器是各種爆滿的。

所以我想說的是,視覺上看到的無偏全局光照是體驗的重要部分,但是基於光柵化的程序也能在一些特定情況下提供這種體驗,並且光照並不是和電影唯一的差距。電影和遊戲的可用資源的巨大差距和兩種媒介體驗的本質差距等綜合因素都是遊戲畫面電影化的障礙!資源的差距包括一幀畫面計算的時間資源(1/60秒和數小時),計算資源(普通CPU+GPU和一個渲染農場),美術素材資源(幾十萬個三角形和過分細分到比像素還多的三角形)還有物理模擬的精度等等。體驗的本質差別則是電影的是線性的。導演,特效師只需要保證所有的畫面在一個角度,一個時間達到完美即可。而遊戲則是可互動式的方式。所以光線追蹤真不是最終的救命稻草。實時程序就是一個要把及其珍貴的時間和軟硬體資源合理的分配到不同的因素里去。

所以我想說的是,視覺上看到的無偏全局光照是體驗的重要部分,但是基於光柵化的程序也能在一些特定情況下提供這種體驗,並且光照並不是和電影唯一的差距。電影和遊戲的可用資源的巨大差距和兩種媒介體驗的本質差距等綜合因素都是遊戲畫面電影化的障礙!資源的差距包括一幀畫面計算的時間資源(1/60秒和數小時),計算資源(普通CPU+GPU和一個渲染農場),美術素材資源(幾十萬個三角形和過分細分到比像素還多的三角形)還有物理模擬的精度等等。體驗的本質差別則是電影的是線性的。導演,特效師只需要保證所有的畫面在一個角度,一個時間達到完美即可。而遊戲則是可互動式的方式。所以光線追蹤真不是最終的救命稻草。實時程序就是一個要把及其珍貴的時間和軟硬體資源合理的分配到不同的因素里去。

當然我不是保守派,光線追蹤作為一個最基本的採樣場景的操作來說,通用且直觀,如果性能跟的上,必然會帶來許多渲染技術的發展。但是高效的實現難度就是很大,前面許多回答也都多少分析了些原因,我就總結和補充一下。
難點1:計算量大。如果拿一個4K解析度的遊戲要做全局光照演算法,例如路徑追蹤,假設每個像素要1000個樣本噪點才收斂(這是非常非常保守的數字),每個樣本的路徑長度是5次反射(也是非常短的路徑),那就需要3840 * 2160 * 1000 * 5 = 41472000000根光線。再假設一秒60幀的刷新率,41472000000 * 60 = 2488320000000。也就是說一秒鐘要射出2500G跟光線,這個數字大概目前最快的渲染器也慢了至少一萬倍。諷刺的是對於電影級的畫質來說求交的過程和著色相比只是非常小的一部分。離線渲染的最前沿的研究我也了解且實現過不少,有許多提高採樣效率的方法。但是無論怎麼提高,在這一萬倍面前都是捉襟見肘。所以除非有高效且robust的filter和reconstruction的方法,拼樣本數量的做法在實時應用里真的沒什麼希望。要怪就怪1/60秒的要求是在太苛刻。但我不想顯得過分悲觀,上面10000倍的差距也只是真正要做一個無偏路徑追蹤的需求,實際上就算是離線渲染也有許多trick能減少noise,biased去加快收斂速度,所以如果真的應用到遊戲里肯定能用一些其他biased方法去cheat away這麼大的計算量。
難點2:現代GPU已經將基於光柵的管線性能優化的將近極致了,榨乾了最後的性能,一方面是光柵化演算法的確相比於光線追蹤更容易被集成進硬體,三角形可以在不同管線階段Stream,另一方面光柵化大規模流行了20年,廠商已經有太多的時間和經驗積累經得起考驗的優化。於此同時,基於光柵的渲染演算法也有無數的trick和hack能去騙你的眼睛,讓畫面看起來也非常牛逼。基於光線追蹤的演算法在可交互應用可以說要從頭髮展,當然肯定有新的東西可以搞,只不過也真的需要人來做這個工作。
難點3:現代基於光柵的圖形管線已經烙印到GPU里,介面暴露在API里,大量現成的演算法實現在遊戲引擎里和遊戲開發者的腦子裡。所以光線追蹤的加入意味著圖形管線的改變,新programming model,所以我認為就算性能跟上之後,光線追蹤的普及也會是個緩慢逐漸的過程,並且需要整個industry的一起努力。

最後我想說我不同意光線追蹤沒有需求這個觀點。需求是自己創造的。要麼被自己淘汰,要麼被別人淘汰。


原理什麼的樓上已經說了很多了。單獨說計算量其實沒什麼可怕的。但是除了計算量之外,還有別的原因:

和基於濾波的光柵化相比(當然實際上也不完全是這樣,具體見評論),完全靠採樣的光線追蹤的雜訊是一個比較麻煩的問題。為了降低雜訊,需要付出平方級別的採樣成本。
此外,光柵化演算法中,幾何數量、屏幕解析度都與計算量有著近乎線性穩定關係;相比之下場景複雜度對於光線追蹤有著不可預期的影響;
最後,如果使用有偏估計來加速圖像生成,因為是有偏的,所以細微的變化都會早成比較嚴重的色差。幀與幀之間的差異性會造成嚴重的幀間抖動。這樣你看起來就屏幕就不停的閃爍。
電影上你看到的那些美輪美奐的畫面,是付出了無數後期製作成本才有的。

所以綜合考慮光線追蹤的這些特點,恰好和遊戲需要的幀間連續性和場景複雜度可預計性是相悖的,要糾正他們需要付出很高的計算的代價,所以我不認為RT會成為遊戲成像的主流。不過作為一些視覺效果的計算,特別是全局光照之類需要物體間交互的演算法,RT或者其變種(例如Cone Tracing)已經登上了3D的舞台。


這是一個十分難於全面回答的問題。


我的背景:並行計算,圖形學經驗限於傳統的光柵化渲染,參與編寫過一個小型的圖形引擎以及一個體繪製引擎,寫過一個十分簡單的基於CPU的ray tracer作為課程項目,在線上過Stanford的CS348B渲染課程,零零散散的使用pbrt實現了課上要求的若干作業。所以我對圖形學和光線追蹤有所了解,但相比知乎里的諸多圖形學程序員,涉獵的還很有限,這裡的答案多數來自自己的理論分析及和一些實驗室同學及其他同行的討論。這題已經有很多好的答案了,我想盡量不和已有的內容重複,請各位多指教。

(相當嚴格的)定義:首先來定義實時光線追蹤。我認為一個嚴格的定義如下:使用基於光線追蹤的演算法(包括ray tracing, path tracing, photon mapping, beam tracing, cone tracing等等 )進行圖形渲染。渲染對象是包含真實剛體及柔體物理模擬的動態場景。場景解析度需達到720P(1280x720),並需要允許動態攝像機以及多光源(點/面光源)。渲染幀率需不低於30並以60為目標,渲染結果應該有較小的(肉眼難於分辨的)噪點。如果是path tracing等蒙特卡洛方法,則還需要無偏的結果(不然會出現局部模糊等artifacts)。

應用:目前的應用包括:各類照片級渲染應用中場景設計的快速原型生成,視頻遊戲中的部分場景渲染。未來的應用領域會更加廣闊。


難點:@lgthetyro 的答案對光線追蹤演算法有很好的描述。因為光線的傳播是方向可以互易的物理過程,於是從屏幕像素髮射光線到場景,在相交測試結束後根據光源和物體本身的材質屬性來計算像素顏色改變,同時生成供下一輪計算的新的光線(根據物體的屬性可以產生額外的光線或改變當前光線的屬性)。可以看到這是一個迭代收斂的過程。那麼僅從光線角度看,計算量有多大呢?以30幀的幀率,720P的解析度(約一百萬像素)來計算,每秒需要計算三千萬條光線和場景的相交檢測及光照計算。而這樣一個像素對應一條光線(之後用ray per pixel RPP來代替)的方法僅僅能渲染出硬陰影和一層反射折射,多層反射折射需要4-12RPP,軟陰影需要10-20RPP,Path Tracing需要500以上的RPP,Ambient Occlusion需要100左右的RPP。如果從場景複雜度來計算,對每幀場景的渲染不僅要考慮每條光線的遍歷,同時也要考慮每個三角面片的遍歷,對場景遍歷進行相交檢測可以通過一些層級結構來進行(最普遍認為的高效數據結構是Bounding volume hierarchy)。實時的光線追蹤的難點就在於場景複雜度和需要的真實感渲染效果決定了遍歷和相交檢測的巨大計算量(場景分割數據結構的重構和光線與場景的相交測試是兩項主要計算)。這是渲染領域以及任何模擬計算領域裡終極的矛盾:效率和質量的矛盾。

解決方案:和其他圖形學演算法一樣,如果要應用在實時類應用中,效率是關鍵。目前的解決方案有兩個方向的努力:1)軟體角度。2)硬體角度。我個人沒有實現過任何這類演算法,所以不能談細節,下面是high-level的描述。
軟體角度又可以分為自低向上和自頂向下的優化:BVH和其他層級結構的場景分割(kd-tree, oc-tree, BSP-tree等)是自頂向下的方法,在對場景進行分割時還有一項十分常用的優化演算法:Surface Area Heuristic (SAH)。其基本思想是在將場景分割為兩部分時(這是BVH, kd-tree以及BSP-tree的基本場景分割操作),考慮分割後遍歷及計算相交檢測的總cost函數最小。而光線擊中一個包圍盒(Bounding Volume)的概率和其表面積相關(SAH將其進一步簡化為線性相關),所以採用二分法尋找cost最優的分割平面會給其後的計算帶來效率的提升。
自底向上的優化則包括packet tracing和ray reordering。Packet tracing的思路是將方向接近的一組光線打包,同時進行相交檢測,這樣在檢測中可以利用空間相關性,同時對一組光線也只需要調用一次BVH。Ray reordering是說在每個packet相交檢測結束後重新將方向接近的光線reorder到一個packet中,從而保持coherence的特性。
硬體角度的優化又可以分為採用GPU和SIMD的優化以及專門的ray tracing硬體。前者就是對上述軟體優化的演算法進行針對GPU或SIMD的優化,同時一些並行環境下的數學庫函數和其他基本演算法如排序等也間接起到了加速的作用。後者就是指將ray tracing中獨有的相交檢測,場景分割等部分採用專門的硬體來優化,比如剛剛推出的PowerVR GR6500(圖片來自:AnandTech | Imagination Announces PowerVR Wizard GPU Family: Rogue Learns Ray Tracing):

對於其他知友提到的很多ray tracer,都或多或少採用了以上的優化方法。
次世代主機遊戲中的光線追蹤一般都有很多對場景、光源、以及效果的限制,還有很多其他的hack和加速方法,我無法一一了解並描述。 歡迎各位補充。

對於其他知友提到的很多ray tracer,都或多或少採用了以上的優化方法。
次世代主機遊戲中的光線追蹤一般都有很多對場景、光源、以及效果的限制,還有很多其他的hack和加速方法,我無法一一了解並描述。 歡迎各位補充。

總結:種種跡象表明,光線追蹤的效率會隨著圖形硬體的發展而進一步提高。嚴格的實時光線追蹤實現起來十分困難,但對場景,光源和渲染演算法有限制條件的情況下,實時光線追蹤已經在視頻遊戲和一些其他應用中實現,並還會有更好的應用。一個更廣義的問題是,如何解決計算效率和計算質量(精度)的矛盾?或許我們永遠不會同時需要這兩者?


實時光線追蹤還是光線追蹤的一種拓展,實時光線追蹤還是初級階段啦,基本上unreal4的cone tracing或者是屏幕空間的反射追蹤應該屬於這種,當然準確度比較差,而且unreal4就是因為svo cone tracing太耗了就刪減掉了。接下來可能的研究方向還是在利用GPGPU跳過光柵化流水線的邏輯吧,但是gpu的這種架構想做並行光線追逐還挺難的,畢竟不能利用局部一致性了從而加大了代碼預測和執行效率優化的可能性。這要是成熟,沒個五年不行


=============這部分是相關討論,提問回答在最後=============

@孟德爾 君的回答前面還比較靠譜,而後面說

光線追蹤現在還在很初級的階段,連電影業都沒廣泛應用,皮克斯直到汽車總動員才開始大規模使用光線追蹤,而且還是部分應用。

以及

或許10年後再看,光線追蹤只是一個歷史的笑話也說不定。

就顯得有些主觀臆測了。


說 "光線追蹤現在還在很初級的階段" 我無法認同。

什麼是光線追蹤演算法

基本光線追蹤演算法

(上圖來自wikipedia)

(上圖來自wikipedia)

1. 對於每個像素,由攝像機向場景中發射一條光線。

2. 對於每條光線,一直追蹤到它碰到某物體表面。

3. 對於每個與表面相交的點,向光源發出一條影子探測光線,來查看是否每個光源都可見,並依此來對該像素點著色。

4. 如果相交的表面材質是漫反射的就停止。如果表面材質是反光/折射的,則根據物理中反射或折射原理計算得出反射/折射方向並發射一條新的光線。

5. 重複1到4,直到達到最大追蹤深度或者光線碰到光源或者漫反射表面。


光線追蹤演算法的優勢:

1. 具有物理準確性,可以達到相片級渲染,尤其擅長強反射(金屬等)和折射材質(玻璃、液體等),焦散( caustics )現象、復反射( interreflection ) 等可以模擬得很逼真,還有影子。

2. 演算法簡單易實現


光線追蹤演算法的劣勢:

計算代價很高,就是慢


光線追蹤歷史:

將光線追蹤演算法應用於圖片渲染最初是由Arthur Appel於1968年提出,那時還叫ray casting。1979年Turner Whitted帶來了新的研究突破(Recursive Ray Tracing Algorithm)。1984年, Carpenter等人發表了一篇分散式光線追蹤的論文(Distributed Ray Tracing),影響甚廣。發展到今天,大多數的相片級渲染系統都是基於光線追蹤演算法的。基本的光線追蹤演算法並不難,相信大部分計算機圖形學的同學都寫過的,難的是如何優化提高效率。


皮克斯的RenderMan和光線追蹤

說到皮克斯直到《汽車總動員》才開始大規模使用光線追蹤。皮克斯的《汽車總動員》於2006年6月在美國上映,今年已經是2014年了,已經快8年過去了,滄海桑田吶同學們。

皮克斯一直使用的是自家開發的渲染器RenderMan,基於REYES(Renders Everything You Ever Saw&<--有點雷= =) 。REYES是另一種渲染演算法,它對於處理複雜場景非常高效。1984年的時候皮克斯有考慮過光線追蹤,但最終還是堅持使用REYES。那篇關於《汽車總動員》的論文(Ray Tracing for the Movie 『Cars』)我有瀏覽過,裡面提到五年前(也就是大約2000年左右)他們就啟動了添加ray tracing功能到RenderMan的這個項目,同期《汽車總動員》正在製作中,文中也提到了《汽車總動員》使用光線追蹤的動機:realistic reflections, sharp shadows, and ambient occlusion。REYES在處理反射強烈的汽車表面材質方面有些捉襟見肘,只能用environment map,仍然達不到光滑閃耀的質感。而這正是光線追蹤擅長的。


使用光線追蹤的主流渲染器

RenderMan就不說了,它本是基於REYES的,現在也有ray tracing的選項。眾多工作室都在用。

(以下是純基於光線追蹤的渲染器)

Mental ray,NVIDIA出品,已經集成到3D建模軟體Autodesk 家的Maya和3ds Max中。

Arnold近些年漸攬風騷,Sony Pictures Imageworks,Digital Domain, ILM, Luma Pictures等著名特效公司均有使用該渲染器。

VRay,比Arnold大眾一點,近幾年也在瘋長,它目前有CPU版本和GPU版本(V-Ray 和 V-Ray RT GPU)。


光線追蹤演算法在目前的影視特效領域佔有重要的地位。我不認為光線追蹤會成為"一個笑話"。2013年的SIGGRAPH有關於光線追蹤的講座(Ray Tracing is the Future and Ever Will Be),可以參考。


硬要說的話,「光線追蹤演算法在電子遊戲領域的應用還在初級階段」還比較靠譜。

光線追蹤目前多用於影視特效中做靜幀渲染。若想要應用到遊戲中就需要做到實時渲染,就是提問中說的實時光線追蹤(Real-time ray tracing)。


======================回答問題的分割線======================

最後回答問題:什麼是實時光線追蹤技術?它可能出現在當前的次世代主機上嗎?

什麼是實時光線追蹤技術?

光線追蹤(Ray tracing)演算法前面說過了,那什麼樣的是實時的呢?6 fps左右就可以產生交互感,15 fps 可稱得上實時,30fps不太卡,60 fps感覺平滑流暢,72 fps再往上肉眼就已經分辨不出差別。


它可能出現在當前的次世代主機上嗎?

全面應用在當前看起來是不太行,在將來應該會有。

你要CPU跑實時的光線追蹤似乎是有點為難它了,在GPU上實現實時光線追蹤相對容易一些,原因 @楊三 的回答里基本說了。GPU的優勢就是核多,大量並行計算。而恰巧光線追蹤就是個特別平行的體力活,每條光線都相互獨立,所以可以並行地計算它們。能夠加速的地方有碰撞檢測,可以使用kd-tree或oct-tree之類。2009年SIGGRAPH 會議上, Nvidia 就發布了OptiX,Nvidia GPUs實時光線追蹤的API 。

另外,NVIDIA目前已經有virtual GPU技術,類似於雲計算,不需要本地的GPU。如果virtual GPU可以應用到主機上,實現實時的光線追蹤應該沒有問題。


最最最後, Phil Spencer原tweet說的是:

「@7kayhan@albertpenello We』ve done experiments with Realtime Raytracing. A ton of potential with this tech, amazing visuals.」

他只是說做了相關實驗,卻被Gamespot完全改編成了另一種說法: Xbox One could get photorealistic rendering system for "amazing visuals"。提問中的那篇文章看上去像是根據Gamespot這篇報道來的。


參考資料

[1] Matt Pharr and Greg Humphreys. Physically Based Rendering, Second edition

[2] Tomas Akenine-Moller, Eric Haines and Naty Hoffman. Real-time Rendering, Third edition

[3] Wikipedia


實時光線追蹤技術是未來的趨勢,不論是 NVIDIA 還是 微軟 都在往這個方向靠。
不能說太多,說太多要暴露了。

另外有個哥們提到「光線追蹤現在還在很初級的階段,連電影業都沒廣泛應用」。看到這裡我的世界觀都奔潰了。
看了這個鏈接我覺得需要感謝這個哥們,讓我漲了知識!Pixar Uses Real Raytracing for First Time in Monster"s University

利益相關:NVIDIA 員工,微軟粉絲。工作中需要搞 OpenGL / DirectX,也研究過簡單的基於純 CPU 以及 基於純 GPU 的光線渲染器。


光線追蹤本質上是一個不太適合(現代GPU的)並行計算模型的操作,因為每條光線的分支和收斂速度是不一樣的??現代GPU基本是SIMD結構,SIMD結構適合那種所有數據做相同操作的「團體操」模型。

現在基於GPU的光線追蹤器比基於CPU的性能要好,很大程度上是佔了GPU核多的便宜,如果觀察每個核的利用率,GPU版本還是很低的。這好比一個一萬人的工廠,每個工人每天只上倆鐘頭班,還是比一個一千人的工廠滿負荷運行產出率高。

as a matter of fact,傳統GPU廠商比如N家和A家,在這方面的歷史包袱反而比傳統的CPU廠商要大,因為GPU有史以來就是SIMD模型機器。而對CPU來說,做多核反而在架構上來得容易些。當然,要實現「實時」的光線追蹤,核的數量需要多到一定程度,cache一致性、調度協同等等問題又會冒出來,所以真的是no silver bullet。

所以要實時光線追蹤能夠進入家用領域,GPU架構需要很(tui)大(dao)改(chong)進(lai),降低線程調度的粒度。但這樣一來會增加控制單元,降低運算單元的密度。中間如何取捨,還是要看市場需求和數據支持說話。


從物體發射的光最後到達攝像機,攝像機才能成像。由於光線是可逆的,我們可以i從攝像機發射射線來於場景中的物體相交,就可以知道這個射線最後成像後的顏色。如果有反射和折射,那麼這根光線就繼續從這個相交的點開始繼續射下去。直到他對顏色的貢獻小於某一個閾值或者計算時間超過了限定等。

光線追蹤可以獲得非常真實的渲染效果,尤其是在光影還有環境漫反射方面。

如果光線追蹤能夠達到每秒渲染30幀,30fps那麼我們就可以說它是實時的。現在的高端顯卡可以做到10幾20幀。簡單的場景30幀也可以的。

光線追蹤的主要技術難點有兩個,
一是怎樣快速的找到與射線相交的物體,這個在cpu上有不錯的演算法,因為cpu有大cache, 和高度優化的邏輯指令,但是cpu核太少,一次算不了幾根射線。用gpu一次可以算幾百幾千根射線,但是cache小,邏輯指令相對較慢,需要特別設計的演算法。

第二個問題是怎樣快速的收斂。因為光線是反射來反射去的。一般的方法光線跳幾次,你就得算幾遍,這個是很費時間的。一副720p就至少80多萬條射線,現在的gpu也就幾百個核,算一次也得跑幾百次,這還是一次反射,然後再多幾次反射後時間就花得差不多了。除非有特別好的演算法,否則這個是現在實時化的主要瓶頸。

題主的那個視頻是NVIDIA的raycast demo, 只是很簡單的場景,所以以現在的gpu做到實時毫無壓力。應用到遊戲中的複雜場景就不一樣了。

Xbox One也主要看計算量怎麼在cpu和gpu直接分配,看微軟有沒有逆天的演算法。否則離替代光柵化還有一定距離。


我假設你問的其實是ray tracing是什麼,因為我想如果知道ray tracing,那麼實時ray tracing就不是問題了。

ray tracing是一種渲染(成像)技術,基本原理是從相機向空間做射線,根據射線與空間物體的交錯點的幾何屬性(位置)、物理屬性(材質),和空間中光源的性質,最後計算出該點的顏色值。是目前很多數字電影后面的渲染引擎(如pixar的Renderman)用的技術(現在的這些引擎,會雜很多的技術在裡面,如photo mapping)。

這種技術能做出相片級的渲染,但是每一幀畫面耗時非常的多。為了得到一個像素的值,可能會在場景里產生大量的射線,譬如,每個像素可能衍生出了1000、甚至是10000根射線。在ray tracing中,大量的碰撞就是ray和物體的碰撞檢測。

但是,這並不是ray tracing不能實時的理由。國外有文章提到過(早期看的,找不到來源了),軟體光柵化的方法寫出的3D渲染器和用ray tracing方法渲染器同時來計算出一幅畫面的話,可能差距不是很大。現在的3D引擎是實時的,是因為GPU(光柵化技術)渲染的能力能實時吞吐。對於ray tracing來說,沒有相對應的專門的硬體(肯定有本身演算法導致硬體不是那麼好弄),才使它不能「實時」。

當然,現在有用GPU來進行ray tracing的,如英偉達(Nvidia的):

NVIDIA OptiX Ray Tracing Engine

和Power VR(手機里GPU的一家供應商)的

PowerVR OpenRL Ray Tracing

但是,它們這些GPU還應該只是利用GPU來幫助ray tracing。

所以,第二個問題答案也就是,有了相應的xPU就可以實時。未來我想有是肯定的。

另外:
推特我沒有看,但是GPU界的幾個老大現在就到這樣,微軟估計肯定不會比他們還牛逼,但是世事難料,也許半路殺出個黑馬來,但我不信是微軟了, :)


後補:

正好看到一篇中文文章,翻譯的fxguide的,這篇文章涵蓋大量的信息,供後來者參考。

渲染藝術之渲染器與渲染流程


光線追蹤簡單說來是在3d場景中發射一條光線,然後模擬這條光線的碰撞,能量變化等等光學及物理學上的各種行為,之所以說它好是因為一定程度上達到了用計算機模擬現實。而反觀現在的遊戲渲染手段,幾乎很多都是建立在「我們看起來像真的」。比如景深特效,遊戲中一直都是通過「模糊預定範圍的圖像」來實現,而現實中一定是因為進入到照相機鏡頭的光線因為焦距等原因發生了偏移。你可以簡單想像這其中的性能差距。
現在的硬體上做到實時幾乎是不可能的。簡單的說只要那張顯卡還是我們都認識的東西,主機上就無法完成實時光線追蹤,我們還沒有針對實時RT的硬體設備。未來有可能,opengpu上面有顯卡工程師說硬體上已經有能緩存光線和幾何體信息的原件,成本問題目前還不可能大規模推向市場。


光線追蹤就是根據一個點,推算使這點發光的多束光路,從而渲染像素點。光線追逐是一個非常消耗資源的項目,如1L所說,皮克斯在Cars中少量引進了該技術,但是據說該部分消耗的渲染時間是恐怖級別的(因為皮克斯的渲染農場是針對傳統渲染程序設計的)。即便是NVIDIA,在4系卡上也只是借用開普勒核心首次講「入門」級別的光線追蹤引進到家用卡上、但是根據專業機構的評測,4系卡只能做到10fps以內的少量低解析度的渲染,明顯不夠用,即便是升級了的6系,恐怕也不能達到基本的30fps吧。

家用主機的話,硬體性能統統在PC之下,也就是說…下代你都見不到的!


我見過的目前最快的實時光線跟蹤渲染器是FurryBall,這個軟體有maya和max的插件,也有獨立的軟體,依靠顯卡GPU,並且支持毛髮,流體,次表面散射實時渲染,效果很驚人!而且對於反射,折射,環境光遮,次表面散射等都可以單獨在光線追蹤演算法和光柵化二者間直接切換。不過目前AAAStudio對FurryBall的更新比較頻繁,還不是很穩定,而且奇貴無比還沒破解……(附:FurryBall官網:FurryBall - Real-time GPU render和介紹視頻:FurryBall 4.5。FurryBall 4 - New Features .mp4 視頻


實時光影一直都是一個夢想,但是它太過於消耗資源,除非演算法上有很大的突破,否則現階段的遊戲主機還是吃不住


次時代主機的顯卡只相當於中端台式機顯卡(記得某次時代主機直接用AMD A10 6800K)。所以不可能大規模用實時光線追蹤吧。
我猜你可能是把屏幕空間的一些技術當成那個了。現在有一些屏幕空間的光線效果,看起來很真。但至少就我所知,屏幕空間的光線追蹤還是處於比較初始的階段,而且有一些很顯著的技術障礙,因為沒法解決信息缺失的毛病。


具體ray tracing的知識大家都有回答了,簡單談談個人感受。

一句話概括,ray tracing更符合實際物理,所以更真實。

當時做的最simple的raytracing的project,用的phong illumination的遞歸演算法去渲染一個球,隨著光線層次的增加,明顯感覺到機器的計算能力不夠用。更別提實時渲染了。

現在在做powervr的公司上班(本人在做cpu,和computer graphics完全沒關係- -)前兩天ceo在公司會上說realtime raytracing貌似和微軟合作取得了突破性進展,不過本人高度懷疑這個「突破性」。- -。因為真的可能需要推倒現有gpu架構完全重來。

隨著ASIC的發展,realtime ray tracing一定是可以實現的。那種真實的場景體驗是能夠碾壓現在任何遊戲的。到時候真的是virtual reality,刀劍神域神馬的簡直酸爽。


PS4上的殺戮地帶4號稱用了,你可以去看看,不過我看那個只是一定程度應用這個技術,和影視級別的差距還是很大,說到底,噱頭而已


我這個人比較蛋疼,恰好知道一些偏門的知識…
幾位高人真的覺得現在不可能嘛?真的嘛?真的嘛?
話,不要說的太滿…(我真心覺得應該開一門電腦遊戲史的課程

如果只是從【滿足遊戲效果】的角度來說,這個技術已經應用於至少一款遊戲之上(這句話並不嚴謹,讀到下面就明白了),並且從遊戲配置來說,目前家用遊戲機的性能理論上是可以運行的
更重要的——
那是2004年,整整11年前。
下面有請:

Quake 3 Aerna Demo: Ray traced

2004年,薩爾布呂肯大學(Saarland University)的Daniel Pohl和他的同學,利用OpenRT-API,在Quake 3 Aerna Demo的基礎上完成了遊戲開發,實現了實時光線追蹤的遊戲引擎(原文realtime 3d raytrace engine),並且實現了移動、射擊、跳躍、碰撞檢測等基礎功能。
看圖咯



(以上圖片來自

(以上圖片來自Quake 3: Ray Traced,相關資料也可在此閱讀)

當然,最初,正像上面幾位專家所認為的那樣,效率太低根本沒法玩。原作者推斷按照最初的設計,在36 GHz(沒寫錯,是36,不是3.6) 的CPU上能實現20fps@512x512 w/ 4xFSAA。他最初在實驗中使用的是分散式渲染。

---------------------------分割線------------------------

有人要說了,這沒法玩吧?

我還沒說完呢。
讀下去。
巨頭Intel伸出了橄欖枝。他加入Intel成為了全職的工程師。有了Intel的強力支持,他又做了下面的事情。他繼續將手伸向了id公司的其他遊戲(quake3的引擎想必給他留下了深刻印象),2006年他對Quake 4下手了(我還沒太整明白這到底是入職Intel之前就啟動的項目還是之後)。

水面的起伏倒影是光線追蹤的結果(這是Q3的model沒錯,但作者確實說了這是Q4: Raytrace)

水面的起伏倒影是光線追蹤的結果(這是Q3的model沒錯,但作者確實說了這是Q4: Raytrace)

雖然審美上不怎麼樣,但這個鏡面反射是實打實的光線追蹤。

雖然審美上不怎麼樣,但這個鏡面反射是實打實的光線追蹤。

2006年在Intel的 "Core 2 Extreme QX6700" 上, 256x256 解析度的Quake 4 地圖 "Over the Edge (Q4DM7)",實現了16.9fps
下面是單、雙、四核的表現


看到這裡是不是有人又要罵了,256x256的解析度怎麼玩啊!
慢著,還沒完啊…
急啥!

-----------------------分割線-----------------------

正如作者在Q3時代估計的那樣,(他設計的引擎的)光線追蹤的實現直接有賴於CPU的強力程度。所以咧?等強力的CPU出現!

這哥們在2008年對Quake Wars下手。
同年實現了四顆Tigerton 四核CPU(4x4=16核心,超頻)上15 - 20 fps @1280x720的幀率
同年在Caneland平台上使用四顆6核CPU實現了25~30fps@1280x720的幀率。
2009年在 (500+ 怪物, 3D 水面)雙CPU Nehalem平台 (2x4=8核心,頻率3.2 GHz a,實現了約15 - 20 fps @1280x720.

這是利用bump map的水面:

而這是利用光線追蹤的水面

而這是利用光線追蹤的水面

(源,Intel官網:

(源,Intel官網:Quake Wars* Gets Ray Traced)

還有,2010年他開始在Wolfenstein中實現Raytrace

到了2011年。
Intel發話了

We are demonstrating this on the Lenovo S10-3t (10 inch) and on the
Viliv S5 UMPC (5 inch). Due to the lower screen resolution a cloud setup
with one machine with one Knights Ferry per client is enough to feed
the tablet at a frame rate of 20-30 fps.(粗體是我加的)

他們使用如下的一台伺服器,實現了針對較低解析度(laptop的解析度超過1024x768)設備的20-30fps的流媒體推送:

  • Motherboard: Intel? DX58SO (code name Smackover)
  • CPU: Intel? Core? i7-980X processor (6 cores, 2 threads per core, 3.33 GHz)
  • Intel code name Knights Ferry PCIe card (32 cores, 4 threads per core)
  • Gigabit Ethernet

(源:Tracing Rays Through the Cloud)

這裡有兩點要強調的,即intel也認識到未來雲計算是實現高性能計算的保障,所以他們這個研究的主要方向是雲計算與流媒體;其次,這次雖然是流媒體推送,但參與運算的只是【一台】伺服器,而不是伺服器集群。

所以說,我們可以認為這一台機器實現了較低(但可接受)解析度下的遊戲,在2011年。
那麼,現在的2015年,又會如何呢?
問題是小哥2013年就停更了…不知道後來如何~

——啊,當然,特效都關了。可能有人鳴不平,說特效關了玩個毛。但有沒有想過,為什麼遊戲敢duangduang的加特技?因為這些特效沒有光線追蹤那麼吃資源啊,這本身是一種偷懶的近似啊,是一種掩蓋啊。全加上了,怎麼看raytrace的效果(而且估計還是有點吃力)


路漫漫其修遠兮,但世界上已經有很多人走在了前面。而且確實弄出來東西了。

啊,最後來認識下這位小哥


----------------------分割線--------------------

話說Intel在2007年搞的這又是個啥?
是個靜態場景實現了90fps@1280x720?


如果你只是想看看樣子,PS4的新遊戲已經用上了,如果是大規模應用,請等下代主機。

我是技術盲,只說一下大致的印象。

其實你不需要知道光線追蹤是什麼,因為實際上你也不知道現在採用的光柵化3D技術的原理,對吧?光線追蹤的原理很好理解,屏幕上的每個像素都發出一束光去射擊3D物體,遇到物體表面就把相關的信息疊加到光上。反倒是現在的光柵化技術很抽象,你可以認為是先把3D物體拍成一張照片,然後對這張照片上色,由於針對的不是3D物體本身,所以會發生很多奇怪的現象,這也是傳統3D技術畫面不真實的原因所在。

兩者之間的關係類似於飛機和汽車,部分硬體能通用(發動機),但是因為運行原理完全不同,因此對硬體的需求重點也不同(比如,汽車發動機要求高扭矩,而飛機沒有需求)。如果光線追蹤發展到很成熟的階段,就連部分硬體都不通用了(類似螺旋槳飛機進化到噴氣式飛機)。

現在的3D顯卡雖然已經普及了統一渲染構架,比原先的通用性高多了,但是仍然是一種特化硬體,如果在現在的顯卡上走光線追蹤,對CPU的依賴會非常大,這與顯卡包攬一切的趨勢是向背的。

目前實驗階段的光線追蹤硬體都是FPGA,可以看成是一個功能沒有被限制在光柵化,可以自由定製的原始顯卡,要將其改為自由度很低的定製顯卡才能提高光線追蹤的效率。自然,真正的光線追蹤顯卡對過去所有的3D遊戲都是不兼容的,這才是問題的關鍵。

以現在的技術,生產出一種高效的光線追蹤顯卡並不難,而且價格不會很高(現在光線追蹤的低效都是因為沒有使用專用硬體造成的),所以無法推廣的唯一因素就是光線追蹤技術根本沒有需求。

3D顯卡推廣花了差不多10年吧,那時候沒有的人就是沒的用,而現在3D顯卡的功能都已經與操作系統結合起來了,不可能統一換新。過去CPU的64位與32位之爭,最後以兼容32位收場,因此黃老闆他們也是走這條路。DX現在增加的雙精度浮點運算等功能,都是為了在老式顯卡上運行部分光線追蹤程序而準備的。以後的顯卡可能會徹底改變結構(就像顯卡進化到硬體TL還有統一渲染構架),同時支持光柵化和光線追蹤。也可能在保留現有構架的前提下,增加一個專門負責光線追蹤的特效模塊,比如集成Caustic的RPU顯卡。

微軟所說的也是這種,可能只在水體反射之類的特效上使用,但是畫面整體水平不會有飛躍,要知道現在大部分遊戲連場景光照都是預渲染的,老技術還沒普及,怎麼可能跨代呢。

遊戲廠商要部分引入光線追蹤的難度不是很大,因為現在工作量最大的三維建模和貼圖都可以沿用到下來。但是要徹底換用光線追蹤,是否還會使用多邊形技術就很難說了,或許真的要過渡到曲面?

光線追蹤的發展還在很初級的階段,現在的好萊塢電影CG主要還是依靠光柵化渲染的,光線追蹤只是輔助手段。皮克斯直到汽車總動員才開始大規模使用光線追蹤,而且還是部分應用。

多說一句,雖然光線追蹤技術是熱點,但是並不意味著它就一定是未來。遊戲的生命就是實時性,所有低效的技術,無論效果多麼好,哪怕不可替代,都註定會死亡。歷史上曾經被看好的3D圖形技術,10個中有9個都死了。90年代和多邊形技術同時興起的還有一種橢圓球體技術(ellipsoid),曾經被寄予厚望,但現在搞計算機圖形學的人都沒幾個聽說過它。

或許10年後再看,「在遊戲中全面應用光線追蹤」的想法只是一個歷史的笑話也說不定。

這就是橢圓球體技術(ellipsoid),1996年的作品,藉機緬懷一下。


不可能。

最基本的, @lgthetyro 圖中的scene object 都無法做到所有object都是有3D模型支持的非純貼圖。 很簡單的例子, 目前無法做到遠景如山脈, 天空中的雲以多邊形, 或粒子系統去支撐, 而是為了frame rate用一大整張紙片貼圖糊弄上去(遠處的山, 星空, 雲全是紙片)

場景中連全3D模型都做不到, 如何做ray tracing? 對著一張張的平面的紙片貼圖去trace嗎?


一些渲染器有「部分渲染功能」的。

不至於一秒做60個不同的蒙太奇哈?

這個主題似乎應該分成單幀的光線跟蹤和帶失真度的動畫關鍵幀間的插值估算,遊戲類的估算更多些,電影類的少些。

還有就是場景中模型的每一個片面(三角形或四邊形等)的面積在顯示面的投影的最小面積的閾值限制不用渲染更細小的片面,在模型的數據結構上設計成為多層級包容的結構,便於計算,可以在需要的精細度級別渲染而不是一直渲染到最精細;這種演算法好像很多軟體渲染器有,但是在運用GPU的渲染好像需要更多的適應。


推薦閱讀:

TAG:創業 | 家用主機遊戲 | 遊戲開發 | 計算機圖形學 | Xbox One |