CG 製作行業的雲渲染這個行業發展如何？

12-24

這裡只說非實時的渲染。過去我也一直認為「雲渲染」只是一個美麗的概念，直到 ...

先說在上一家公司的經歷吧，當時一個動畫項目做到關鍵時刻，公司考慮內部農場節點數不夠，想和一家計算中心合作，分擔一部分渲染量。接下來在考證可行性中出現了一系列的問題。首先是數據如何傳輸。單個鏡頭的動畫緩存和貼圖數據在幾G到幾十G之間，用高速光纖（甚至硬碟拷貝）也能完成數據傳輸，只是要花一些時間。但隨之而來的問題是：製作中的數據其實是在變化的。雖然理論上來說，燈光應該在之前所有步驟結束以後才開始，但參與過實際製作的人都知道，導演永遠會對製作中的鏡頭提出修改意見。比如說燈光渲染完第一遍以後導演想修改一下某個角色的設計，即使是一個細微的調整，也需要重新輸出貼圖和緩存。那麼問題來了：怎麼保證鏡頭第二次渲染時本地被更新的數據在雲端也被更新？而且是所有被這個修改影響到的所有的鏡頭都得到更新？這也牽扯到國內CG製作中很現實的一個問題：大部分製作公司的流程不算完善，渲染時調用的數據的路徑做不到100%規範。本來你規定鏡頭調用的數據都在鏡頭文件夾內，結果有人臨時把緩存輸出到本地。那很有可能渲染需要的數據沒有被同步到雲端的伺服器上，從而造成渲染失敗。所以最後的結論是，我們無法讓燈光師像使用本地農場那樣使用雲端渲染。

直到現在的新公司中，我們採用菜譜式渲染，才真正在實踐中使得雲端渲染和本地渲染獲得了相似的靈活度和準確性。

什麼是菜譜式渲染，簡單的舉個例子。我開一間川菜館子，拿到菜譜上有三道菜：
1.魚香肉絲：配菜（蔥姜蒜，醬油調料，雞肉切絲），爆炒三分鐘
2.魚香茄子：配菜（蔥姜蒜，醬油調料，茄子），爆炒三分鐘
3.宮保雞丁：配菜（蔥姜蒜，醬油調料，雞肉切丁），爆炒五分鐘

如果我要為這些菜做準備，需要的就是蔥姜蒜，調料這些通用的配料，和每個菜不同的主料對不對？我們的 CG 製作中，對燈光需要的數據準備其實是和配菜非常類似的概念。一個場內不同的鏡頭中，環境道具就是配菜，因為它們在每個鏡頭中都是一樣的，有動作的角色就是主料。我們只需要為每個鏡頭準備人物的動畫緩存就夠了。在產品級的 CG製作中，一般來說「主料」的數據量反而是小的，數據的大頭還是環境和貼圖（貼圖是不需要重複輸出的）,。主料平均也就是總數據的 5%-1% 而已。（一般的估算幾十幀的鏡頭，一個主角需要的數據量大概200MB左右。）所以來說，菜譜式渲染可以讓單個鏡頭傳輸的數據量下降一個數量級。

可能有人會問，你的鏡頭裡的配菜，不是還是要上傳雲端的么，那不還是很大的數據么？沒錯。但還是像做菜那樣，常用的配菜是在平時總是一直準備好的，主材準備好以後就一鍋下了。所以環境類資產的數據在平時會不斷向雲端同步。當道具資產提交到本地伺服器之後，同步到雲端；貼圖提交到本地伺服器之後，同步到雲端；動畫緩存提交到本地伺服器之後，也同步到雲端。同步沒完就在雲端渲染？呵呵，其實這種情況不常見，因為從上游組提交到伺服器，到燈光師接到通知在本地測試渲染，到測試沒問題再向雲端發要求渲染，這個過程也是需要時間的，一般情況下測試完成時同步早結束了。萬一沒結束怎麼辦？雲端請求放一個比對檢查就行了.

