為什麼影視級離線渲染會十分消耗內存，一般都需要達到32GB以上？

01-21

是場景面數太多導致，還是光線追蹤採樣點太多導致，亦或是其他？

面數太多，同時需要構建複雜的空間搜索結構。大場景一個模型就上千萬面，整體通常都是上億甚至上十億的面。

當然事實上可以用更巧妙的辦法把這個需求降下來。比如阿凡達，具體怎麼處理的可以看他們的paper：http://dl.acm.org/citation.cfm?doid=1778765.1778774，大概是在說，先用路徑追蹤烘焙一遍把每點的可見性編碼成球面調諧函數，然後正式渲染不再進行光線追蹤計算可見度，直接使用球面調諧函數的插值，然後渲染時候還有一套cache的機制。當然即便這樣依然需要很多內存，他們的cache主要是針對GPU的有限顯存的。

像上面這個表格里，給出的最大的場景有10.16億的多邊形。場景大概長這樣：

光放這個圖可能還沒概念，下面這個比較直觀：

左邊是完整的圖，畫了個小框（第二張只有7x4像素，看著就是個小點了），右邊是小框里的部分放大以後，你就看有多少細節。

這還是2009年的技術（paper是2010年發表的），現在只會更多更複雜。

現在一個shot上百TB都不會大驚小怪了，32GB算是很省的了吧。polygon的體量還算小的了，遇到volume render再大都不嫌過分。一般公司經濟能力差一點都想辦法縮減場景複雜度，某D打頭的土豪公司就是有多大硬碟用多少存儲。某魔法唱歌金曲片段耗費了18TB存儲這種事情，應該會越來越常見吧。

根據評論補充下。因為渲染的時候是需要把場景數據載入到內存里，通過構建特定的數據結構（比如BVH和KD-TREE）才能進入到渲染的那一步。場景越複雜細節越多，文件就越大，渲染時需要讀入內存的數據就越多。所以硬碟上存儲的數據量和渲染時內存的開銷基本上是呈正相關的。

Polygon還好，遇到subdivision mesh還會在硬碟存儲的數據基礎上指數增加內存開銷。因為大部分Subdivision Mesh存儲在硬碟上都還是普通的polygon，都是在運行時才進行細分。Embree和SolidAngle都做過on the fly subdivision，目的就是減少直接細分之後產生的龐大的面數據所佔用的內存。

除此以外建立BVH和ray cache之類也會耗費大量的內存。比如Embree在生成BVH的時候就有兩個選項，把geometry複製一份或者用index引用到原始數據，前者快，後者省內存。

光線追蹤的話現在有種做法是同時向場景中發射上萬條光線，這些開銷也是要計算進去的。比如Hyperion（Walt Disney Animation Studios）裡面有段提到

Hyperion handles several million light rays at a time by sorting and bundling them together according to their directions. When the rays are grouped in this way, many of the rays in a bundle hit the same object in the same region of space. This similarity of ray hits then allows us – and the computer – to optimize the calculations for the objects hit.

關於題主所說

為什麼不能夠採用內存交換的形式分次載入模型，意即我需要用到哪個模型再載入哪個模型，只是渲染的速度會慢一點，但只需很小的內存就可以滿足。

SolidAngle之前做過根據攝像機可見性動態地載入可見的場景以減少內存開銷，但也僅限於實驗。因為實際情況下，場景真的很大很複雜。計算陰影、光線反射折射之類的，沒有全部載入模型就會出現計算錯誤。別的情況還有攝像機高速移動，掃到的場景數據很廣，也會使這種方法失效。因為真的影視級渲染場景都太複雜了，這種做法也就只能停留於試驗階段。題主提到的這種情況在現實中並不成立。

歸根結底，內存開銷大還是因為場景變大變複雜了。尤其是到現在越來越多的火、煙、水之類的volume相關的特效，本身存儲在硬碟上的數據就非常龐大。渲染時要載入到內存里必然不會省了。換到當年PRman第一版，整個軟體都還是存在軟盤裡的。誰敢想像做那麼複雜的場景，自然也不會吃那麼多內存了。

計算吃力就各種cache，畢竟內存便宜點。

你說的第二種分塊渲染原理類似。