渲染农场121.docVIP

渲染农场[专题系列3] – 开发者箴言 在开始前 主要问题：开发者如何从用户需求的角度搭建、开发渲染农场软件。 主要介绍内容：渲染农场的基本概念和未来展望。 关于合作：如果你对开发和设计渲染农场管理软件有兴趣，也可以联系，或Email：yjl424@，我们非常欢迎合作和交流。 …… 软件架构 通常而言，渲染农场必要的部分包括如下三个：任务分发、渲染、文件存储。 任务分发节点，通常被叫做Master、Manager或者Dispather。负责中心调度，接受任务提交、分配、结果回收等。这部分一般做成系统服务，并提供众多控制台接口和网络接口，以便上层GUI调用。因为任务分发是整个系统的中心所在，所以很多其他部分也会放在这里，例如：渲染节点的管理，用户管理，日志等等。 渲染节点，一般被称为Slave、Node、Render Client等。当任务分发节点将任务（Job）分割并分派后，渲染节点是实际运行子任务（Task）的节点。这些节点一般是多核的高端机器，运行在节点上的软件一搬也作为系统服务。如前文所提到的，因为操作系统license的问题，渲染节点支持Linux是一个普遍的需求。 上图是一个常见的渲染农场管理软件架构，各个部件由交换机或者其他网络部件连接。 文件存储节点，叫做File repository。大部分的集群管理软件选择使用了局域网络共享协议，所以会将相关的文件夹共享，用来支持场景读取、图像存储等工作。文件存储节点，可以集成在Master机器上，可以单独的是一台PC机，在重量级的系统中，文件存储是单独的节点，一般为高性能磁盘阵列。 有了上述三个节点，整个系统就可以工作了。当然，用户不希望整个系统的使用沉溺在各种控制台命令之中。任务的提交，进度的查看，错误的分析，这些部分都是系统和用户之间沟通用的。 系统管理，一般叫Monitor、Web Monitor、Explore之类。成熟的系统中，用户界面和底层系统内部逻辑是完全分离的。甚至用户界面都是用脚本配置的，以便于系统的拓展。用户管理系统登录连接上Master机器，读取系统状态。用户关心的内容主要是：任务（Job）排队状态、当前任务运行状态、渲染节点工作状态、任务（Task）分配、结果查询。 渲染器支持 专业渲染管理软件和自带工具的最大区别在于，是否支持各种主流渲染器。举个例子，如果某个工作团队使用Maya做动画，用3DMax做建筑效果，用After Effect做后期合成特效，那么这个渲染农场系统至少要能同时为这三种任务做划分，然后并行渲染。显然，任何一个自带工具（如Vray distributed rendering、Backburner、Maya satellite）都是无法胜任的。 渲染器的支持有几种不同的方法。首先是调用渲染器的控制台程序，其次是用插件的形式在创作工具内部嵌入直接提交的功能。支持三方插件的软件，比如Maya和3DMax，都可以在程序中嵌入任务提交界面。 本质而言，无论支持何种渲染器，都是从调用控制台程序开始的。例如Maya的渲染控制台文件是”Render.exe”，按照Maya的命令行手册调用这个程序，就能在渲染节点渲染某个场景。调用”Render.exe”不会启动用户界面，所以会比较节省计算资源。 多渲染器的支持，需要做接口抽象，将所有渲染器的共同点提取出来。共通点包括：场景文件、起始帧、终止帧、结果存放文件夹等。定义了这些抽象的字段之后，实际上可以支持任意的渲染器，只要渲染器提供了相关的接口。将这些规则做成用户手册，指导用户按照一定的格式自己可以定制新渲染器支持，包括自行开发的渲染器。 任务分割 任务分割是并行发生的基本要素，是从Job细分到Task的过程。单帧量图像渲染，从屏幕空间对图像分割，每一块图像为一个子任务。动画任务由一系列的单帧组成。 屏幕空间的划分，在3DMax的建筑效果渲染任务中比较常见。但不是每一种渲染器都支持屏幕空间的划分，所以，这个特性不是通性，如果在渲染农场管理软件中很好的支持这一功能，有便捷的用户界面支持，也是一种“先进”之处。 更多的情况下，渲染农场处理的是动画任务，大部分的管理软件会把任务直接细分到单帧，也就是说每一个Task是一个动画帧，例如48帧动画中的第2帧就是一个Task。 这样的单帧任务划分方式，在一些应用下会降低整体渲染效率。例如100帧的动画，20台渲染节点，平均每台渲染节点需要处理5帧动画。如果5帧动画作为Task单独渲染，渲染节点需要不断的加载场景，关闭，再加载场景。如果给渲染节点直接分配连续5帧的动画，那么场景只需要加载一次，场景之间的一致性也会较高。 上图是一个10帧任务划分的例子，一种方式是划分为10个单独的Task，另外一种方式，对Task进行了捆绑，当然这种捆绑需要一定的原则。 调