Vault筆記 - Translating Art into Technology: Physically Inspired Shading in Destiny 2

05-27

來自專欄 Thanks for All the Fish

編輯功能真心還是牛關的好，排版也正常還給目錄...

全文都是從這裡搬過來的，也可以直接在牛關看（死

Vault筆記 - Translating Art into Technology: Physically Inspired Shading in Destiny 2 - 奶牛關

知乎啊知乎... 連個二級標題都沒。

最近翻譯Vault資料的人多到數不過來，好像就沒什麼必要逐頁說明了。

就按自己的理解做個簡單的摘要，順便補充點 感（瞎）想（扯） ，

因為不是翻譯所以也不保證內容的準確性。

原文在這裡

http://gdcvault.com/play/1025382/Translating-Art-into-Technology-Physically

如題圖，Talk有2個演講者，相應分為Tech和Tech Art兩方面。

從題目也可以知道，這篇主要關注Art和Tech的關係。

這個話題對於中大規模的production來說至關重要，

然而時至今日業界似乎依然沒有歸納出一套行之有效的方法論。

即便是TA人口開始爆炸的這幾年，從自己能了解到切實地信息來看，真正能夠做到達成連接Art和Tech仍然是少數。

分支上的各類TA，如shading artist，rigging artist已經相對成熟起來。

構築asset pipeline那邊也有TD負責。

但優化或者定製workflow或是runtime之類的後勤工作依然不吃香…

在聽到Nate最後幽幽的吐出一句"Im just a TA"的時候，

覺得即使是能把這樣的內容帶上GDC的環境里，

Tech和Art的共生關係也遠遠沒有達到大規模製作所需要的程度。

主題

一頭一尾給的兩張圖很好的概括整個內容。

所謂translating就是一個從需求（Art）-> 實現（Tech）-> 結果（Art）的過程。

原文說的是， Going from art concepts to engineering, back to art while preserving and refining the original goal is what we call translation.

雖說是translate，

對於製作過程來說refine是不可避免的，同時一開始的goal也通常不是100%明確的。

另外，既然是translating還是必然會有"lost in translation"，

refine的過程中避免偏離目標也很重要。

於是，

Q：如何保證製作過程順著這個flow進行？

A：對於遊戲來說，Goal和Result永遠都是Art。

（注意Tech應該去實現Goal，而不是成為Goal）

Q：如何儘可能地使Result貼近Goal？

A：像下面那張圖一樣，模糊各個階段的邊界（比如靠TA）來保證communication順暢。至於怎麼實際操作，這裡有takeways…

然後剩下就是細節問題了（死當然其中一半以上的問題，是中大型規模（20人以上？或者說有TA生存空間的）的遊戲製作環境所特有的。

剩下的是Tech Art/Graphics的純技術細節。

老實說兩者對於小團隊沒啥卵用…

對於中大型團隊來說，技術細節很少會成為瓶頸，

迭代效率才是進度的最大敵人。

特別是美術方面即使思路和工具都有了巨大的發展，

體力活依然是體力活…

於是就需要上面所說的引導和保障並存的環境（怎麼好像在宣傳TDD

然而把工具做好，或是給人科普不管在哪都是很難被度量的業績，簡單說就是吃力不討好這也導致了即使有部分人願意主動去做，也會因為各種內部外部原因而堅持不下來。（最近知道了碼農這邊搞各種中層系統的也是同樣尷尬的處境

Tech - Alexis

Overview

基本是在講怎麼從讓當初製作Destiny引擎進化到現在的樣子。 Renderer基本沒有什麼特別的地方，比較意外的是Lighting相比GBuffer佔比似乎較高，不過仔細一想網遊比起扣Geometry細節來說，在Lighting上投資確實更實際。

這張requirements大概也可以被稱為開放世界常見大坑一覽表了2333一本道的時代的各種偷懶技巧慢慢地都開始不適用了，

動態的東西越多，組合就越多，需要的Asset也就越多，而開放世界正好是建立在這個基礎上的。

這裡的問題目前都沒有通用解法，每個遊戲都還是會根據需求和限制來實際進行取捨。

（隔壁桌的人常說，一幀反正就33ms，想在這裡加東西就得在別的地方刪東西，最終都是選擇問題

Material Art Direction

回到正題，視覺表現最直接的體現就是材質了。PBR的出現解決了一大部分問題，但遊戲需求的提高也並不會因為放緩。

從分析舊材質系統來導出需求。然後作為一個「系統」，首先分清主次，方便給人用是主。這裡也強調了過多的Control（可控性）是有害的。

雖然整個基礎部分都可以划進Tech的範圍，但最終的目的還是服務於Art的。

另外也從這裡導出了 Safety，Simplicity，Guidance 這些關鍵詞。 Implementation部分就是怎麼在僅可能滿足這些需求的前提下進行選擇，細節就跳過了www

↑說起來容易做起來相當難，假設實際遊戲運行所需要的功能的工作量是1的話，

那麼編輯輔助功能，各種調試功能，以及優化的工作量就會是100，甚至1000。（並且相當枯燥，也就是說容易出現沒人願意做的情況… 原文花了很大的篇幅來討論如何定義各種參數，以及各種優化策略，

本質上都是為了能讓Artist能在創作的過程中可以忽略細節而專註於Art本身。

Lighting

Lighting基本上都是技術細節了於是跳過….

Tech Art - Nate

