RenderMan与CG生产流程简述

比眉伴天荒 2021-12-11 15:39 228阅读 0赞

# RenderMan与CG生产流程简述 #

## 周波 ##

更新日期 2010年11月12日

随着国内CG事业的发展 ，越来越多的人开始学RenderMan，越来越多的公司也逐渐的开始尝试使用RenderMan做片子。我在进入Autodesk前一直在南京的CG公司兼职工作，由于工作需要使用了RenderMan。许多朋友都会问我关于RenderMan的问题，下面是我对在流程中使用RenderMan总结，随着时间的变化我也会更新的，欢迎挑错与提问。

## RenderMan扫盲指引 ##

确切的来说，RenderMan只是PIXAR当年定的一个渲染器标准，而且恰巧，那批人（包括Pat Haranhan）也是设计OpenGL，所以你看RenderMan API和OpenGL API很相像。现在我们经常说的RenderMan，一般来说是PIXAR自己开发自己使用同时也对外出售的PIXAR PhotoRealistic RenderMan渲染器。

RenderMan有哪些公司在用

*  PIXAR

> 毫无疑问，自己家吃饭的玩意。

*  Industrial Light & Magic

> 由于当初和PIXAR分家所签订的条约，使得IL+M可以永远和PIXAR分享RenderMan的源代码。作品无数。

*  Sony Picture Imageworks

> 老作品不说了，最近的比如《Beowolf》《Spiderman 2》《Benjamin Button》等。

*  Weta Studio

> 《King Kong》，还有最近的《Avatar》。其中NVIDIA 为《Avatar》的制作流程开发了基于GPU的外部点云光线跟踪器，也就是那个PantaRay。

*  MPC

> 《Clash of Titans》。MPC开发了Importance Sampling解决方案，应该类似于mental ray的Phenomena。

还有很多公司会在流程中用RenderMan。但是千万不要抱着非RenderMan不用的说法，因为mental ray、VRay有时候也是干活的得力助手，就好比并不是说有了航空母舰就有了一切，你还需要配备重型巡洋舰和核潜艇护卫舰才能发挥航空母舰的威力。

首先说一下，倘若你的流程决定用RenderMan，那么，会基本脚本能力的Shader Writer，或者Technical Director是绝对必不可少的——RenderMan附带的材质极其有限，可以说基本上没用。如果你还能够有高素质的R&D Programmer，那么一切就都很好了，你的流程可以向世界级工作室看齐了，别人为提高流程效率所做的，你也能做。

## RenderMan技术指引 ##

RenderMan主要的特点有

*  易学。科学怪物的玩具可不能给艺术家使用并参与生产。
 *  全面的几何体支持。无论是基本的Polygon Mesh，还是Loop/Catmull-Clark Subdivision、NURBS，Implicit Surface，以及Point与Curve。
 *  极其廉价的displacement、motion blur、DOF。由于REYES的工作机制，使得这三种效果相比光线跟踪器来说要快速的多。
 *  简单易学的Shading Language。相比mental ray，RSL的学习曲线要比mental ray API平和的多，后者更偏向于R&D。
 *  强大的开发支持。

具体的内容可以看PIXAR发布的论文以及文档。尤其是关于RenderMan基础算法的论文，可以让你了解许多底层信息。

## RenderMan购买指引 ##

首先，你能找到的开源实现有Pixie和Aqsis。前者作者貌似已经没了继续开发的动力，后者刚刚出2.0版本。BMRT在民间依旧有流传，不过你要是在商业产品中使用严格来说是违法的行为。Pixie的功能是比较全面的，有光线跟踪，也有Photon Mapping、Irradiance Cache，Point-based Color Bleeding等这些还没过时的技术以用来支持GI。根据我的测试，Pixie比Aqsis效率高。Pixie据说在《Spiderman 2》的流程中使用过。

目前成熟的商业版RenderMan的主要有

*  PIXAR PhotoRealistic RenderMan
 *  3Delight

PRMan前者目前只有13.5的盗版，后者你可以用MAC地址申请一个免费的License。据我所知，国内许多个人和公司都用的破解的PRMan 13.5生产，其中不乏一些叫得出名字的公司。我曾经在流水线中用盗版PRMan 13.5在生产中所碰到的致命问题有，

*  只有32bit版本的破解，无法计算超大规模场景。
 *  光线跟踪不会释放内存，一直到最后程序崩溃。
 *  Slim假死。

对于一套PRMan来说，它由三个部分组成

*  RenderMan ProServer

> RPS，基本的命令行渲染器以及辅助工具。

*  RenderMan for Maya

> 类似于mental ray for Maya的东西，可以在Maya中完成工作的艺术家工具。

*  RenderMan Studio

