浅谈CG流水线《又名五分钟内精通Maya》（全文）

浅谈CG流水线《又名五分钟内精通Maya》不知做CG的是否听过计算机系的一个笑话：有二个学生争论：一个说： C是最好的编程语言。另一个说 Java才是最好的编程语言。教授听到后说： 最好的编程语言其实是研究生。对于CGer来说，哪个软件最好的讨论可能是最为热烈和旷日持久的争论了。在VFX圈中，最经典的可能是Maya, Houdini和XSI之间的争论了。如果VFX技术的作者不讨论这个问题，那么真是有点对不起CGer了。本文试图从技术角度来比较一下几大工业级的CG软件。一　重要的不是软件，重要的是流水线每看过一部大片的后，观众们第一的反应到问题是这电影是用什软件作的。在今天的VFX领域，一个简要的回答是各种软件都有，或是艺术家愿意使用什么就用什么。这样的回答几乎相当于什么也没有说，读者可能会感到更加诧异。下面就容作者给大家详细解说一下：对于工作室，特别是大型工作室。制作过程并不是按照建模，动画，渲染，合成这样的线性流程进行的。许多时候，为了赶工期，许多工作时并行的，并且在制作的最后阶段，需要大量的修改。这样的工作流程需要极强的自动化软件系统支持。比如，当艺术家修改模型之后，艺术家希望动画的修改和渲染的修改可以自动完成。同时，动画师希望可以专心的设计角色的动作，而无需关心角色建模和材质的变化。这套自动化的软件系统在VFX业内被称为流水线。所有的制作工具是基于其内部的流水统之上的而设计的，无论是商用软件还是自己开发的私有工具是作为流水线上的零部件。从技术角度上说，软件大致可以分成两大类。第一类是完成特定功能的软件，主要包括渲染器，流体仿真器等等，动作合成器。如renderman,mental ray, natural motion和realflow之类，有时也称之为插件类的软件。另一类则是综合通用软件如Maya, Houdini和XSI.最初的时候，通用软件试图集成全部的功能，使得艺术家可以在一个软件中完成从建模到渲染的所有的工作。但是在今天，这种想法不仅不现实，也越来越没有实际意义了。在今天，CG技术内容之多己远远超出一家公司的开发能力，也就是说没有软件公司可以开发出CG制作所需的所有软件。另外，今天的CG制作分工也越来越细，期望一个艺术家完成从建模到渲染的全部工作也不实际。就目前来说，许多大型的工作室即使采购Maya或是Houdini这样的通用工具，也几乎不使用其建模或是渲染的功能。无论是建模，动画，仿真还是渲染，都是使用专业软件或是自己的内部工具来完成的。于是通用软件的设计目标就发生了变化。软件的功能己经不再是设计中的重点，设计的重点转向了增强软件的灵活性与可扩展性通用软件比拼的不是功能，而是其架构。对于不想从头开发流水线的工作室来说，采购通用软件的主要目的利用其内部组件之间的通讯机制。将通用软件作为流水线的信息交换的总线。觉例来说：如果工作室开发了自己的渲染器，如果想在制作中单独使用的话必须还要开发许多支持软件将模型，材质，纹理提交给渲染器渲染。一个简单的做法就是写一个插件，将渲染器集成到Maya中，这样就省掉了许多开发支持软件的麻烦。对于有软件开发背景的读者，其实Maya跟Houdini其实不是功能性软件，倒更接近于开发工具包(SDK)或是操作系统，提供文件，界面方面的支持。我知道的许多工作室还在用Maya7.0，新版本的Maya功能他们几乎都用不上。对于这些工作室来说，使用Maya和Houdini主要是因为界面和操作艺术家更加熟悉而己。二　XSI与API流水线架构实际上在强调扩展性方面，做得最早的可能还是XSI。XSI开放了一套API，也就是一些软件库函数，工作室可能调用这些API，同XSI软件进行数据通信。这在当时是很大的进步，因此XSI也成为了侏罗纪公园制作时的核心工具。XSI的扩展性是非常好的，而且软件性能很好，并且稳定。但问题是XSI这种以API开放的结构是比输底层，也是比较低级的。在扩展时，开发的工作量非常大，对于时间周期非常紧张的VFX制作来说是不合适的。因此后来在VFX中的地位一点点的未落了。但是直至今天XSI这种API方式仍然有广泛的应用。它非常适合同开放API的工具结合，而且效率非常好。最典型的这类工具就是游戏引擎。游戏公司主要使用XSI跟3DMax.3Dmax主要是用来多边型建模。而XSI通常连接到游戏引擎的API上，这样XSI就成了游戏编缉器。在电影特效制作中，　XSI被更灵活的架构取而代之。一种结构是DAG，有向依赖无环图， 也就是Maya的核心设计专利。另一种是以数据流为基础的程序化设计，这便是Houdini。在介绍这两种架构之前，首先介绍下VFX工业对工具的要求。软件工程中简单的模块化的设计是很难适应VFX制作灵活多变的要求。VFX工业是无法做需求分析的，导演都是一帮想像力极其丰富的人，你永远预试不到导演想要什么样的效果。VFX软件的设计要求是高内聚，低耦合。希望一项功能能切成不同的小块，而每一个小块又能自由的组合。在另一方面，VFX对实时性和内存要求不高，多数运算都是放在可扩展的服务器上。相对而言，VFX对计算时间和内存的要求并不高，花几十个小时出一张图是可能接受的。因此新一代的工具许多采用了节点式（node）的结构。Maya和Houdini以及开源的blender都是这种以node为主的结构。每一个node都是一个小功能模块。工具的扩展可以有以两种方法：一种是将己有的node重新联接。另一种是开发新的node。虽然都是node的结构，Maya同Houdini又在这里采用了完全不同的结构设计。导致了学习跟使用上的巨大差异。三　五分钟精通Maya作者当年年少无知的时候，就特别喜欢CG，也曾心潮澎湃的学习过Maya。后来没有学成，就放弃了，改学编程了。那时没有想到会有一天写文教别人来学Maya。那时学习Maya最让人抓狂的事是照着《某某宝典》一步一步的按菜单，结果发现现机器像失灵一样，一点反应都没有。为什么呢？后来看书看了几遍（那时还没有互联网）, 发现在后面一页中书中有个小note。再点这个菜单之前，还要选按一下另一个按扭，这样在面板上才会出来那个按扭。为什么呢？不知道。按了一下，还是没反应。于是又哭了，为什么呢？不知道。于是重装了maya，于是重装了操作系统，于是又换了个版本，为什么呢？为什么有那么多技巧呢？为什么我的书上的那么好用，我一按Maya就崩溃了呢？我觉得我可能永远都不知道原因，永远者不可能知道按扭该按哪一个。终于十多年后的今天，我觉得明白了当年为什么自己的机器总死机。于是写了这篇结初学者，算是一点经验之谈吧。一句话说：我们的学习方法是错误的，那种学习方法像可能一辈子都精通不了Maya这样的工具。Maya设计得很特别，学Maya就要学习Maya特别的地方。许多人学习Maya，常常专注于学习Maya的功能，其实圈内人士对Maya的功能评价非常低。Maya的建模不如3DMax, 动画不如XSI，仿真器基本没人用，渲染器是个半功能品。但是Maya插件是最多的，许多公司不扔Maya是因为不能把内部的插件都扔了或是重写一遍。各大软件公司对Maya支持可能是最好的。说来Maya的最得要的优点，只有一个：灵活。只要你弄清楚Maya是如何组织其功能的，就理解了Maya的全部。在此基础之上，各种功能都是可以触类旁通的。一　Maya的基本结构其实学Maya最应注意的是Maya的Hypergraph。许多初学者对这个东西不太注意，觉得Hypergraph是一个不知所运的东西。其实这才是Maya的逻辑跟灵魂。当Maya死机或是软件不正常工作时，最要作的就是打开Hypergraph。当你看到别人的作品时，打开Hypergraph你就可以看到别人的用到的技术。当不知道操作是否成功时，也要打开Hypergraph.Hypergraph就是Maya的设计图，就是一切的一切。看得懂Hypergraph就学明白了Maya的一切。问题是究意Hypergraph画的是什么啊，好奇怪啊。Hypergraph所描述的是一种数据结构：叫有向无环依赖图(DAG)。它定义了Maya各组件之间的数据通信的方式和内容，也描述了动画运算的全部操作跟流程。从技术讲，Maya的核心就是一个DAG引擎。在这个DAG引擎之上，有一个MEL脚本语言接口。从理论上讲，MEL语言才是Maya软件的真正接口。Maya运行时，UI完全是不必要的。MEL脚本语言非常之强大，可以完成任何的功能。但是从另外一方面，MEL脚本语言又非常的简单。因为它的核心命令只不过十句而己。创造／删除节点创造／删除属性设置／读取属性连接／切断节点联接。遍历节点／更新节点。实际上Maya的项目文件不过就是简化后的MEL脚本。在MEL之上，是Maya的界面系统，不管Maya的界面有多复杂。所有按扭所作的其实就是发出一系列MEL命令而己。准确的说是一执行一些MEL脚本的快捷键。这也是Maya软件UI问题多多的原因。许多Maya的UI发出的MEL命令非常的复杂。一些UI生成的脚本会有100多行。可能创造了三五个节点，然后再将这些节点联接起来。再跟UI输入的信息相联。一旦一个节点出错，操作就将失败，而且有时Maya还无法正确的报错。 这节操作是非常易失败的。可能会因为节点名没注册，或是节点重命之类。更大的问题是许多UI脚本是依靠全局变量获取用户输入的。比如UI脚本通常会读取一个叫当前选取节点的全局变量。这种形式的脚本是非常危弱的。比如给多边形加一个形变动画，UI组件的一个菜单或能会生成形变，动画通道多个节点。再将多个节点联接。然后期望系统中有一个叫计时器的节点，假设叫timer1。然后希望用户通过选择选了一个多边形模形，被设成的当前选取节点。如果系统中的计时器节点不叫timer1，或是用户选取的节点不是多边形模型。脚本好的时候失败了而不报错，坏的时候导致系统崩溃。因此许多高级的Maya用户主要是通过MEL脚本来跟控制Maya。他们通常会查看UI输出的原始MEL脚本指令。二　用DAG组织动画流程理解到些，强大无比的Maya只剩最后一点秘密了，这就是DAG.计算机系最初学到可能是从数据结构中学到的。Maya在设计中，是使用这种结构来组织流水线功能的。如下图1-->2-->3.是一张最简单的有依赖有向无环图。其中1，2，3为结点。-->表示联接。在实际应用中可能1代表建模，2代表动画，3代渲染。在设计上每一个节点的功能都非常独立，而且不必在乎其它的节点在做什么。动画师可以修改这张图来实现非常不同的设计。如果动画师想换一个动画算法， 可以再设计一个节点4，取代2.1-->4-->3这样就是另一个动画了。当然，这种情况还是算单了点，我们也可以设计出另一个渲染器51-->2-->3 |-->5其中｜表示分支。这样动画数据2就被分开导入到两个渲染器（3，5）之中。大家可以想像，一个是实时渲染器，可能是游戏引擎，用于预览用。另一个可能是产品渲染器如renderman，用于生成最终的成片。在高端的VFX中，导演跟故事都是不可预测的。许多动画是分解后多级完成的。因此可能出现这样的结构。1-->2--->4--->37------->|这个例子中，1可能是身体，2可能是骨骼动画，4可以是毛发动画而7是毛发模型。可是可能需要碰撞捡测8于是就可以再修改一下。1-->2--->4-->8--->37------->|如果角色站立不动，则可以把骨骼动画2删除1-->4-->8--->37-->|如果1表是多边形模型，现在要换成样条模型9，我们也可以加上一个多边型器10把样条转换成多边形。9-->10-->4-->8--->37------->|当然，你也可以按装肌肉，对毛发进行物理仿真变换等等。接着候改这种结构就可以了。跟API接口的XSI相比，Maya的一个非常大的优势是许多修改不需要编程就可以完成。但CGer要注意的是，Maya做的事地是非常有逻辑的事。你可以不写代码，但你必须要很有条理的思考。在技术讲，各种Node结构的工具在本质上都是可视化的一种编程工具。三　DAG的求值顺序DAG的另一个问题是更新。DAG的更新机制有两种，一种是从左向右的更新。如图1-->2-->3如果将1改了，顺着数据流向下，依次更新所有的数据。但Maya不是这样设计的。在动画中，这种结构有不合理的地方。如果３是工业渲染器，渲染很花时间。每一次改动都要渲染会耗时太多。Maya用的是另一种方式， 是抽取式的，是从右向左更新。当更新3的时候，3读2的数据，2再读1的数据。但是Maya又不是每次都抽取数据。只有在数据有变化的时候才进行抽取2的数据。这是通过另一种扩散机制完成的。当数据修改时，数据会向下联接标注成需要更新。1-->2-->3若2被修改了，2和3会被打上标记。1-->2‘-->3’当抽取3时，2会被抽取，但因为1的数据没有变化，所以不会被抽取。这也说明了Maya中为什么不能有环结构，因为如果有环结构如1-->2-->3|<------|更新3时，1被修改，于是2，3又被标记，3还要再被更新。系统就会进入死循环。四　Maya 的问题从理想上说maya设计得很有完美，但在真实世界中，Maya有时工作得很差劲。按Maya的设计要求，任何节点都读取不到节点之外的信息。节点的所有输入信息都来自于联接或是自身的属性。1->2之前相联绝不是想的那么简单。一个节点如1可以有十几个联接端，一半是输入，一半是输出。结点必须告诉系统哪些输入会影响哪些输出。许多时候，单从单个节点自身的信息是很难知道的。更有甚者，许多时候为了开发效率，在节点之前传递的数据指针。这会带来数不清的问题。另外对于物理仿真来说，一定是有环流的。物体的位置传结仿真器，仿真器计算出的结果再用来修改物体的位置。Maya的更新是很不确定，计算器都是不可预测的，时不时的就跑死机。虽说不用编程，但很多时候，如果你不知道每个节点实现的具体细节，DAG引擎是非常易崩溃的。如果对灵活性要求更高，Houdini更合适了。五　高级学习方法其实每一个使用Maya的CGer都应该去看一看你的DAG,或是HyperGraph.在工业界中，对制作者的要求并不是作出好看的模型和动画那么简单。许多时候在团队协作时，每个用Maya的人都应看看自己的场景文件的逻辑是否合理，运算的效率如何。这是一个在团队中工作的人必须明白的。很多时候，因为UI的失灵或是更新的不及时，Maya中会留下许多无用的节点和断了的联接。将这些东西推给下级流水线是不负责的行为。许多maya高手其实都做过这样一个练习，就是开发一个小maya来。你可以将maya的文件存成ascii的格式，这种格式的文件记录了一个Maya项目中创造了哪些节点，节点的数据属性是多少。然后写一个程序，把maya中的数据和动画加载进来。这要求你实现几个基本node的功能，并作出一个DAG引擎。你可以找一个游戏引擎来，使用其中的代码跟组件，将它们分包成一个个node，然后用自己的DAG擎加进来。四　Houdini，伪装成图形工具的unix操作系统一　没有UI的Houdini终于要说houdini了。老实说houdini在国内好像并不算特别流行。我曾问过人，为什么不喜欢用houdini，回答是“我不喜欢UI,居然连个菜单都没有“对于初学者来说，的确的这样。大家都希望三维动画软件都设计得跟photoshop似的。上面有个大大menu，写着打开图片，模糊，存盘。特别是用windows的人，一直以为这样的东西才是软件。Maya也把自己伪装成这个样子。于是新人也以为可以像学photoshop那个样子来学Maya.于是许多新人认为Maya设计得比Houdini更好。但是如果你学Maya日子久了，或是读过本文的前一篇，你可能明白，三维软件绝不是在菜单栏中加几个菜单那么简单。Maya规规矩矩的UI表面之下，有一颗灵活多变可编程的核心。对于专业的工作室来说，Maya具大的问题是什么呢？就是还不够灵活。Maya的问题在于虽然提供了足够的扩充方法，但是功能的组织必段按照maya的方式来进行。使用者弄清楚问题的解决方案，还必须把解决方案转化成Maya的模式。所以很多时候，会有削足适履的感觉。Houdini的灵活性在于使用者可以按自己的工作流来使用Houdini。Houdini除了提供强大的支持之外，对工作流程没有限制。因此在许多studio中，Houdini是越来越流行的。许多新人认为houdini的文档不好。你很难从houdini的文档中找到如何做形变的方法，原因是对于像形变这样复杂的问题，是没有统一的方法的。不同人在houdini上试过不同的方法。你想怎么弄，它就能怎么弄，所以新人常常感觉不知道如何弄。二　houdini的特点及学习要领。但对于初学者来说，houdini有着极其陡的学习曲线。原因在于houdini设计得非常透明，将大型三维软件的复杂性全部暴露给了最终用户。虽然houdini也可以像maya似的用几个UI快捷键实现自动化，但houdini并没有将这种复杂性隐藏起来。在运行时会将运行的信息都反馈给用户。初学者一下子看到这么多不懂的东西会觉得非常恐怖。对于高级用户，houdini开源与否差不多。除了一些优化的技巧外，整个houdini的运行机制基本上没有秘密。所以通常使houdini的工作室都有一堆TD跟R&D人在里面玩。老实说，我也很少见CGer一开始学就学houdini的。更多的时候是见到他们学maya之后进了工作室看见高手们在那玩houdini也跟着学的。等到从maya转到houdini之后，问他们如何看maya。他们说：maya设计得不可理喻。一般说来，学习houdini大概会经历四个险段1 UI在哪？我究竟该按哪？2 我觉得学houdini就跟学编程似的。3 我突然发现houdini很强大，但也很逻辑。４这东西不就是个linux嘛。houdini实际上不是一个软件，houdini中有文件系统，有编译器，有脚本语言，有shell，有虚拟机。不仅可以装软件，我还见过人拿houdini当ftp服务器，或是控制起重机。houdini其实是装成软件模样unix操作系统。所以在学习houdini的时候，你就是在学习编程，你就是学习unix下VFX软件的开发和设计。houdini所做的，与其说是提供强大的工具，倒不如说是让软件开发更简捷些。想学houdini其实最难的是理解它的高设计思路。原因在于houdini的设计思想是来源于unix的。对于每天使用windows的人来说，会很不习惯。如果你想深入理解houdini的设计思路，推荐你先去读一读<the art of unix programming>这便是houdini的灵魂。许多设计houdini跟unix是一模一样的。用houdini解决问题的思路也是跟unix一模一样的。学houdini其实是没那么难,问题是要转变思想。学houdini不能像学photoshop似的，靠记住几个强大的虑镜工具。学houdini要从最其本最简单的功能开始学。一旦你弄清楚三维软件中，数据是怎样被操作和流动的了，你就可以随心所欲的玩弄各种技巧。于是乎，你就不再是软件的奴隶。软件只是你手上的玩具。三 Houdini解决问题的基本思路在我看来，maya就像windows。houdini就像unix.主观的感觉是maya跟windows设计得很精明。而houdini跟unix设计得很智慧。maya跟windows像是管理的高手，制定的许多规范。一切按规范来来规规矩矩的。houdini跟unix则是一种抽像和概括的能力，只在一些基本的问题上有规定，给人很大的自由。其中给我印像最深的一种是那种碎片加胶水的结构。另一种就是那种一切皆文件的想法。一个问题是你想作一个文件浏览器。在windows上的做法是写一个大大的程序，不断的改进再加上排序，查找的功能。在unix上不是这样玩的。按unix的思路。这是由四个到5个程序程序协作完成的。一个ls,来负责列出所有的文件名。一个程序sort，负责排序另一个程序view，显示表格。还有一个程序fill，表排好的文件名写到表格里。接下来的问题是这些程序之间如何协作交换数据呢？　通过文件。每一个程序读取文件并将输出写到一个文件中。Ls将输出写的一个文件中ls.out。Sort读ls.out，排序，再将输出写到另一个文件中sort.out。Fill再读排序好文件sort.out，将结果写成表格文件fill.out。View读这个表格fill.out显示在UI中。对于这么简单的工作，如果用户不想操作这么多程序的话，可以通过写个脚本来实现自动化。这便是unix的基本设计思路，实际非常简单。在上面的例子中，所有的.out文件对用户来说都是无用的，存在硬盘上对用户一点意义也没有。于是unix提出了一种优化的设计，叫管线pipe，将一个程序的输出直接导到另一个文件的输入中，所有的交换在内存中进行。上面的程序就成了ls|sort|fill|view.其中|表示管道。其实在unix上， C语言开发的程序非常少。系统中的主要程序都是脚本，整个操作系统的主要行为都是通过脚本来控制的。同样的，脚本也是程序，也可以供其它的脚本调用。脚本也是文件，也可以供其它的脚本读取。程序就是文件数据，文件数据也可以是程序。在houdini中，我们可以把node看成是程序。程序一定是一个文件，所以它有它的完整路径。同样的，程序也一定有输出，所以文件中的数据是即是程序输出的结果。在node之间的联接就像管道一样，一个node的输出就是另一个node的输入。在这一点上，houdini跟maya是不同的。maya的连接表示的是数据，如果一个节点有10个个数据，同另一个节点相连时，就要建立10个联接。如果一个节点要同１０个节点相连，每个节点又有１０个数据的话，就要有１００个连接。houdini的连接只有一条，表示的是文件。一个问题是如果按这样的设计，有多少数据会被传递到下一个节点。另一点是，虽然有许多的节点，但houdini的节点在设计上功能更小更单一。在完成一件工作的时候，许多时要用更多的节点。这其实不是管道设计的问题，这是文件格式设计的问题。深入而准确的说，在底层的数据结构中，houdini传递的是一种字典式的数据结构。每一部分数据都是有名字的。如果将node理解为一个脚本程序的话，可能理解为houdini整个context和符号表都传递下去了。直白的一点说法是，每一份数据都是一个变量的值。当数据从一个节点传到另一个节点时，全部的全局变量都被传递下去了。后一个节点实际上是通过变量名来找数据的。如houdini中，一个tri节点被接到了一个color节点上。tri->color在逻辑上等价于这几个脚本。在建模环璋中，系统会声明一个变量。Snet init:export geo.三角形脚本如下trigeo.add vertex v1geo add vertex v2geo.add vertex v3geo.add face(v1,v2,v3)着色的脚本export geo.color= red当把两个节点联起来之后。Color节点的输出实际上是geo=[v1,v2,v3, f1=[v1,v2,v3]]geo.color=red当然这只是简化的比输，真实情况产生的数据的脚本会理复杂。从这个意义上说，color节点只是向文件中加了一份数据，并没有进行实际的渲染操作。至用户为什么看到了红色的三角形，那是渲染器的事情。当color 被接到渲染器上时。tri->color->render渲染器将color变量的值当成了渲染的颜色.rendercolor=geo.color这就是houdini运行的最基本原理,　其实非常简单。Houdini的灵活性理解了houdini的点基本原理之后，你就解放了。tri->color->render的这种结构实际上是不必要的。color->tri->render的效果跟tri->color->render效果是一样的。也完全可以可以不可color节点。在tri节点中，加一行脚本export geo.color=red.或是在渲染器render之上，加一行启动脚本。Export geo.color=red.同maya相比，houdini要灵活得多。在使用maya的时候，必须通过建产联接来实现数据通信。很多时候，设置像color这样的数据是容易的，但是找到接收color数据的节点却不是那么容易的事。而在houdini中，用户可以不考虑那么多，只要指定颜色就可以了。还可以把color跟tri节点合成一个新的节点叫tricolor。它以tri的ndoe做输入，以color的输出做输出。这在houdini中叫digital asset.对使用者而言，digitl asset跟一般的节点完全一样。使用它会使复杂的houdini工程更清晰。tricolor还是更简单了点，复杂的可能有BuildACity->render.而buildACity内部的节点可能也是digital asset.如果这种觉得这种digital assert的合成节点速度太慢，就可以也用C写一个Node，叫tricolorC.许多开发工作只是从context读取数据，其它的编程跟通常C编程没有什么区别。因此很容易将己有的代码集成到houdini中去。最后houdini的所有节点输出的都是文件。在houdini中，UI中的viewer只是一个几何文件浏览器，可以查看任何节点的输出结果。这样，用户可以看到数据在每个节点操作后的数据的变化。很像调试程序一样，用户可能轻松的找到出问题的地方。houdini的许多行为都是通过变量控制的，这此变量都是脚本shell的变量，同unix其它脚本中声明的变量是一样的。脚本设置的变量是可以被外部程序读取的，同时houdini节点也可能通过管线同外部程序相联。houdini可以很方便的同其它程序协作，许多时候，如修改的渲染器之类的工作，完全可以不需加写插件来实现，改一个变量值的字符串值就可以了。甚至可以说只要能在unix上运行的程序都可以集成到houdini中来。小结：实际上houdini的核心就是一个小型的文件系统加上一个运行脚本虚拟机，就是一个去掉了内核和驱动的unix操作系统。它的文件系统有着跟unix系统类似的逻辑结构，而它的脚本就是修改unix的shell脚本而来。文件系统用来组织脚本，脚本虚拟机负责装载运行脚本程序。虽然都是node结构，用起来跟maya感受很不一样。感觉maya的node好像一个个元器件，使用maya时就好像在连接电路。而houdini的node结构，更像是代码段，使用的时候感觉就像做复制粘贴。两者都很灵活。对于初级用户， maya的UI做得更完整一些，许多时候点个按钮就可以了，但成为高级之后，就会发现maya的node结构很繁锁。houdini的UI功能不强，但node更易用，连接更灵活，调试也更方便，虽然开始时有些困难，一旦习惯了之后，解决许多问题会非常直接和简单。从个人来讲，作者更认为CCer们应该学习houdini。虽然houdini并不是主流，但是这种node结构可能更流行一点。新开发的许多工具，基本上都是houdini的这种数据流结构，比如Nuke。而且多数流水线在设计的时候，都是以文件为单位的数据交换更自然。四：基于python的流水线有些读者可能会问，既然maya和houdini这样的软件己经如此强大了。对工作室来说，如果加入新功能的话，只要写插件就可以了，重新开发流水线是否真的必要。这个问题是非常值得讨论的。是否有意义取决于两个方面，一是应用的价值，一是开发的成本。为了读者意识到自主流水线的意义，不妨想像这样一种情况。假设场景中有许多群众演员类的CG角色。这类动画通常精度要求不高，但是数量巨大。可以从网上的motion 数据库下载大量的动画数据。下载之后发现，数据的作标系有问题。这在CG中是一种常见的情况。比如制作约定时，角色向X方向走，而动画的数据是向Z方向走。或是将角色的动作作一个镜像的变换，将左半身的动作转换到右边身去。如果你是maya用户要问autodesk 公司怎么办，autodesk公司一定要人买一个motion builder。在最好的情况下，软件是现成的。但是可能你要花一段时间开学习motion builder。即便你会用motion builder，处理这样大量的数据你可能还要学motion builder的编程。所以看似简单的事在没有自己的流水线工具的情况下可能做起来并不简单。但从数学原理上，这类问题是极期容易的。如果你能将动画数据导入到矩阵或是一个二组的数据中，全部的操作实只是将数据中的作标都乘一个变换矩阵，或是将几列的动画数据置换一下位置而己。通常只三行程序就够了，强大的语言可能只要一行。所以只要知道数据文件格式，并且有导入导入数据的软件库，许多CG制作中的技术问题都可以简洁而优雅的被解决。对有研发能力的制作工作室来说，数据才是最重要的，流水线的核心功能实际小是读取，解析和保存数据。Asset为核心架构中的文件格式管理第一个问题：开发流水线的主要原因不同的工作室有不同的需求。Cg软件，特别的通用软件，在设计时的目标是在一个软件中完成所有的工作。其中暗含的一个想法是希望所有的工作能由一个人在一部机器上完成。这种设计思路显然不是为团队协作而设计的。在今天的VFX领域，工作不仅不是由一个人在一部机器上完成，更多的时候即便是一份工作也要由许多人，甚至许多团队来完成。工作不仅只限于一部机器上，更多的时候可会分包在太平洋的两端。对于这种规模的协作而言，houdini跟maya这种工具是远远不够的，这种分布的流水线必须有非常强的网络跟数据库支持。对于这种分布式的流水线来说，它们软件架构会更接近google或是amazon这样的网络公司的软件系统。它的核心组织是以数据为中心。在VFX制作中，称之为Asset为核心的结构所说的Asset中心的流水线中，制作不是像普通电影按镜头和故事来组织，而是按制作产生的数据类别来组织，如模型，材质，纹理，动画曲线，灯光。每一个制作人员不是分配给一个或是几个镜头，而是被分配给一个数据资源的制作工作，如建一个模型，画一张纹理。在这种结构的组织下，制作人员的分工更加专业化。制作人员通常并不需要了解制作的全部知识，只要精通一项工作就可以了。对于一个建模师来说，它的工作只需要用到多边型建模工具就可以了，动画，材质和纹理的东西不仅不对他无用，而且在许多时候，是绝对不允许建模师修改的。在另外一些时候，交给建模师修改任务的时候，数据库一定要找到原有的模型数据，必要时要将原模型跟修改后的模型都保存下来备用。这也是为什么采用数据库的原因，在以assert为核心的流水线，对数据的查找，访问权限以及修改版本的管理的功能都被强化了。在这种结构的流水线中，即使使用了maya和houdini这样的工具，数据交换也不是按maya或是houdini的方式来进行。在这样的流水线中，所有的节点都会把关键操作都是写到数据库中，所有关键数据在被操作前，也要从数据库导入。从另外一点来说，maya和hounini的文件格式也不适用于这种架构。maya跟houdini的文件格式在本质上，不是一种数据文件，而是创造场景的脚本程序。这种文件格式也不适合数据库系统来管理跟查找。所以采用以asset为中心的流水线系统，一定要有自己的数据格式，一定要有自己的数据内容规范。而开发的文件格式的转换跟读取，解析以及存储的程序基本就构成了自主开发流水线的中的主要内容。一旦文件格式的问题解决了，应用程序的开发就可以直接操作数据， 而不必再写成maya或是houdini插件的形式。软件的开发在形式上也更加方便。Phython的优点：houdini跟Maya结构很不相同，但新版本都加入了一项功能，就是对python的支持。这是自然而必要的。在VFX技术圈，Python会成为比maya和houdini之类的工具软件更主流的技术。如果读者读完前文也许就会发现，主流GC软件都是脚本加插件的结构。在设计上，我们通常称之为虚拟机的设计模式。也就是说如果一个软件对灵活性要求非常高的话，最好的方法就是设计一问专门的编程语言，让用户自己去编程。这实际上不仅是CG圈，可以说整个IT产业都采用的一种方法。不仅maya，houdini是这样，实际上渲染器，网络济览器也都这种结构。在本质上maya跟houdini都是这样的。它们只不过是除了设计一问专业的编程语言外又加了一个可视化的UI工具而己。从虚拟机的角度讲，功能扩展有两种方式。一种是组合式的，我们称之为脚本或是procedural。另一种是原子式的，通常理解为扩充虚拟机的批令集，我们称之为operator或是node.在以前的架构中，op或是node的扩充是用C＋＋开发的，而上层的脚本是通过修改各种shell脚本而来的。所以开发者同时要用二种语言开发。但今天的phython自身就是虚拟机，phyton足够高级也足够低级。即可以当成脚本用，也可以当成C＋＋来用。并且在集成原有的C＋＋代码方面，phython更容易一些。即便maya跟houdini不提供官方支持，开发人自己加入phython脚本也不难。python的功能非常强，而且可以调用的资源也更多。一旦软件集成了python，系统的所有功能都可以调用。不管是以库函数还是以可执行文件的方式。对于做技术的而言，可以一种语言走天下。甚至可以说，如果有phython，maya跟houdini完全都是不必要的东西。它们的架构己经过时了，只有一些己写好的op还有应用的价值。因此今天的流水线的技术的一种潮流是是在数据库跟网络后台方面，phython和C＋＋为主。在前端的应用软件方面，己经不做大的集成，把从建模到渲染合成的全部放在一个软件中的意义己经越来越小了。但是由于技术的发展，许多控制都开始向后推，目的是为了在后期能够方便的调节视觉效果，在后端集成化越来越强。建模和动画更加独立，而材质，光照，渲染跟合成集成的越来越紧密。无论哪种软件，新软件的都是以python作为虚拟机的主干，用户通过python写脚本，写插件，或是操作其它软件。而对于maya跟houdini来说，大型工作室己经不再专门为之开发插件，在其内部数据库跟流水线之上，以python为核心定义一套脚本跟op插件，形成了一个不带ui的maya或是houdini的软件系统。为方便美工的习惯，为每种专业软件只写一个插件，就是初始化phyton虚拟机环境，将应用软件的数据转换成内部数据格式，然后通过python调用内部己定义好的op。这样做的好处是，无论美工使用maya，houdini还是 nuke，甚至是renderman，都可以调用定义好的op. 工作室根据自己技术开发的特殊op 插件，可以在任何应用软件平台上运行。总结：写这篇小文主要有两个目的，对于应用软件的使用者来说，希望读者能够理解应用软件是如何工作的。而对于学习CG技术的读者来说，作者希望读者读完此文之后在学习过程中能将重心从学习按按钮上移开。在VFX技术中，软件日新月异，学习软件操作是一件没有多大意义的事情。对于艺术类的设计人员来说，最有用的工具永远是铅笔。而对于技术的Cger来说，三维软件中其实没有那么多的技巧之类的东西。核心的问题是数据和操作数据的方法，这才是CG技术中最核心的东西。一旦理解了这一点，软件之前的差别只是按一个不同的按钮而己，或是将一件用另外一种语言或是换一种说法而己。理解了核心问题之后，学习三维软件会变成一件非常简单的事情。你可以花5分看一看软件模块之间是如何交换数据的，再看一下软件的node的参考资料，了解一下软件可以做什么，可能你就知道了软件最有用的九成的信息。而制作中你所展现出来的水平，其实不取决于你知道多少高手的神秘技巧，取决于你的解决问题时的想像力。作者将在后续的文章中，大致介绍一下主要流程中的基本问题跟解决方法的思路。希望读者能明白一个简单的道理，其实不论多强大的计算机，它也只能将简单的事情做许多次。而将复杂的问题转化成简单的问题，恰恰是人最突出的能力。