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最后幽幽的吐出一句"I'm 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的改善。
希望这样的人再多一点吧。作为码农好省点心（本音）。

以上，瞎扯完毕！

关于validation和guidance的重要性，回来补充一个（真实）段子。
自己也经历过好几次所以深有体会...