三种renderman规范引擎的dice对比

次表面做的有些烦躁，既然如此，索性先记一下前一阵比较的PIXIE、3delight、prman的dice方式。

研究过reyes的人都知道dice，简而言之，就是为了生成高质量高精度的图片（电影CG），我们把一个grid或者叫patch打散成很多的microPolygon（以下简单记为mp），而每个mp的大小投影到屏幕上甚至小于一个像素（这个是可以设置的，mp的大小大约为一个像素的shadingrate倍）。对于四边网格，dice是很显然的，将grid投影到屏幕上，根据投影后的大小计算在u和v方向上分别需要细分多少份才能满足shadingrate，另外由于内存是有限的，grid的大小（dice之后grid上的点数）有一个用户设置的上限，如果dice后超出该上限，grid需要split成两个新的grid，然后再重复该过程。本文主要讲dice，四边的网格dice没什么好说的，几个引擎都做的差不多。但是，三角网格就需要比较tricky了。我觉得这也是我现在开始讨厌reyes的一个重要原因：总是不能统一的去做事情，三角的细分就不能跟四边的一样。可话又说回来，如果一样了，更是悲哀，比如pixie就是一样的，把三角网格的某个顶点看做长度无限小的边，然后跟四边一样dice，导致的后果就是靠近该点处会有过多的点被dice出来，多余的shade使得渲染速度变慢，而更糟糕的是这种singular会导致其它问题，比如计算dPdu时，发生除0（du为0）的错。3delight和prman采取了tricky的办法，将需要dice的三角形补全为四边形，三角形最长的边即为公共边，然后按四边网格采样，落在原三角形上的即为真正的采样点。

我们先看3delight，上图均为bake点云，然后显示的图。左侧的两图的原几何模型为两个等腰直角三角形，合并起来一个正方形，右侧的图分别展示了这两个三角形，都取非常大的shadingrate。左上角的为插值生成的点，这在bake点云时使用，用每个mp的中心点代表该网格，还包含该网格的亮度、面积、法向等信息。显然我们可以知道两点，一是dice时，边界点是重复计算的，二是插值取点，只取了mp是四条边的网格，边界处的三角形网格未插值取点，所以左上的图有一条大缝。

然后看prman。据我发现，prman与3delight的区别只是插值不同，如下图

prman在边界的三角形的mp上也插值取点了。下面隆重请出PIXIE：

圆盘大小代表面积，这个结果已经是我修改之后的视点无关的dice了，唯一的欠缺是没和前两个引擎那么tricky。

dice分为视点相关和视点无关两种，视点相关的，即细分的程度跟投影到屏幕上的大小相关，近处细分多，远处细分少；而视点无关的细分，只跟物体在世界坐标系内的大小相关，常用于bake点云。前面提到，如果PIXIE的视点相关的dice不够tricky，那么视点无关的dice简直不能直视，我觉得是错的，如下图：

更改之后好很多：

上面两幅图都是插值生成的点，不插值看起来也类似。现在唯一的困惑是3delight插值生成的图有pattern，如下：

但是，修改前的pixie也有类似的pattern，我觉得没道理。pixie有类似pattern，说明这是四边形的grid，四边形grid插值取点怎么能有缝隙呢？

prman和修改后的pixie（视点无关）已经没有该pattern了。

本想好好写篇博，可写着写着就发现乱了，其实不怪我。本身可变因素太多，而且完全正交，三个引擎、视点无关\有关、插值\不插值。

dice并没有多高深的知识在里面，但是dice的好坏会影响渲染的速度甚至质量。

如果有什么认识错误还请指正，虽然我有上面的图做”证据“，但是不少也是瞎猜的。