1、基于 python 的流水线有些读者可能会问，既然 maya 和 houdini 这样的软件己经如此强大了。对工作室来说，如果加入新功能的话，只要写插件就可以了，重新开发流水线是否真的必要。这个问题是非常值得讨论的。是否有意义取决于两个方面，一是应用的价值，一是开发的成本。为了读者意识到自主流水线的意义，不妨想像这样一种情况。假设场景中有许多群众演员类的 CG 角色。这类动画通常精度要求不高，但是数量巨大。可以从网上的 motion 数据库下载大量的动画数据。下载之后发现，数据的作标系有问题。这在 CG 中是一种常见的情况。比如制作约定时，角色向 X 方向走，而动画的数据是向 Z 方向走。或是
2、将角色的动作作一个镜像的变换，将左半身的动作转换到右边身去。如果你是 maya 用户要问 autodesk 公司怎么办，autodesk 公司一定要人买一个 motion builder。在最好的情况下，软件是现成的。但是可能你要花一段时间开学习 motion builder。即便你会用 motion builder，处理这样大量的数据你可能还要学 motion builder 的编程。所以看似简单的事在没有自己的流水线工具的情况下可能做起来并不简单。但从数学原理上，这类问题是极期容易的。如果你能将动画数据导入到矩阵或是一个二组的数据中，全部的操作实只是将数据中的作标都乘一个变换矩阵，或是将几
3、列的动画数据置换一下位置而己。通常只三行程序就够了，强大的语言可能只要一行。所以只要知道数据文件格式，并且有导入导入数据的软件库，许多 CG 制作中的技术问题都可以简洁而优雅的被解决。对有研发能力的制作工作室来说，数据才是最重要的，流水线的核心功能实际小是读取，解析和保存数据。Asset 为核心架构中的文件格式管理第一个问题：开发流水线的主要原因不同的工作室有不同的需求。Cg 软件，特别的通用软件，在设计时的目标是在一个软件中完成所有的工作。其中暗含的一个想法是希望所有的工作能由一个人在一部机器上完成。这种设计思路显然不是为团队协作而设计的。在今天的 VFX 领域，工作不仅不是由一个人在一部机
4、器上完成，更多的时候即便是一份工作也要由许多人，甚至许多团队来完成。工作不仅只限于一部机器上，更多的时候可会分包在太平洋的两端。对于这种规模的协作而言，houdini 跟 maya 这种工具是远远不够的，这种分布的流水线必须有非常强的网络跟数据库支持。对于这种分布式的流水线来说，它们软件架构会更接近 google 或是 amazon 这样的网络公司的软件系统。它的核心组织是以数据为中心。在 VFX 制作中，称之为 Asset 为核心的结构所说的 Asset 中心的流水线中，制作不是像普通电影按镜头和故事来组织，而是按制作产生的数据类别来组织，如模型，材质，纹理，动画曲线，灯光。每一个制作人员不
5、是分配给一个或是几个镜头，而是被分配给一个数据资源的制作工作，如建一个模型，画一张纹理。在这种结构的组织下，制作人员的分工更加专业化。制作人员通常并不需要了解制作的全部知识，只要精通一项工作就可以了。对于一个建模师来说，它的工作只需要用到多边型建模工具就可以了，动画，材质和纹理的东西不仅不对他无用，而且在许多时候，是绝对不允许建模师修改的。在另外一些时候，交给建模师修改任务的时候，数据库一定要找到原有的模型数据，必要时要将原模型跟修改后的模型都保存下来备用。这也是为什么采用数据库的原因，在以 assert 为核心的流水线，对数据的查找，访问权限以及修改版本的管理的功能都被强化了。在这种结构的流
6、水线中，即使使用了 maya 和 houdini 这样的工具，数据交换也不是按maya 或是 houdini 的方式来进行。在这样的流水线中，所有的节点都会把关键操作都是写到数据库中，所有关键数据在被操作前，也要从数据库导入。从另外一点来说，maya 和 hounini 的文件格式也不适用于这种架构。maya 跟 houdini 的文件格式在本质上，不是一种数据文件，而是创造场景的脚本程序。这种文件格式也不适合数据库系统来管理跟查找。所以采用以 asset 为中心的流水线系统，一定要有自己的数据格式，一定要有自己的数据内容规范。而开发的文件格式的转换跟读取，解析以及存储的程序基本就构成了自主开
7、发流水线的中的主要内容。一旦文件格式的问题解决了，应用程序的开发就可以直接操作数据， 而不必再写成 maya或是 houdini 插件的形式。软件的开发在形式上也更加方便。Phython 的优点：houdini 跟 Maya 结构很不相同，但新版本都加入了一项功能，就是对 python 的支持。这是自然而必要的。在 VFX 技术圈， Python 会成为比 maya 和 houdini 之类的工具软件更主流的技术。如果读者读完前文也许就会发现，主流 GC 软件都是脚本加插件的结构。在设计上，我们通常称之为虚拟机的设计模式。也就是说如果一个软件对灵活性要求非常高的话，最好的方法就是设计一问专门的
8、编程语言，让用户自己去编程。这实际上不仅是 CG 圈，可以说整个 IT 产业都采用的一种方法。不仅 maya，houdini 是这样，实际上渲染器，网络济览器也都这种结构。在本质上 maya 跟 houdini 都是这样的。它们只不过是除了设计一问专业的编程语言外又加了一个可视化的 UI 工具而己。从虚拟机的角度讲，功能扩展有两种方式。一种是组合式的，我们称之为脚本或是procedural。另一种是原子式的，通常理解为扩充虚拟机的批令集，我们称之为 operator 或是 node.在以前的架构中，op 或是 node 的扩充是用 C开发的，而上层的脚本是通过修改各种shell 脚本而来的。所
9、以开发者同时要用二种语言开发。但今天的 phython 自身就是虚拟机， phyton 足够高级也足够低级。即可以当成脚本用，也可以当成 C来用。并且在集成原有的 C代码方面， phython 更容易一些。即便 maya 跟 houdini 不提供官方支持，开发人自己加入 phython 脚本也不难。python 的功能非常强，而且可以调用的资源也更多。一旦软件集成了 python，系统的所有功能都可以调用。不管是以库函数还是以可执行文件的方式。对于做技术的而言，可以一种语言走天下。甚至可以说，如果有 phython，maya 跟 houdini 完全都是不必要的东西。它们的架构己经过时了，只
10、有一些己写好的 op 还有应用的价值。因此今天的流水线的技术的一种潮流是是在数据库跟网络后台方面，phython 和 C为主。在前端的应用软件方面，己经不做大的集成，把从建模到渲染合成的全部放在一个软件中的意义己经越来越小了。但是由于技术的发展，许多控制都开始向后推，目的是为了在后期能够方便的调节视觉效果，在后端集成化越来越强。建模和动画更加独立，而材质，光照，渲染跟合成集成的越来越紧密。无论哪种软件，新软件的都是以 python 作为虚拟机的主干，用户通过 python 写脚本，写插件，或是操作其它软件。而对于 maya 跟 houdini 来说，大型工作室己经不再专门为之开发插件，在其内部数据库跟流水线之上，以 python 为核心定义一套脚本跟 op 插件，形成了一个不带 ui 的 maya 或是 houdini 的软件系统。为方便美工的习惯，为每种专业软件只写一个插件，就是初始化 phyton 虚拟机环境，将应用软件的数据转换成内部数据格式，然后通过 python 调用内部己定义好的 op。这样做的好处是，无论美工使用 maya，houdini 还是 nuke，甚至是 renderman，都可以调用定义好的 op. 工作室根据自己技术开发的特殊 op 插件，可以在任何应用软件平台上运行。更多教程