那麼總結一下雲渲染需要的條件
1. 雲端與本地一致的軟體環境。如果本地是用炒鍋，雲端用的是砂鍋，那就永遠別想兩邊做出同樣味道的菜了。
2. 雲端與本地一致的文件系統。如果本地蔥姜蒜放在第一排第三個盤子，雲端放在第二排，那雲端也沒法取到這樣菜
3. 菜譜式渲染的流程設計。雖然理論上以 Maya 或者 Houdini 為平台也能設計這樣的流程，但我還是建議應該用提出菜譜渲染概念並實踐的 Katana
4. 渲染調用數據盡量細分。一個帶貼圖的模型緩存，不如一個乾淨的模型 + 一套貼圖 + 一套材質和模型的連接關係，這樣修改以後可以盡量少的同步數據。
5. 本地和雲兩端的技術團隊。相信能做到前幾條的CG團隊肯定是有足夠的技術實力了。但是燈光作為製作中最後一個環節，總會有意想不到的情況發生。而且即使菜譜式渲染可以盡量減少數據傳輸量，在任何時候還是需要對數據流做出有針對性的優化

那麼這麼做的好處是什麼？
1. 少買渲染節點。一個長期項目中，渲染需求是一個波動的曲線，如果按照波峰來買節點必然有重大的浪費。
2. 逼迫我們的製作流程中的數據必須嚴格按照規範來。對國內的製作公司來說，這甚至比第一點更有意義。

最後補充：我們是追光動畫，他們是阿里雲

實名反對@子雄對於realtime的過分樂觀，光線追蹤離解決任意渲染問題還早得很呢，對於全局照明中焦散或者複雜路徑依然沒有很好的解決方法。
Recent Advances in Light Transport Simulation: Theory Practice (SIGGRAPH 2013 Course)
可以參考SIGGRAPH 13的light transport course的倒數第二個ppt，Monte carlo 演算法在某些情況是可以做到很高效率但是由於它本身的屬性（方差是隨著樣本平方減小）對於某些場景依舊是幾十小時上百小時才能做到產品級質量，而這一點對於遊戲這樣的實時性應用是不能忍的，如果在遊戲中應用光線追蹤，玩家突然把視角轉到一個全是間接光照明很困難的地方，幀率一下掉下來咋辦？

再說說GPU上的光線追蹤存在的問題，就比如brigade和octane renderer，親手測試，場景夠小，octane確實非常快，但是場景規模一大，速度立馬爆跌（GPU顯存以及CPU GPU數據互傳問題）
普通室內場景已經幾乎與CPU渲染速度一致，更不用說幾十G的電影場景了. GPU的這些問題需要若干代來解決，但是很有可能在解決前CPU和GPU已經撞牆，可以參考Intel 新發布的Xeon Phi

那麼為啥大家會覺得實時越來越貼近offline的畫質呢，因為它本身的起點就太低了！實時的很多渲染技術其實就是offline一些東西的重複利用，比如unity和unreal的physically based shading，其實就是一些基本類型的微平面BRDF，幾十年前的論文，那你再去看14年weta digital 的毛髮BRDF建模，已經複雜到讓你難以想像了。

那麼光線追蹤或者說基於物理渲染的意義在哪裡呢？本質上還是用便宜的機器成本去節省人和藝術家的時間，比如材質的問題，理論上高質量的貼圖能搞定一切（實際上遊戲里確實是這麼做的）但假如有了BRDF我啪啪啪幾下就能搞定，效率自然提高。再比如說電影特效，靠合成分層一樣能做的很吊，但是現在的CG VFX哲學更加推行preview + one shot，一個鏡頭渲染搞定. 而從這個角度來說，雲渲染或者分散式自然有它的意義。算力的解放意味著能夠使用更加複雜和無偏的演算法，對於藝術家和團隊來說能夠達到更高的生產效率。另一個方向是將更多的生產流程搬到雲端去，想像一下你在製作或者設計過程中就能夠同時的preview一個幾乎完全真實的效果圖，這毫無疑問是未來的方向，事實上也已經有人做了，比如剛剛被Autodesk 6300w 刀收購的lagoa：

LAGOA | Cloud-based 3D Design and Publishing

同意 @子雄的回答的第1 2 3 4 點,
」短期內沒戲，長期不看好。

1.吞吐數據量太大，小也有幾g到貼圖模型動畫數據來回傳，傳圖時間頂的過算圖時間了。數據量少的圖又沒必要用雲來渲。

