Plausible Shading

RenderMan for Maya introduces a new Maya-native shading system that supports a modern, physically-plausible RenderMan shading workflow. This shading system provides an out-of-the-box, easy-to-use system that supports advanced lighting and shading workflows, including live global illumination and subsurface scattering. Fundamental to the new system is a collection of shading and lighting nodes intended to provide better results than the standard Maya shading nodes, particularly in two very important ways:

• by providing a consistent model for energy transfer (scattering and absorption), and
• by endorsing a physically-based model wherein lights are "infinite".

These nodes take advantage of the newest technologies in RenderMan, including the Physically Plausible Shading methods introduced in PRMan 16, the radiosity cache, and across-the-board improvements to ray tracing performance. From a lighter's perspective, we provide separate light nodes for direct and indirect illumination, as well as an improved area light node.

RenderMan Archives

Prior to RMS 4, users had only two choices for working with RIB, each with certain limitations. By default, when RenderMan for Maya generates RIB for geometry it is emitted as independent RIB archives, referred to in "driver" RIB files, which decorate delayed read archives with shading and attribute state [*]. For an asset like a helicopter, which consists of thousands of small parts, writing those thousands of files to disk can be time consuming. Paying the cost of having thousands of files on disk might be worth it during look-dev, when geometry can be reused while only updating driver RIB files for shader changes. Alternatively, the whole helicopter could be exported as a single "flattened" RIB archive, making it portable and eliminating the cost of any further RIB generation. This has the drawback of baking shading into the RIB archive along with geometry, and not taking advantage of memory savings at render time that delayed read archives offer.

The new RenderMan Archive workflow solves these problems. Geometry is still written as individual RIB files that are referenced as delayed read archives, but they're written together into a single .zip file that also contains driver files for a range of frames, which is now portable, and the driver RIB files no longer contain shading information - that has migrated outside of the driver RIB and the .zip, into RenderMan Look Files. The speed of writing one of these new .zip files is comparable to the speed of writing "flattened" per-frame RIB archives, while retaining the advantages of delayed read archives. And since shading isn't burned into the archive, there is flexibility to change shading by updating RLF files after the .zip has been generated, at any point before and up to rendering.

Furthermore, RenderMan Archives are ideal for re-rendering. For a heavy asset, like a helicopter with thousands of parts the initial cost of writing an archive can be as much as a few minutes. After the archive has been written, though, on subsequent renders pixels should start coming back immediately. This is great for ray-traced re-rendering, where the startup cost can be reduced to almost nothing.

For more about how to use RenderMan Archives, see the RenderMan Archives documentation, or the RenderManArchive QuickStart.

Re-Rendering

RenderMan for Maya supports both the RIS (ray-traced) and REYES modes of re-rendering. Each mode has its particular benefits. Users should consider their needs and choose accordingly.

Both modes support all manner of edits to lights and surface shaders. All light and shader types are supported, including environment lights, as are volumes, hair, lots of geometry, implicit surfaces, and so on. Edits can be made to Maya nodes in the Maya UI or to Slim shaders in Slim, including co-shaders. Baked data can be updated selectively.

The difference is, the REYES re-renderer caches the entire scene (on disk) and applies edits selectively. It incurs an initial bake cost, but allows users to work with extremely complex, heavyweight scenes. The RIS re-renderer, on the other hand, re-renders the entire scene from scratch with every edit to maintain the full and correct results afforded by ray-tracing. Startup is virtually instantaneous and there are no inherent constraints on the class of edits that can be applied to the scene, but the entire scene must fit in memory to achieve "interactive" render times. In general, if you are working within the memory constraints, for example in a lookdev cycle without full set dressing, etc., users will enjoy faster performance and fewer constraints with the RIS re-renderer.