In case you haven’t been paying attention, Mental Ray is a sinking ship. The announcement by nVidia last year that Mental Images was being reformed as the Advanced Rendering Center was not the death rattle that many depicted it as, but the break in continuity came at a time when confidence in Mental Ray was at an all time low. Users were already greedily eying the competition and the news set off a growing avalanche of defectors. Luma Pictures was among them: last year we made the switch to Solid Angle’s Arnold and it’s been a refreshing experience (more on that to come in future posts). Prior to the switch, I used Mental Ray in production as both a lighter and a developer for over 8 years and it helped us produce some amazing imagery, including the Destroyer and Rainbow Bridge in Marvel’s Thor. Since then, I’ve thought a lot about what went wrong and a bit about what could be done to fix things, and I’ve come to the conclusion that the best way to save a limb may be to cut it off.
Even employees of Mental Images will admit that something has gone terribly astray, but they pin the blame on Autodesk and its failure to provide a quality Mental Ray plugin for Maya. While it is true that the Mayatomr plugin is bloated, crippled bugware, Mental Images must shoulder part of the blame for this: they opted to outsource this crucial task in the first place. While other renderers offer a complete package — renderer, integration, and support — Mental Images opted for an isolationist approach, licensing their tech en masse and outsourcing the 3rd party integration and support.
On paper, the plan seems quite convenient: Mental Images relieves itself of dealing with pesky clients and focuses on writing Mental Ray, while the developers of 3d packages like Maya and 3dsmax get an out-of-box renderer far beyond their manpower and capability to write. Unfortunately, the upshot is that the arrangement isolated Mental Images from user feedback and thus it often produced features that strayed from the mark, while Autodesk provided support and integration for a renderer that it never seemed to fully comprehend. The “man-in-the-middle” support that Autodesk provided has been the source of many headaches for end users trying to get straight answers, cut off from the actual developers of Mental Ray. Did Autodesk drop the ball? Yes. But Mental Images should have heeded the age-old adage: if you want it done right, do it yourself. (do they have this one in germany?)
Recently, Mental Images, now ARC, has finally recognized their flagging reputation (funny how competition does that) and has been more active about reaching out to their customers directly. As we were extricating ourselves from Mental Ray, Mental Images was pushing a new python toolset as a way to tack on functionality missing in Mayatomr. Frankly, this is just polish on a rotten apple, and it stinks of desperation. The new toolset may be gravely needed, but it only furthers the fragmentation of this already woefully fragmented renderer. Mental Ray has a bewildering array of rendering modes — ray trace, scanline, rasterizer, unified sampler, iray — each with their own look and limitations. It’s just a pile of knobs upon knobs upon knobs, some that work with one mode and don’t with others. Maya’s Mental Ray Render Global window puts the dials of a 747 cockpit to shame. As renderers go, Mental Ray is old, and with that age comes some serious baggage. Among other things, what newer renderers like Arnold offer is a clean slate, free of cancerous knobs and liver-spotted rasterizers. And while the news that Mental Ray guru Zap Anderson is heading to Autodesk to work on 3dsmax is good for that camp, it does little to ease industry-wide fears about Maya.
I have little doubt that the Company Formally Known as Mental Images plans to return with conviction in several years with new technology, possibly even a clean break from MR 3.x, that will attempt to leap-frog everyone else. With the current promise of IRay and the GPU expertise of nVidia, it could be quite impressive. In the meantime, they can do little to stem the flow of refugees to V-Ray, Arnold, and even Maxwell. Once it finally ships, how good will the new Ray technology have to be to convince customers to switch back, so soon after leaving? I have not heard a single story of a company that switched from Mental Ray to V-Ray or Arnold and came to regret it. So where will the new customer base come from? Probably not VFX and animation, and judging from IRay (hello, no render layers) and Mental Images’ previous cloud-based archviz initiatives, I don’t think we’re going to be the target market anyway.
Back in the here and now, Maya 2013 was just released and Mayatomr is finally a proper Maya plugin that uses all of the same hooks as other 3rd party renderers — it is no longer a exception to all the rules. While the features that were added to achieve this will benefit all 3rd party integrators, the fact that Autodesk finally made this a priority after almost a decade of Mental Ray being fused at the hip plainly shows their desire to make Maya a more fertile grounds for alternatives to Mental Ray.
I’ve heard a few users clamoring for a cheaper version of Maya sans Mental Ray, and, after a lot of consideration, I think it is a sound idea. With the latest changes in Maya 2013, the technical foundations for the move are finally there, and frankly, everyone would be better off. For the user it’s an obvious win: there is a healthy rendering ecosystem surrounding Maya now, so there are plenty of options to choose from; Maya’s base price would be cheaper, and studios could put the difference toward a renderer that fits their needs and price range. Currently, with Mental Ray bundled with Maya (and 3dsmax and XSi, for that matter) Mental Images has had no clear metric of success: how many of those studios buying Maya licenses are actually using Mental Ray? If the co-licensing umbilical were cut, the company formally known as Mental Images would be forced into direct competition with other renderers, which would hopefully drive them to provide better support and produce a better product (ideally taking over control of, or rewriting, Mayatomr). That’s a big win for everyone. And Autodesk, well, they get happier customers and they can stop wasting their time mucking about with Mayatomr.
FumeFX for Maya Announced
The clever Croatians at Sitni Sati have recently announced that FumeFX will be coming to Maya. I’m proud to say that this is the direct result of a collaboration between Luma Pictures, Digic Pictures, and Sitni Sati.
When Luma was look-dev’ing the stormy “Rainbow Bridge” for Marvels’ Thor, we explored a host of options, including Houdini, Maya, Krakatoa, and the FumeFX plugin for 3dsMax. In terms of achieving great quality in a short amount of time, FumeFX won hands down. However, adopting it at Luma was still a huge point of contention because as a Maya + Linux/OSX studio no one wanted to introduce 3D Studio Max, and least of all Windows, into our pipeline.
Ultimately we bit the bullet and went with FumeFX, but we immediately opened channels with Kresimir, the owner of Sitni Sati and lead developer of FumeFX, to see how far we could push FumeFX in Maya. A FumeFX library for linux, dubbed “voxelflow”, had just been released, but it only exposed enough functionality for rendering, not simulation. It was enough to get started though. I created some basic python bindings for it, and whipped up a python plugin for Maya that could read in a Fume cache and/or .mi file exported from 3Dsmax, load it into Maya, and allow it to be lit and rendered using Mental Ray. Key to all of this, was that it worked on linux and could be rendered on our linux renderfarm with our standard Maya lighting tools. By the end of the show, John Cassella, our lead FX TD, added a C++ plugin for visualizing the voxels within Maya (For more on how we used FumeFX in Thor, check out this interview on the Afterworks site).
It was during this time that I had a conversation with Horvátth Szabolcs who works at Digic Pictures, which had also succumbed to a split Maya/3dsmax pipeline just to use FumeFX. We concocted a plan to ask Kreso if our two studios could team up on the development of a FumeFX plugin for Maya. All Kreso needed to do was provide us with a library and headers that exposed the simulation functionality and some sample code, and we would take it from there. Both studios invested a lot of time and effort writing the Maya plugin while Kreso and team performed a ton of refactoring on their side to transfer as much shared functionality from 3dsmax into the growing voxelflow library. The results? A godsend for smoke & fire work in Maya. As of this writing, there are still a lot of bugs to work out, but the plugin promises what you’d expect: an intuitive interface modeled after the one in 3dsmax with some Maya-friendly tweaks, quick visualization of sims directly in the Maya viewport, and the ability to use both Maya dynamics nodes like fields as well as new Fume-specific ones.
Thus far only Mental Ray is supported for rendering. It took a bit of work to adjust the FumeFX volume shader code to work within Maya’s shading framework (IIRC, to support intersecting volumes, Mayatomr creates a geometry shader that generates a bounding box and a special volume material that evaluates other volumes shaders within it). The result is that you can intermix FumeFX volumes with Maya fluid volumes, if you’re into that sort of thing. Regarding other renderers, Kreso explained to me that all of the renderers in 3dsmax supported by Fume, save Mental Ray, use some kind of a unified shading functionality built into 3dsmax, which allows Fume to produce similar results across these 3dsmax-enabled renderers without the need to write separate shaders for each. This will delay support for renderers like VRay and FinalRender in FumeFX-for-Maya until Kreso has time to write volume shaders for these renderers from scratch. Like Digic, Luma has moved to Arnold for rendering, and the folks over at Solid Angle are hard at work implementing a new sampler optimized for volume rendering, so we look forward to a project soon where these two amazing tools can work together.
