【资讯】Frozen II 一些场景和特效的实现

【I. 关于魔法森林】
Joseph, Norman Moses, et al. "Frozen 2: Effects Vegetation Pipeline." Special Interest Group on Computer Graphics and Interactive Techniques Conference Talks. 2020.
DOI: 10.1145/3388767.3409320
魔法森林是冰2的主舞台，这里的植被非常丰富，枝叶都很有辨识度。镜头里几乎永远有树木，各种角色也都在不断与树木进行互动。植被的数量和规模对于特效团队来说是非常有挑战性的。
迪士尼之前已经有很多工具专门用于植被生成的工具，在冰2中用到的包括：
XGen：是一种任意图元生成技术。它最大的用处是在一个表面（二维流形）上生成需要一定程度的“随机性”，但又有规律可循的东西。此处“图元”可以是头发、叶子、羽毛、瓦片……在冰2中用于生成树木、灌木、苔藓之类的。
Bonsai：是一种专用于给植物建模的工具，界面大概长这样：

可调整的参数非常之多！
Aurora： 是一款点状和嵌套式的”实例化“工具。 我想这里的实例化和可视化是近义词。
因为这些不同的工具是同时使用、用于不同的设计阶段的，就带来了一个问题：这些工具各自的设计者为了最优化它们各自的性能，做出了不同的管理和存储数据的方式。
建模的一个阶段完成之后，数据要导出再导入到下一个阶段的工具中继续的时候，就非常麻烦。这个导入/导出的过程对每一种植被数据都是不一样的，所以需要花很大的精力来管理各种”衔接“上的问题。
打个不太恰当的比方：假如苔藓工具使用的坐标是以坐标的外接立方体的左下角为原点的， 而灌木工具使用的空间坐标是以外接立方体的中央为原点的。于是当我们想要用实例化/可视化工具来把他们组合在一起的时候，变换和投影这些坐标就要用不同的矩阵了……如果我们有成千上百种植物，然后各种植物的树冠、叶子和枝杈的数据处理方式都不一样的话……
为了能获取高质量的的视觉效果，也为了能让艺术家们能专注于效果、不在数据和资源管理费太多心思，特效团队开发了针对”植被资源“的工作流程：Vegetation Asset workflow

这个工作流程基于Houdini引擎。Houdini是个基于“节点(node)”的“程序式(procedural)”引擎,功能包括了建模、渲染、动画、特效以及其他更多。
“节点”和“程序式”都听起来很抽象嘛，其实楼主自己也不知道怎么解释毕竟我没用过啊……（别）每个节点都是一个任务，或者说是像编程时的一个函数，存放着完成这个任务所需的逻辑步骤和数据。而“程序式”就是把一个个节点用逻辑关系串起来的这种“网络”。
像程序里把一些代码封装成库一样，Houdini中我们一样可以重复利用同一批节点织成的网络，把它封装成可以反复使用的“资源(asset)”
抱歉……我觉得我还是啥都没说清楚o(TヘTo)……
用一个官网的例子来说：如果这个项目的目标是渲染一个长方体箱子的话，那我们可以用三个节点完成这个任务，这三个节点是线性的一步步推进的关系：
一个节点决定八个顶点的在空间种的位置/坐标，一个节点决定只有箱子的外壳需要用长方形连接起来，一个节点用之前的信息做出箱子的六个面。
然后我们可以把这三个节点以及它们的逻辑关系（先做什么后做什么）封装起来，成为一个“箱子”资源。
于是冰2的Houdini有三个专有的Houdini节点：选择植被、更新植被、生成（实例化）植被
以及一个普遍的节点：进行物理模拟
动画师们走的流程是 选择 --> 模拟 --> 更新 这样，而”生成（实例化）植被“这一步则在制作的每一步都可以调用，这样动画师们就可以每做一步调整就实时看到物理模拟的样子，而不是和一大堆数据干瞪眼了。
这好像很显然的样子? 而且你看，Bonsai就可以实时给建模者看到模型的样子嘛……
不过这个流程可以让动画师们无缝衔接不同建模阶段而不用担心数据导入导出的问题、同时使用很多种类植物模型、进行很大规模的物理模拟， 等第……
（更具体的明天再继续吧hhhh）

【之后楼主会把自己添油加醋的解释和臆想放在方括号里】
有这个工具之后，特效师们 只要用一个Houdini节点——也就是“选择植被”这个节点，就能导入所有的植被资源类型了。这大大简化了导入数据的过程。
没有这个工具的话，如果我们的工程长这样的话，每一个node都是一个asset，每一个都需要分开处理导入导出数据的过程……

【 楼主臆想时间：这可能就像我们用单独一个软件就可以打开并编辑doc，ppt，xls，或者一个编译器就能搞定java，py，cpp一样的感觉吧！】
然后，这个工具会变换、并扁平化来自不同类型的植物资源的数据。这样数据的形式在同一个可视化级别上就可以保持一致了。
【 楼主臆想时间：比如说把所有模型的坐标原点都调整成这个模型的外接长方体的左下角，数据格式都换成float32，把向量、矩阵、张量之类的数据按照某种统一的规则变成一维的array……之类的吧】
数据转换需要考虑的事情当然比楼主能想象到的还多得多。空间坐标这样可以说是最简单的了。迪士尼要确保的是各种物理模拟对各自导入的植被数据所产生的效果要是和谐的。那就意味着Houdini自带的各个解算器必须能能对所有的导入数据产生一致相同的效果，比如说，Vellum解算器——这是一个GPU加速的多物理量解算器，可以用来模拟植物、头发、果冻之类的。
【下面这个例子是用Vellum解算器进行的植物模拟，gif来自tokeru.com/cgwiki/index.php?title=HoudiniVellum】

