基于python的流水线

有些读者可能会问，既然maya和houdini这样的软件己经如此强大了。
对工作室来说，如果加入新功能的话，只要写插件就可以了，重新开发流水线是否真的必要。
这个问题是非常值得讨论的。
是否有意义取决于两个方面，一是应用的价值，一是开发的成本。
为了读者意识到自主流水线的意义，不妨想像这样一种情况。

单精度浮点数除以65536假设场景中有许多众演员类的CG角。这类动画通常精度要求不高，但是数量巨大。
可以从网上的motion 数据库下载大量的动画数据。
matlab多少个g下载之后发现，数据的作标系有问题。这在CG中是一种常见的情况。
编程软件python怎么读比如制作约定时，角向X方向走，而动画的数据是向Z方向走。sort方法是降序还是升序
或是将角的动作作一个镜像的变换，将左半身的动作转换到右边身去。

如果你是maya用户要问autodesk 公司怎么办，autodesk公司一定要人买一个motion builder。
在最好的情况下，软件是现成的。
但是可能你要花一段时间开学习motion builder。
即便你会用motion builder，处理这样大量的数据你可能还要学motion builder的编程。
所以看似简单的事在没有自己的流水线工具的情况下可能做起来并不简单。

但从数学原理上，这类问题是极期容易的。
如果你能将动画数据导入到矩阵或是一个二组的数据中，
全部的操作实只是将数据中的作标都乘一个变换矩阵，或是将几列的动画数据置换一下位置而己。
通常只三行程序就够了，
强大的语言可能只要一行。
程序员是做什么的一年多所以只要知道数据文件格式，并且有导入导入数据的软件库，许多CG制作中的技术问题都可以简洁而优雅的被解决。



对有研发能力的制作工作室来说，数据才是最重要的，流水线的核心功能实际小是读取，解析和保存数据。






Asset为核心架构中的文件格式管理
第一个问题：开发流水线的主要原因
不同的工作室有不同的需求。
Cg软件，特别的通用软件，在设计时的目标是在一个软件中完成所有的工作。
其中暗含的一个想法是希望所有的工作能由一个人在一部机器上完成。
这种设计思路显然不是为团队协作而设计的。


在今天的VFX领域，工作不仅不是由一个人在一部机器上完成，更多的时候即便是一份工作也要由许多人，甚至许多团队来完成。工作不仅只限于一部机器上，更多的时候可会分包在太平洋的两端。
对于这种规模的协作而言，houdini跟maya这种工具是远远不够的，这种分布的流水线必须有非常强的网络跟数据库支持。

对于这种分布式的流水线来说，它们软件架构会更接近google或是amazon这样的网络公司的软件系统。
c语言输入输出字符串它的核心组织是以数据为中心。
在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＋＋开发的，而上层的脚本是通过修改各种she
ll脚本而来的。
所以开发者同时要用二种语言开发。
但今天的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 插件，可以在任何应用软件平台上运行。

更多教程www.linecg

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。