2.數據保密。這個對某些如電影、產品設計等行業比較重要。

3.需要和花的起錢要做雲渲染的公司別買得起渲染農場。一個160核的農場現在價格就十幾萬：一個cg製作人員一年的工資。而且本地調試和io性能都是雲無法比擬的。

4.生產工具要變成在線化雖然說是遲早的事，但前提條件是網路條件好到一定程度。

而且首先會在娛樂行業中出現計算在線化。雲遊戲都推n年了才有點苗頭：onlive可是在09年就推出了雲計算遊戲，直到今年微軟、sony、amazon才正式進入戰場。其首要面對的問題便是網路帶寬和延遲。"

對他第5點開始的答案持保留意見, 原因有下:

1 .
realtime能渲染地這麼棒其實靠很多預計算, 貼圖, 紋理, 場景燈光, 粒子系統各種原件的製作, 和offline渲染完全是兩個等級兩種概念的事情. 對於像電影這種追求到毛孔的渲染質量要求來說, realtime的演算法根本無法達到.

2. 個人是專業搞流體演算法的, 實時的和離線的都搞, 我只想說, 對於電影需求的流體模擬來說, Nvidia倒騰出來的那些實時演算法, 根本就是每年讓N飯熱血一下的"玩具"級別的流體演算法. nvidia搞出來的演算法, 在遊戲這種不追求細節的環境中應用都尚要一定年月, 如果用它的東西來做電影級別的模擬, 其效果就是四個字不--可--接--受. 現在電影一個爆炸和煙霧, 湍流已經開始普及渦粒子模型, 上100K的渦粒子, 用全GPU並行解算, 一個時間步的長度就要達到5~10sec(已經是很快的代碼), 用於渲染需要幾billion級別的渲染粒子, 這樣的數量級, GPU連存都存不下你搞幾十個GPU來一起並行, 此時的計算模型就是分散式運算了, 和單GPU很不同, 數據傳輸, 分塊, 排序演算法的實現...等等等等....能比同等數量的CPU快上5~10倍是很好的了.

---切割線...所以...為了對比子雄給的nvidia的例子....我就舉幾個電影級流體的 preview 水準的例子

https://www.youtube.com/watch?feature=player_embeddedv=8GGwVjCUWyY

能達到final cut 級別的模擬, 比如:
http://vimeo.com/78836903

我個人認為是一個概念炒作。
我之前對雲的理解就是：所有大量重要數據可以存貯在第三方伺服器上以備隨時調用，不用擔心丟失等等。如果他們是雲渲染是否我可以理解為：我上傳文件，你們幫我渲染成成品並且在你們伺服器保存一份？那他們跟渲染農場有何區別？給錢的話渲染農場也能幫你備一份成品呢，而且現在渲染農場都不需要直接拿著素材去渲染了，全程網路就可以。

雲渲染其實在國外以及用上超過十年了，是一種典型的SaaS服務，也是符合所謂共享經濟的社會發展趨勢。

前面追光的朋友講得很好啊，除了可以提供非常高的彈性，減少製作工作室的投資之外，最大的一個好處，甚至可以倒迫製作團隊的技術規範，往更規範的方向發展，這個是非常有意義的一個事情。

短期內發展起來確實很難，但現在有幾家農場做的還可以了~

CG製作行業的雲渲染應該是有了質的進步，不僅僅體現在渲染農場場。
早兩天去北京參加中國影視與動漫高峰論壇，期間炫我科技（就是炫雲）講解了一款新的產品，就是影視雲流程。影視製作的雲流程，配合雲存儲雲渲染等，可以解決很多現有影視行業流程相關的問題。我覺得這是一個質的飛越。而且聽完講解後才知道，所謂的雲渲染並不是我們簡單理解的在線的渲染農場那麼簡單，計算資源按需調整（動態），按量計費，才是雲渲染的特色。還有渲染插件一鍵提交、公有雲和私有（專用）雲的細分。對於保密性比較高的比如軍工這類的現在用的都是私有雲等等吧，覺得這才是渲染農場和雲渲染的區別，也不知道說明白沒有。反正我是覺得雲渲染的技術已經是非常成熟了，如果能配上這套雲流程的話，就對中國影視工業化製作的推動來說，絕對是福音。