|Accessing RenderMan from Python|
|script written by Yuichirou Yokomakura|
In a previous post, I complained about Pixar not updating the RenderMan interface specification1. Since then, my wishes have been more than fullfilled because the complete documentation for Pixar products (including past versions) is now online. Just check http://renderman.pixar.com/view/resources. Registration in the forums is required but is free.
Skimming through it, I can measure how far behind is XRT in terms of features. This new release (available in the Downloads section) is an attempt to somewhat fill the gap.
At first, my intent was to simply add a Python binding for the RenderMan interface provided by XRT. Using the ribclients project from Nicholas Yue, I thought it could be a quick development. Alas, I stumbled rapidly on limits and bugs of my current implementation. So, it turned out to be a complete rewrite of everything related to RenderMan in XRT.
I have switched from a bison/flex based implementation to a hand tuned lexer/parser. No only this is more flexible and allows for better error checking but loading files is now 30% faster.
The previous implementation features only an interface to XRT. The new one supports also saving to output to ascii files or strings. Binary output is in the works.
Pixar's Python binding for RenderMan ("PRMan for Python") documentation is rather sketchy. Nevertheless, that was enough to understand that I needed to perform extensive modifications to the original "ribclients" code. I have mostly based my tests on a handful of example files gathered on the Internet. My main sources have been Jon Macey's courseware and Yuichirou Yokomakura blog2.
In most cases, writing a Python binding is just a matter of translating arguments from Python to the target API. There are even tools that automate this kind of tasks, SWIG being probably the most widely known. PRMan for Python follows this pattern except for Procedurals which request procedural callbacks written in Python. My tests are OK but I have not tried enough examples to be completely confident on my implementation.
Misc bits and fixes
- There is now a progress bar in the console so that you know if your render is doing well (or not …).
- CSG operations and transformation stack management are much more robust.
- There is a improved sampler for even better image quality (as explained here).
- RenderMan inline archives and hierarchical subdivision meshes (rendered as simple subdivision meshes) are now supported.
Posted: 10 Jul 2013 22:27
The Pixar folks are not only good at making movies, they have also a team of top-notch engineers who write R&D papers available at the Pixar online library . One of their latest publications is called "Correlated Multi-Jittered Sampling". The happy few who read this blog know that one of my pet subjects is sampling. Therefore, this paper could not pass unnoticed.
Let me remind you of a few concepts about samplers before digging into it1.
A stratified sampler divides the unit square (the area of a pixel, for instance) into equal area cells and position a single sample within each cell. If the sample is at the center of cell, you get an uniform sampler, the simplest but the worst (in terms of aliasing) sampler. If the position is jittered within the cell, you get a stratified jittered sampler. Jittering allows you to trade aliasing for noise but the noise increases when samples get too near from each other in neighbouring cells or adjacent pixels. This is called clumpiness. A well designed sampler will try to preserve stratification and to decrease clumpiness.
There are other types of samplers. Amongst then, low-discrepancy samplers built from quasi-Monte Carlo sequences are the best at decreasing clumpiness but they tend to suffer from correlation artifacts because they are highly deterministic. They also require a degree in mathematics from you. As explained in this post, XRT use these sampling techniques for area lights, soft shadows, glossiness or translucency.
Pixar's paper advocates a variant of stratified sampling that reaches the level of quality of low-discrepancy samplers through smart jittering techniques. Although the article gives ample arguments to proof the validity of correlated multi-jittered sampling, perhaps the best one is the fact that Pixar is confident enough to use it in the latest RenderMan Pro Server. The author has also been kind enough to provide a sample implementation2. I could not refrain myself to give it a try …
Here is a comparison between XRT current sampler (on the left) and the new one (on the right).
Depth of field (magnified 5 times)
Thin lines (magnified 2 times)
Motion blur (magnified 5 times)
This looks really convincing with depth of field effects and thin lines but is only marginally better for motion blur and large edges. To be honest, visually speaking, I see no differences but, when comparing the two pictures as JPEG files, the picture computed with the new sampler compresses slightly better which means there is less noise.
Therefore, correlated multi-jittered sampling will be the new default sampling method in the next version of XRT.