這裡提了一個非常有意思的觀點，像Destiny這樣生命周期較長的遊戲，會需要一直進行更新，完善，補充內容。（圖裡大概是pokemon梗）不僅是有新的Asset或是Visual的需求，甚至會有新的遊戲模式。

擴展開來說，不僅僅是網遊現在開發周期本身就要幾年的情況下，環境會一直在變化，跨世代的大作也是屢見不鮮。

所以一個版本的引擎很可能只夠做1~3個遊戲就得開始準備應付下個世代了。

於是在設計的時候把目光放長遠已經可以說是必須的了。

但是顯然需求不是能簡單應付的東西。雖然第一次聽說Feature Parity這個詞，不過日常跟Artist打交道的過程中真是有切實體會。

換個角度來看其實就是組合爆炸。

有A，B，C三個功能的時候，AB，BC這些組合功能便是隱性成本了。

原文舉的例子是Terrain+iridescence和foliage+fuzz，

雖然乍一聽會覺得都是些什麼奇葩組合，但實際等Artist開工了想像力可是無邊無際的。

記得幾年前有個大佬說過其實任何新技術都只要2天都能實現出來，

但要保持健壯穩定高效就是另外一回事了。

當時就覺得大佬真牛，實際自己動手做過了就覺得大佬真辛苦…

回到Safety，Simplicity，Guidance 這些關鍵詞上來，Parameter ordering這個問題，看似毫無技術含量，回報卻相當高。（對於碼農來說，就跟看到Refactoring技巧裡面有一條rename的感覺一樣，開始滿臉問號，後來連連稱是。當parameter的定義和順序非常混亂的時候，出現不合理的參數組合的可能性就更高，Artist也需要花更多精力去理解背後的技術細節，

技術人員最終也還是會在debug上付出代價。

至於color picker，每個引擎，DCC都會有，但要做到上面那個程度，

事前需要確立一大堆標準，並且還要符合Artist的使用習慣，

比起實現難度，決策難度要高出好多倍。

Textures

介紹了非常魔幻的自動packing機制。隨著shader製作的開放化（由Artist直接製作shader），

技術人員需要或者說可以介入的部分越來越少，性能和自由度這兩極就會非常難平衡。

Packing是很常見的策略，但是要求Artist在製作shader或texture的時候考慮packing必然是非常沒有效率的。

自動packing就很容易想到了，然而這裡又是個組合爆炸問題www

Decals

Decals也是一樣，當給了Artist自由度之後，組合爆炸幾乎就是必然。然而要在這樣的環境下去解一個優化問題（運行時性能，內存佔用等作為約束條件），雖然不是不可能，但在遊戲開發這樣不穩定的環境下維護成本會相當高。

這裡的解法就是回到原點，從目的而不是手段出發進行了抽象。

很多時候在跳進實現細節考慮下目標是什麼，怎樣才是達成目標的思路是相當重要的。

Validation

既然有了PBR等一系列rules，接著就需要讓這些規則更容易驗證。前兩天還在推上看到了類似的討論，Visual Art方面完全的自動化似乎至今沒有很好的solution。

所以現實角度來說就是儘可能地讓製作者本人更容易確實做出來的東西是否符合規範。

對於Artist來說Visualization幾乎就是必然的選擇了。

總結

技術細節幾乎年年都有人講，加上UE4開源之類的資源普及，門檻已經相對較低了。

但實際操作起來卻不是這麼容易。

做遊戲的過程本身就是合作突破各種limit的過程，

在有理論基礎的部分（如PBR），難點在於如何讓系統更易於理解，使用。而沒有理論基礎的部分，難點就主要在於如何建立合理的規則，並以其為基礎和Artist合作了。目前來說，這些方面的內容很大程度上還是靠經驗來堆砌，也就覺得這篇東西非常難得了。

雜談

有意思的點

destiny1的時候材質全靠ID索引
拿QWOP來解釋too many controls真是再合適不過了
原來GGX的那個叫hyper rough，11區好像叫super rough，不知道為什麼大家都不用
transmission依然靠magic number… 雪地和帳篷的例子好像之前就在推上看到了…
iridescence原來只要lut就可以搞定，known iridescence types as standards!
debug view裡面不僅顯示顏色還有數字！仔細想想好像也不難實現（抄回去抄回去）
GBuffer依然很compact啊！packing真是玩出花了
Cubemap居然有個roundness參數！
娜姐都走了快一年了你們要致謝多少次啦！
textures和decals的packing又玩出花了… 好奇自動化要寫多少輔助工具和測試…
Validation部分還提到了Cornsweet illusion！然而最後解法的有效程度還是挺可疑的
一個光源兩種顏色也是第一次見…

Technical Artist? Technical Director? Tech Art Director?

我個人還是不太分的清TA和TD，不過也沒想要特意去分清過。

畢竟TA和TD的差異因環境變化相當大。

目前個人的理解來說，

TD是設計實現workflow的，

TA是完善優化workflow的。

雖然內容有類似的部分，但我更偏向於，

TD是面向功能的，

TA是面向人的。

遺憾的是周圍目前還沒有見到符合我這定義的TA。

倒是有個Tech Art Director，這算是TA的進階職業么？

做的事倒是挺符合的，技術的validation和推廣以及workflow的改善。

希望這樣的人再多一點吧。作為碼農好省點心（本音）。

以上，瞎扯完畢！