数据转换就包括了确保这个球滚过不同类型的小草的时候效果要一样，比如说弹性、粘性之类的表达方式都要统一
Frozen 2 里 风灵对树枝、树叶、地表的落叶造成的动作能如此连贯和自然可真是不容易的事情啊】
动画师们完成模拟工作后，点和曲线的数据被传递到下一个“植被更新”的节点。这个节点会查看数据并自动更新每个资源的内容，确保每个资源都包含更新的模拟数据。
使用这些节点，艺术家们就不用花太多时间在枯燥和易错的数据上啦——专注于美化他们的物理模拟就好。
而最后这个“可视化/实例化”节点，是用于将整个工作流程中的植被数据变成可视化的几何图形，这样动画师们就可以在过程中的每一步都实时看到物理模拟的样貌了。
这个节点还允许动画师查看在模拟中使用的原始几何图形，动画师也可以在更新节点之后把输出的新的几何结构作为“输入”重新放回资源中。每次模拟后，都可以。
最后，因为这个方便的更新几何结构的功能，这个工作流程可用于影片中任何“程序性”的元素——不再局限于仅仅是渲染和模拟植被。

大家应该对魔法森林起火的场面印象很深，但是如果我们用传统的分工和工作流程来制作这个场景的话，似乎是个很难为动画师们实现实时的可视化。这是为什么呢?
传统的工作模式是，我们把会动画师们分成两个团队，一批人负责布局（建模、分镜、设置镜头、选择哪些树会着火等等），一批人负责特效（物理模拟，包括火焰和重力等）
布局美术师需要看得到最终的火灾模拟特效来选定哪些树木应该着火，但特效师们需要知道哪些树会着火才能设计镜头中燃烧的树木的外观……这就造成了一个鸡生蛋蛋生鸡的问题。用传统的工作流程的话需要多次迭代“特效”和“布局”这两个步骤才能看到效果，会耗费很多计算和存储资源。
于是软件工程师们就专门为此开发了两件工具：
> 一个预先模拟的燃烧树木数据库
> 还有一个新的Maya插件，FireStarter
这个插件允许布局美术师们直接选择树木来“放火”，不再像之前那样稍有改动如果想看到就必须重新迭代了。

迪士尼开发了一种添加火灾模拟的流程。在创建植物资源的时候，火焰的模拟数据就直接成为植被本身的“属性”之一，这个物理模拟的结果可以像树木的颜色、纹理之类内在属性一样很容易就能被调用。
其中用到的技术有：
> VDB
一种数据结构，适用于具有【动态拓扑】并有高分辨率要求的【稀疏体积】
并不是迪士尼的原创，而是2013年由梦工厂开发的。
叫这个名字是因为它是个体积（Volumetric）的、动态的（Dynamic）网格，并且与【B+树】有很多相似之处
【似乎这里每个名字展开都可以是长篇大论啊……欢迎大家补充或者我以后补充！不过以楼主的能力，大概只能搬运一下定义了】
> 着色器
【原文没有细说，楼主的理解是不太特殊的负责进行几何变换和光照计算的程序，顾名思义，着色器通过这些几何和光路的运算最终输出的频幕上哪个像素是什么颜色.
其中几何变换告诉我们去看"哪个像素"——一个位置坐标，而光照计算告诉我们“什么颜色”——可以用RGB（或者别的色彩空间）等来表达】
> 粒子系统
用于燃烧后余烬/粉尘的模拟
【原文没有细说具体的实现，不过3D Studio Max、Maya 以及 Blender之类的软件本身就自带自由度很高而且很成熟的粒子系统了，大概并没有什么与众不同之处】
当布局美术师把一棵棵树放进森林的时候，这些树的模型本身就已经带有了预模拟树数据库，都是自带火焰模拟的树！树木的层次结构并不重要，布局师们只需像真正的园丁一样“种下”那些单个的树木模型，然后选中那些他们觉得需要着火的树就可以了——在交互式Maya视口中，燃烧的树木将会被高亮成粉红色。
Maya的播放功能可以实时展现灰烬颗粒的模样。这样依赖，布局美术师可以随时调整镜头的位置和树木着火与否的情况。而完整的最终模拟效果会在整个场景的布局完成后、整个场景一起渲染时显示。
等等……如果我们在所有的树上都用了相同的预模拟数据的话，岂不是火焰的样子都会很像，最终效果会很明显是“量产”的，会观感很不自然么?
不必担心，特效师仍然可以逐个帧精细调整，来减少太过相似的效果。这一切都可以在布局师们完全完成建模和镜头设置之后进行，不需要在两个团队之间反复横跳了。
有了这些工具，我们不仅省去了许多不必要的、耗费计算资源的来回迭代的物理模拟过程；而且还能让这两个团队（布局和特效）有更清晰的职能划分。一个任务只需一个团队独立完成，不再需要同时并行工作了。

VDB数据结构的原论文：
http://www.museth.org/Ken/Publications_files/Museth_TOG13.pdf
随机和按序查找/插入/删除的平均时间复杂度都是O(1)，原作者简直是神仙……