As most of you know Mental Ray comes with Maya and is fairly well integrated. It is principally a biased renderer and comes with two main approaches to GI - final gather and photon mapping. It is possible to do path tracing (unbiased rendering) however there is no GUI integration (which can be alleviated somewhat by third party plug-ins) but ultimately is unwieldy and slow, and certainly not the intended usage of the software. Mental Ray benefits mostly from its long history of development, tested tirelessly in feature film and commercial production for numerous years. One of the byproducts of this is it has excellent optimization acceleration techniques and a proven track record of creating photo-real imagery. The downside to so much development is that in general it requires a fairly broad base of knowledge to efficiently use the software. Fortunately this is being addressed by Autodesk and while recent releases have made significant improvements to the workflow, the substantial learning curve for newer users is still an issue to consider when implementing Mental Ray in the pipeline. http://www.mentalimages.com/

Osario Test Renders using Mental Ray

This section will show various technical tests made using test scenes of the Osario. The test scene was created to give a base example of the general components of a typical scene: High-poly decimated mesh derived from scan data, flora, HDR sky, and various texture inputs. Currently this scene contains around 900,000 polys and the Osario wall maps are 2K each while the grass texture in front of the camera area up to the ruins is 4K. If decimated poly models are being used in the final render the final poly count will likely be an order of magnitude higher while the textures will be closer to 4K. Since we are already familiar with the mental ray basics these tests are more of an advanced test bed to determine specific production options and optimization strategies. For clarity we have listed some of the assuptions made prior to testing. For starters we are strictly using Final Gather as our GI solution, as emitting photons doesn't gain much in an scene that only has the photon bounce one or two times before it disappears into the sky forever. Within the Final Gather scheme we are employing basic techniques for dealing with flickering, such as creating a final gather map cache file, adding additional final gather points to complex areas such as the tree and turning off certain final gather properties on a per object basis. As for shader properties we are starting with the mia_architecture shader to keep all materials physically accurate for calculations and using the snu/sky system to approximate the correct lumens for sunset. We are then adding the sky imagery via compositing.

render test v04

On our first test here we are employing what is known as a 'linear color workflow' to see if that will reduce time artists are having to fine tune shader and lighting parameters in 3D. As a footnote we are facing a production situation with extremely limited resources (people and time) and so one of the considerations in choice of renderer must be 'ease of use' for artists with limited to no prior experience in that software. For Mental Ray this is going to be a challenge, as I mentioned the knowledge base is fairly broad. So the essence of this test is to basically dump all the textures, shaders and lighting into the scene and deal with fine tuning it in post, which should be faster. So what is a 'linear color workflow'? Basically it is the idea that all inputs and outputs are kept in linear color space in comparison to having them processed with a gamma correction which is compensating for the gamma correction happening on your monitor (2.2 for PC, 1.8 for Mac), thus introducing 'guess work' as to what 'looks' right. Mental Ray natively processes everything in linear color space already, so the main things we need to do are 'de-gamma' our textures (on a PC apply a gamma node and set to .455) and make sure our output is also set to a format that handles linear color space. The details of the process (how and why) are too lengthy for this wiki posting but can be expanded upon elsewhere. The end result of test one here is not however completely accurate due to two reasons. First is that I hadn't properly understood all the settings on the 'simple_exposure' lens shader, and had left an attribute on that I thought was being cancelled out, thus affecting the color space. Better would have been to just disconnect it all together. Second thing is related to the shader on the stone, where I was trying to use scalar maps derived from the luminance of the image to affect the glossy reflection and BRDF inputs amongst other parameters. In general the parameters need more testing, as the first test is losing detail. I feel that this needs one more test to properly assess the linear workflow option. After that should just be a 'what you see is what you get' test. Finally although we are showing here one pass renders, it is assumed that we will be breaking these down into respective passes and layers.

render test v03 quicktime movie(17.8MB)