[比较Prman和Mentalray.docVIP

比较Prman和Mental ray 2009-06-21 16:23 原文在此。/showthread.php?s=threadid=33132perpage=15pagenumber=4 我必须发表意见，因为关于Menta ray的讨论中流传着许多错误的概念和明白的错误信息.我在工业光魔工作，这里我们每天都使用Prman和Mental ray。我个人对这两个渲染器分别各有5年的经验。我是使用者、着色器开发者，所以，我能够数着头发告诉你这两个渲染器地问题。.这里是两个渲染器各自的优点和缺点。.1) Mental ray是一个混合渲染器，事实上，从2.0开始，它就是这样的。混合渲染器对Prman是个新的事物，但是，对图形社会则不是新东西。除了Mental ray，Lightwave\Maya等等，都是混合渲染器，而且相当彻底。.这意味着你可以仅仅使用扫描线方式如果ray trace 是不需要的。绝大多数混合渲染器，象Mental ray ，Prman 和Lightwave可以在取样中混合扫描线和ray trace.不好的混合渲染器则做不到或者有可怕的限制（Maya出现在我的脑海中。）..2）Mental ray3确实是一个micropolygon渲染器，而不是基于reyes架构。The talk of not being able to do driven displacements thru the hypershade is just bogus. 不能通过Hypershade驱动置换贴图只是一个假象。Menta?? ray是一个基于物体缓存的Micropolygon(微多边形)架构的渲染器。这一点既有好处也有坏处。（这种算法）物体被分为子物体，而不是小块。（想象屏幕空间和世界空间，我猜想）置换贴图的质量几乎不用羡慕或者完全不用羡慕Prman了。物体缓存也更少象Prman的爆裂Mental ray总是力图最大的占用内存消耗，并且在Ray trace的时候尽量保留更多地三角形在内存中，不象Prman。这一点并不坏，它使ray trace速度更快，但是，如果，你不限定它的内存消耗，它会立刻发现它消耗太多内存。使Ray trace加速的方法是grids或bsp，虽然bsp更是首选。 Mental ray 3.1首次实现（bsp自动）加速。Mental ray 3.2在这个问题上作了更多，并且固化这种结构。现在，我能够证实，目标缓存的架构已经被证明和Prman的Reyes架构一样成功，而且，如果使用ray trace则更加成功。然而，和扫描线相比或者和虽然ray trace，却使用非microploygong 细分的架构相比，光线跟踪微多边形是昂贵的，但是，Mental ray在我曾经尝试的渲染器中仍是最快的。圣诞节期间，我光线跟踪了一个超过一千万个多边形的场景，时间少于2.5小时。不过，当我们处理更加复杂的案子，我会发现瑕疵，我们经常给两家软件商报告需要它们处理的问题.例如，我最近确实发现一个不甚明确的瑕疵：当处理1.2亿个多边形的时候缓存变得泛滥失控，由于重新细分，在技术上变成了1.5亿。使我们惊奇的是，虽然有这样一个瑕疵，渲染器仍然好好的处理了这个场景，虽然时间很长：16个小时。十六个小时处理1.2亿个三角形对我来说，实在是很便宜的，真的。尤其是考虑到让他做绝大多数从新细分的代码是我的，而且没有优化，不象Mental ray的细分代码那样好。3) 细分面。Mental ray提供一个非常全面的，额外销售的细分面程序包。这是一个愚蠢的市场决定。事实上导致了多数连接转化工具不支持他。（译者注：例如Mental ray 1.0 1.5for Maya ）。而且，考虑到它在美国销售，我不清楚，它是否会让Mental ray面临和pixar的法律问题。我们知道，Pixar在细分面技术上有明显的知识产权。它的细分工具箱比Prman在细分类型和结构上更加完整，但是，它没有象prman那样解决细分的bsplines。4）Mental ray的架构被多次并且再次被证明比Prman灵活，而不是相反。我们常常尽量使用Prman完成所有的活，因为我们的流水线更多依据它而建，因为ILM使用它太长了，我们有更多地艺术家熟悉它。但是，SL是很好的，也很友善，但是， Prman仍然缺乏开放性这一点会刺痛我们，如果希望用SL来做一切。在技术上，我们确实有办法合法地Hack 进入Prman的代码。不过呢，我们很少有人能够这样做（从技术上，也从法律上的限制），更多时候，我们没有时间这样做。并且Prman的DSO架构不够成熟。而M