In recent years, the 3D industry went from very little support of fisheye rendering and now every modern render engine fully embraces it. I think we can thank the rise of VR for helping to shine a light on immersive production.

We recently had a chance to upgrade the render engine that we use in Maya for producing our fulldome shows. We were also able to add some computers to our old 10-node render farm. Many thanks to the Charles Hayden Foundation for the grant that made this vital tech leap possible.

With the recent introduction of GPU render engines, things are a bit more convoluted when considered alongside CPU render engines. Yet each render engine is unique and excels at different aspects, so it makes comparing them tricky work.

And so I thought it would be useful to hear from the fulldome community…

Survey Results: Render Engines in Fulldome

I was curious to see exactly what render engines are currently being used by fulldome producers. So I sent out a survey to a few fulldome listserves and heard back from 49 people. Below are the results.

I was surprised just how spread out the results were. But it does make sense to use whatever render engine is included with your 3D animation software of choice, especially if unlimited render node licenses are freely provided. Although I wasn’t too surprised to see that 29% of people are utilizing Blender Cycles since it’s a free open-source tool that renders on the GPU.

Goodbye Mental Ray

For 9 years we’ve been producing fulldome shows using the Mental Ray render engine. It’s a powerful render engine and we’ve really pushed it to create some beautiful scenes. But we’ve now found ourselves increasingly limited of what it can achieve. For instance we’ve hit a tech ceiling when dealing with things like: displacement map artifacts, very large resolution textures, long GI/FG render times, and fisheye lens shader bugs. I’m thankful that it was a free tool included with Maya, after all it taught me the real nitty-gritty of 3D rendering. But it’s time to modernize so that our art creation process can fully spread its wings.

Although I must say that I still think that Mental Ray is unmatched when it comes to it’s textured fluids implementation. That has proven amazingly useful when creating nebulae. So we might keep Maya 2016 installed on the old 10-node farm just for this, or at least until we see if V-Ray/Phoenix can match it.

Personal Findings: Render Engine Testing

It took a good chunk of time to explore and experiment with some of the various render engines currently on the market. Here is a collection of random thoughts from the process.

• Octane is a GPU renderer. It had decent Maya integration but it gave us some annoying problems right from the start. It is an unbiased engine, so you cannot turn off the GI light bounce, which makes render times longer but easier to make look realistic. Also it doesn’t currently have a fisheye camera option and we really couldn’t afford to always render using the equirectangular camera, so we omitted Octane as an option.
• Arnold is a CPU renderer. It creates amazing renders, but it’s an unbiased render engine, meaning you cannot turn off global illumination and so your render times are always heavier. Yet when rendering scenes of outer space, we ironically just don’t need to have GI light bounce all the time and would rather save that render time. Global views of Earth or spacecraft tumbling through space just don’t require GI and can often be faked with clever lighting. Arnold really is designed for artists that don’t want to worry about tweaking infinite settings and so there are very few settings available. Since we have limited computing power on the farm, we eventually omitted Arnold as an option. Plus it is expensive and you cannot buy a permanent license, it can only be rented annually. But it is interesting to note that they have just started beta testing a GPU version of Arnold.
• Redshift is a GPU renderer. I really can only sing praises of it. Redshift has a tight integration into Maya and the devs are actively looking into bugs. It renders wildly fast, looks realistic, tons of deep dive options for tweaking, and includes fisheye and equirectangular camera options. It is a biased engine, so you can decide whether you want GI light bounce enabled or not. If you render without GI then images crank out very quickly. The render times scale don’t scale linearly when using multiple GPU’s, but limiting to 4 GPU’s for a render seems like the sweet spot. Hopefully that’s something they can improve in the future. Plus the upcoming Redshift v3 promises some pretty amazing features, including Optix for denoising renders. Redshift is offered as a permanent license and you can renew the maintenance contract annually to continue receiving the latest version. Overall my only real gripe is the poor support of Maya Fluids.
• V-Ray is a CPU renderer first in my opinion, and it also includes a GPU renderer that is quite mature. Again I really can only sing praises of it. Some of the GUI options are a little less obvious, but the online documentation is excellent. Phoenix FD is an incredible fluid simulation tool and there is so much to explore. We haven’t quite figured out if it’s possible to connect 3D textures into the fluids, since that has proven immensely useful in creating nebulae with Mental Ray. It is a biased engine, so you can decide whether you want GI light bounce enabled or not. Overall it is similar to Redshift in many of its features. Unfortunately the fisheye camera isn’t yet supported in the GPU engine, so you’d have to rely on hemicube camera for rendering for fulldome. V-Ray is offered as a permanent license or annual rental, and all minor updates are included. When a new major release is unveiled then you can pay an upgrade fee. V-Ray is a solid render engine in every regard.
• Other notes – Since we are dedicated to working in Maya almost exclusively we didn’t consider Blender Cycles. We also skipped over Maxwell since it’s an unbiased engine and also more angled towards CAD software. RenderMan is very powerful but requires a custom lens shader to enable a fisheye camera, but we can’t afford to deal with any edge case bugs. In the past we’ve done some scene-specific rendering in Unity, but it’s Maya integration leaves much to be desired and so we omitted Unity and Unreal as options.

Final Decision

For those of you that are curious, we ended up dipping into both the CPU and GPU worlds by relying on both Redshift and V-Ray. Redshift renders incredibly fast on the GPU, even with global illumination enabled, and that is a game changer for our show productions. Yet we also do a lot of fluid simulations for creating nebulae, supernovae, aurora, and such. So V-Ray & Phoenix FD is already proving versatile for fluid sims and sprite particles. Plus since V-Ray can render on both the CPU and GPU, then that gives us some wiggle room for experimenting in the future. But for now we are juggling between Redshift and V-Ray to determine their true strengths and it remains to be seen if we will end up focusing on just one render engine in the future.

For the render farm, we ended up purchasing 8 CPU nodes and 2 GPU nodes.

• For the CPU nodes, we weighted more heavily towards CPU core count since more threads allows for more concurrent render buckets. Ideally you want the highest CPU speed and largest core count, but having more cores is currently the best way to balance performance vs cost. These are useful for V-Ray, After Effects, and slicing.
• For the GPU nodes, we installed 8 graphics cards into each node. The GeForce RTX 2080 Ti graphics cards pack a serious punch especially since Redshift can utilize up to 8 GPU’s at once.

I’m interested to see how our workflow changes with these new render engines and farm upgrades. Being able to render faster will hopefully mean that we can iterate quicker on scenes, spend less energy on bug fixes, and instead focus on being creative.