> 其实就是老一代的RenderMan Artist Tools，它包括

*   *  Alfred。渲染任务管理器。
     *  It。简单而强大的显示服务器，可以看RGBA各个通道的便捷小工具，带序列帧文件管理功能。
     *  Slim。基于tcl\\tk的Shader制作工具，使用起来极其诡异，特别容易崩溃。

对于3Delight来说，则就简单的多，也是由3Delight for Maya的艺术家工具和独立渲染器组成。 3Delight的计算效率和稳定性不如PRMan。但是由于售价便宜，艺术家工具简单易学，所以也可以用。《District 9》的制作据说用的是3Delight。

具体的你可以去PIXAR和3Delight网站去得到更加详细的介绍。

## RenderMan实施指引 ##

软件方面，首先，Maya是必须的。并不是说没有RenderMan for 3dsmax，因为那个玩意年代实在太久远了（名字忘记了）。而且，如果你要用盗版的PRMan 13.5，那么只有对Maya 7、Maya 8.5、Maya 2008的艺术家工具。从Houdini 9开始对RenderMan的支持也越来越好，可以用Python进行开发。

后期软件的话则没有特别要求，Shake和Nuke等等都可以。

硬件方面，则很简单——刀片服务器RenderFarm是最好不过了。台式机搭建的网络曾经我们也测试过，稳定性和刀片服务器根本无法相比，哪怕是用的华硕服务器主板外加ECC内存，也一样没刀片服务器稳定。

## RenderMan开发指引 ##

这一块可以分进阶和高阶两个阶段。进阶主要就是围绕RenderMan本身的开发，高阶指的是开发配合RenderMan渲染器的外部工具。

### Shader ###

首先，写Shader不难，难得并不是什么算法，难的是如何实现想要的效果。这是个可以发挥高度创造性的工作领域，许多时候不仅仅是将论文上的公式写成代码，更多的是写一些达到事半功倍的trick，比如Cook-Torrance BRDF中Beckmann Distribution项的修正（这个是SPI的朋友告诉我的，我不能透露具体做法）。

### DSO ###

DSO分ShaderOp和Procedural DSO。前者主要是在RSL中添加新的函数，比如用GPU读取贴图的函数。后者主要是在运行期生成一些新的几何体，这样可以免去解析RIB的时间与存储空间。

### RifPlugin ###

RifPlugin是Procedural DSO的一个延伸。具体作用就是，在解析RIB的时候，用你写的这个C++类去分析RIB，我们可以对写在RIB中的数据进行操作，本质上是RIB Parser。

Implicit Surface

其实这个东西，说有用也有用，说没用也可以。首先，Implicit Surface运用的地方不是很多，在学术圈内Implicit Surface Modeling相关的主题已经很成熟，但是真正的生产环节这个是没几个人用的。二来，常用的流体解算工具比如Houdini和Realflow求解出的SPH数据多半已经Polygonized，所以再用Implicit Surface替代毫无意义。开发人员晓得这是怎么回事就可以。

### Subsurface Scattering ###

我永远强烈建议开发人员熟读Henrik Wann Jensen的这两篇论文，

*  《A Practical Model for Subsurface Light Transport》
 *  《A Rapid Hierarchical Rendering Technique for Translucent Materials》

如果你不想读论文，在这里我可以用一个等式告诉你根本含义，

*Albedo & Diffuse Mean Free Path = Absorption & Scattering*

这个等式贯穿了整个SSS 的制作方法。虽然Gelato、PRMan 14、OSL都支持了subsurface这个ShaderOp，但是本质上依旧没有脱离这个等式所涵盖的范围。

### Fur ###

这是个最近对于我来说比较热的主题。首先，毛发的建模和动力学解算是个难题，大规模毛发的渲染又是个问题。用Maya+Shave的人那么多，但是却几乎无一例外的用Archive而不是DSO解决问题。毛发的GPU求解已经几乎是必然趋势，Animal Logic有自己的基于GPU的求解工具，SPI也在继续开发类似的系统。大量毛发的运行期生成也是必然，过段时间我会写一个这样的工具。

### PantaRay ###

为什么这个工具被开发，本质上还是因为目前AMD64/EM64T的程序不是真64bit，大规模场景数据依旧无法处理。《Avantar》的主要场景是在森林中，由于森林很庞大几何体数据会极其庞大，有些数据的计算比如Ambient Occlusion的计算无法在程序中完成。于是乎可以将物体的点云输出，在外部计算那些庞大的数据，出Pass的时候在Shader中直接读取计算完成的点云就可以。具体的你可以看今年Siggraph 2010的论文。

转载于:https://www.cnblogs.com/Jedimaster/archive/2010/11/12/1876176.html