Editor’s note: One of our main goals moving forward is to continue to expand our coverage of the industry and, in turn, our editorial voice. We’re thrilled to bring you the first article by our new contributor Sekani Solomon.
Having been a C4D user for the past seven years, I’ve seen the render landscape transform drastically, especially in the last few. When I began my C4D render journey, render selection was simple, you either choose Cinema’s built in renders (standard or physical) or Vray. Fast forward to 2017, you have several renderers to choose from. These include Arnold, Octane, Redshift, Cycles, Corona, Maxwell and Maxon’s upcoming AMD Pro Render, with the first three being the most popular of the bunch. While ultimately beneficial to the end user, choosing the right render tool can be a bit confusing for a newer artist and studios in general.
For this discussion, we’ll be chatting with Greyscalegorilla’s very own render guru and former Digital Kitchen Creative Director, Chad Ashley. We’ll take a look at Arnold, Octane, Redshift, Cycles, Physical Render and break them down in terms of their Speed of convergence(ability to turn around a render), image quality and production features/scalability and also who we think they are best suited for.
Who is Chad?
For those who may not be familiar with you and your work Chad, can you give us a brief background with your experience with rendering?
I’ve always had a love for 3D rendering. I guess it stems from my love of film/fine-art and my formal education. My drawing skills were always far from perfect (very far), so 3D rendering allowed me to create engaging visuals without having to pick up a pencil or paintbrush. I took to it immediately.
One of the reasons I made the switch to Cinema 4D from 3ds Max was the abundance of rendering choices coming up. As I learned Cinema, my love for third party rendering grew into somewhat of an obsession. Then, as the Greyscalegorilla Podcast started up, we began joking about all these renderers and lovingly referred to the situation as “The Render Wars.”
Before we jump in, I wanted to state that my opinions are all from my POV. A point of view that is founded in need to create production quality animations (mostly photo real) on time and on budget and hopefully with little to no issues. Not all of this info will apply to you, but there is still plenty of crossover in requirements when choosing an engine.
Arnold
Let’s begin our render discussion with Arnold (one of your personal favorites I know). It seems to be quite popular with larger shops for it’s robust, reliable pipeline tools, ability to handle insane amounts of geo and photo realistic render quality. Can you speak more to this?
Arnold is currently a CPU renderer (a GPU version has been teased and is coming soon) that has been around for over 15 years and has been used in many fully animated feature films as well as it’s been THE renderer for many high-end film VFX shops. When you have a production renderer that’s been battle tested for as long as Arnold has, coupled with a solid development team, you end up with a renderer that is tough to beat.
The speed of convergence:
Because Arnold is currently a CPU only renderer, it sometimes gets a bad rap from motion designers who come from Octane, saying it’s “too slow.” Though admittedly Octane is faster, the problem usually stems from someone who built a machine with moderate CPU specs choosing to spend their cash on GPU. I guarantee if those same folks invested the same amount of money into their CPUs, speeds will be become faster and at times comparable. I always say that Arnold is fast for a CPU renderer. If you understand how it works and how to optimize for it, it’s speed will surprise you.
Image Quality:
Extremely high-quality images are possible with Arnold. If you’ve seen any summer blockbusters over the past five years (Gravity or Guardians of the Galaxy are a fine examples) you’ve already seen what it’s capable of. It’s a hybrid biased/un-biased renderer with a very cinematic look. It’s also extremely predictable (this is good).
Production features:
C4DtoA (Arnold’s Cinema 4D Plugin) rules in this category. No other renderer that I’ve tested has as many production features. Full AOV (multipasses) workflows, light groups, LPE’s (Light Path Expressions), and tons of click saving goodies. That on top of rock solid stability makes it perfect for getting shit done.
Who would I recommend Arnold to?
I recommend it to those individuals/studios who demand high-quality images and who value stability. Arnold is also perfect for those who are not quite ready for GPU rendering but are looking for something beyond the Physical renderer in Cinema 4D. It’s also ideal for individuals or studios that have not yet made the switch to PC as Arnold will run on either Mac or PC. If you are an individual artist or a studio running lots of different sort of jobs (volumes, particles, large data sets) Arnold is the right choice for you. If you are studio with mixed 3D host applications Arnold’s proprietary .ass format is interchangeable which can be a great benefit. Arnold coupled with render farm solutions out there such as Pixel Plow is a potent combination. Arnold and cloud rendering gives small studios and independent artists as much firepower as most large studios. All things considered, Arnold is one of my most recommended renderers.
Strengths:
Killer development team, Deep feature set, Custom AOV’s, Light Groups, LPE, frequent C4D plugin updates, simple settings, x-particle support, supports both Mac/PC, same engine in multiple host applications, scalability, stability, Many speed enhancing short-cuts and workflows
Weaknesses:
Expensive (compared to competitors), confusing license system, CPU only, Slow compared to most GPU renderers, owned by Autodesk (bad track record of acquisitions), poor choice for interior rendering, caustics.
Octane
Next up we have Octane, which was my first introduction to GPU rendering. Coming from V-ray where you had to wait minutes to get render feedback, having the ability to get feedback instantly was a significant evolution in my work process. Talk to us about your experience with the renderer.
When I first used Octane, I was blown away at the sheer speed of the IPR ( the IPR being a fast, progressively rendered preview of your 3D image). In fact, it still astounds me. Over time the thrill of the IPR speed faded, and I was frustrated with problem after problem in trying to use it in production. All that speed came at the cost of flexibility, features, and an inability to scale. These are not tolerable issues for advanced CG artists and power users delivering large CG jobs with a small team and tight deadlines. So, my use of Octane trickled down to a drip.
OTOY as a company has been falling out of favor to motion designers as well. On the Siggraph show floor this year, numerous motion designers vented to me about various frustrations with the company. Years of ignoring requests and not making good on promises have left many Cinema 4D Octane users very frustrated. Though some of the more vocal user base is frustrated, I continue to see great projects utilizing Octane and pushing it to its limits.
The speed of convergence:
If there is one thing Octane has, it’s speed (in most situations and mostly regarding its IPR). The more Cuda Cores (Nvidia GPUs), the faster it’ll go. But this criteria is not just about speed; it’s about speed to converge on a clean image. That is always a tricky thing in Octane. If it’s a simple scene with moderate lighting complexity, it can usually converge on a clean image rather quickly (assuming you have more than one GPU). It’s when you push Octane just over that moderate threshold where it gets tricky for it to converge. Ever hear an Octane user complain about fireflies or small lights with atmosphere?
Image quality:
I’ve not heard anyone complain about the quality of a finished Octane animation or render. It does photorealism very fast and simply. It’s not the most accurate or easy to predict renderer out there, but it can quickly deliver nice looking frames. As image quality is subjective, I’d say that I can usually spot an Octane render with better than average consistency. Not because of any “look” or distinct flaws but usually, the subject matter is the dead give away. Because of its many limitations, many Octane renders fall into the category of “object in a void.” There are plenty of fantastic examples of non-void Octane renders. The majority of these examples tend to be stills. You don’t see as many animated Architecture interiors being rendered or intricate pieces where Octane is utilized. This is not without good reason.
Production features:
In my opinion, production features are the Achilles heel of Octane. It lacks even the most fundamental production features such as not being able to exclude/include an object from a light source. I’ve found it to have less impressive production features overall, but I will say that I do enjoy its node editor more than those who use C4D’s built in Xpresso UI. But an excellent node editor does not make up for the huge list of production flaws in Octane.
Who would I recommend Octane to?
I think Octane is perfect for an art-director that is designing frames or doing basic look dev. It’s fast IPR, and simple UI will make it easy for a designer to create imagery, given they have the GPU power to run it efficiently. I’ve seen Art Directors have great success with Octane. Do boards with Octane, then move to a production renderer to finish the job. Octane is also useful as a “daily render” tool. I’ve often joked on our podcast that Octane should have a “send to Instagram” button as it seems to be used more on that platform than any other. Not sure if that’s good or bad. Up to you, I guess. I should also add that Octane is a fine choice for those doing primarily exterior architecture renders.
Strengths:
Easy photorealism, IPR Speed, IPR window features, speed of rendering (up to a certain level of complexity), simple settings, custom material node interface, Octane Scatter Utility, tri-planar mapping
Weaknesses:
Limited by GPU memory, Stability, scalability, no custom AOVs, no light linking, inconsistent/delayed updates, limited maps/materials, layering multiple materials is cumbersome, “Octane Effect” (see GSG Podcast).
Redshift
Redshift seems to be the new kid on the block. Personally, it’s my favorite render right now. It combines the speed of Octane with the production flexibility of Arnold and V-ray. It bridges the best of both worlds. What’re your thoughts of this renderer?
Redshift is the new GPU renderer I’m most likely to recommend to artists right now. I had first become aware of it a couple of years back when it came out for Maya and was very intrigued by the idea of a biased GPU renderer with unified sampling, something I loved about V-Ray in 3ds Max. The images I saw out of it were also gorgeous.
As soon as the alpha was available for C4D, I joined up. Since then, I’ve been testing and helping to shape the plugin with the Redshift team. It’s been a blast watching it take shape. Plus, now Pixel Plow announced it is now supporting Redshift making it an excellent choice for the individual artist or studio.
The speed of convergence:
Because Redshift is a biased renderer and it features unified sampling, it is the fastest GPU renderer I’ve ever tested. The beauty of biased with unified sampling is that Redshift can drastically reduce samples in areas of the image that don’t need it and focus all of its power on areas of the frame that does. Or, if you’d like to put samples exactly where they make the most impact (lights, specular glossy, etc.) you can make renders scream.
Image quality:
Next to Arnold, Redshift is my favorite looking renderer. It has a natural sexy raw look (drops filtering) and features photographic controls that offer you just enough control over the look but not as heavy handed as Octane’s Camera Imager. The SSS is beautiful and natural. It has a realistic, clean look with very little grain and the atmospherics look superb and have minimal impact on render times.
Production features:
Redshift touts itself as a final frame production renderer so it should be no surprise that it excels in traits that will help you get stuff done. I often tell people that Redshift is like Octane and V-Ray (3ds Max Version) had a baby. A speedy/affordable baby. Take the speed of Octane and the feature set of an Arnold put it on Nvidia GPU’s, and you’ve got Redshift. Oh, and only charge $500 for access to the plugin from any 3D host application. It’s also worth mentioning their Proxy and Instance workflows. The Redshift proxy file works very much like Arnold’s .ass file (with a much less ridiculous name).
Who would I recommend Redshift to?
I recommend Redshift to anyone running Nvidia GPU’s and who is looking for a stable production renderer and isn’t afraid to jump into some settings to squeeze out every ounce of speed out of your frames. It’s very well rounded and versatile able to handle arch-viz interiors, intricate character work, product viz, or complex VFX.
Strengths:
Balances load between CPU and GPU, Very Fast, production focused features, biased engine, unified sampling, great uber shader, tons of map types, and a responsive development team dedicated that shows up on forums and answers questions, Redshift Proxies/Instances, and X-Particles support is growing.
Weaknesses:
AOV workflow is convoluted, no ability to texture lights beyond images, not as many useful utility nodes as other choices, no support for X-Particles trails (or splines at all), higher learning curve (Redshift is still in alpha and many of these features are on the roadmap to be implemented).
Cycles
Then we have Cycles. This is the only one from the pack I haven’t really played with. It sells itself on its great integration with X particles.
I only became aware of Cycles when Insydium began their integration plugin for it a while back. I had seen some things in the press about it, but honestly never looked at it seriously until recently. All I had known until then is that it was part of Blender which is a free open source 3d application that’s been around for some time.
I will say, Insydium created a robust and fluid integration into Cycles, tying it deeply with their highly successful X-Particles plugin.The things I’ve seen Mario Tran Phuc do with it are astounding, but the integration is not where the issues lie with Cycles4D. The issues are foggier and not always technical.
The speed of convergence:
From what I’ve tested and seen, Cycles4D’s ability to converge on a clean grain-free image is slower than Octane and Redshift. I’ve also had a hard time in my early tests getting it to clean up a very high-frequency grain that always plagued my renders. I’ve seen that it has improved significantly since then, so this may no longer be an issue.
Image quality:
To check the quality of Cycles4D, all you need to do is see the amazing work by Insydium’s own Mario Tran Phuc. He proves that this engine is entirely capable of making stunning images. Though I must admit, outside of X-Particles renders I’ve not seen an abundance of killer examples. I’m not sure if this is due to the renderers limitations or because the C4D plugin is doing very much what it was designed to do. Become the best renderer for X-Particles.
Production features:
Cycles4D does not lack features. Let’s get that out of the way right now. The node based material editor designed by Insydium is a dream to navigate, and other render engines could take a few pointers here. Cycles has plenty of maps, knobs, and features though not as fully developed as some of its competitors (Arnold, Redshift).
Who would I recommend Cycles4D to?
Anyone who’s work is primarily X-Particles based would benefit from Cycles4D. It’s CPU/GPU flexibility, and low price would make it an excellent choice for those on limited hardware/budget.
Strengths:
Works both on CPU and GPU, tons of features for rendering X-Particles, affordable, great node material editor, plenty of learning resources.
Weaknesses:
Cycles is developed by the Blender Foundation and not Insydium. The open source nature can scare large studios who are looking for deep customer support and accountability. I’ve found that it also a bit cumbersome on seemingly simple shading/lighting tasks. AOV’s are also a bit lacking.
Physical Render
Lastly, we have the Physical render. I know artists like Jeremy Cox that swear by it. It’s free as it ships with Cinema and quite reliable. For me though, it can be pretty slow when it comes to making things photorealistic.
Contrary to what most people think, Physical is a fast and capable CPU renderer and a great in-application engine (running on both Mac/PC). It’s a bit confusing to get the settings right, and the lack of a node based material editor makes it fairly limiting, but all in all, you can still deliver great looking images with it.
The introduction to Reflectance brought the ability to layer shading/specular models uniquely, but often increases render times. As convenient as a built in render engine can be, however, once you’ve tasted the real-time IPR of Redshift, Arnold, Octane or the likes, it’s nearly impossible to go back.
The speed of convergence:
Probably the worst performer in the bunch in the speed category. There are methods to optimize (we’ve done our fair share of tutorials on the subject), but you cannot avoid the fact that Physical is a CPU renderer that just isn’t quick.
Image quality:
The Physical renderer looks fantastic. No one would ever doubt it’s quality (especially if you’re not cutting too many corners with optimization). I enjoy its overall look and find it very similar to Arnold. Must be a Monte Carlo thing.
Production features:
Well, Physical is hard to beat in this category (sort of). It’s built into the core of Cinema 4D for crying out loud. You get all the standard maps and noises, materials display correctly in the viewport, and it’s all very intuitive. Still, it’s features are outdated. No node based material editor, no true tri-planar mapping, no curvature map (and sorry, inverse AO is NOT true a curvature map), no custom AOV’s, I could go on and on here, but you get the point.
Who would I recommend Physical to?
I suggest you stick with Physical if you are tied down by hardware/OS and haven’t a budget to upgrade to anything else. It’s also entirely satisfactory if you don’t find yourself rendering any complex photo-realistic animations on a regular basis. It’s quite adequate on stills and can even handle distributed rendering with TeamRender to Picture Viewer.
Strengths:
Built into the core of Cinema 4D, tons of tutorials out there (wink-wink), good representation of materials in the viewport, great for stills, reflectance is quite robust, awesome noise maps.
Weaknesses:
Slow, No IPR, lacks strong pass (AOV) system, needs node material editor, no curvature map, no real tri-planar map, not receiving regular updates, lights are in need of a serious upgrade, no dome light.
Final Thoughts
Do you have any final thoughts on the topic? Do you see any of these renderers dominating like V-ray once did?
I think this is an exciting time to be a part of this industry. Even five years ago the choices in rendering made the entire process painful and expensive. Now depending on the work, you do and your hardware situation there are now many options for you to check out. I want to end by saying thank you for giving me the opportunity to share what I’ve learned. My findings and thoughts are just that, mine. I urge everyone reading this article to look at the work you are making and try the renderers that make sense for you.
Also, be sure to visit Greyscalegorilla.com and check out our tools, training, and plugins for all things motion design. We also have the Greyscalegorilla Podcast, a weekly show that will keep you up to date on all this stuff. You can find it on iTunes and Google Play. If you are interested in keeping up with the render wars, Be sure to check out our page called “What Renderer should I Use?” which we are keeping up to date as new information and new renderers pop up. You can also find me on twitter at @cgpov.
Thanks for sharing this information, Chad. We tend to have these discussions amongst ourselves almost daily and it’s awesome to share this with the community. At the end of the day, we all win, as everyone is racing to make the tools better for the artist.