Particle Deathmatch: Arnold vs. Vray for Maya!

***UPDATED 11/16/2013*** Link to scene files at the bottom of the article!

Today we settle once and for all which render engine will reign supreme over the world of non traditional particle renderers! Exciting, I know.

We began this journey a few weeks back when the question was raised, “Why not render our particle simulations in Vray/Arnold?”. It’s been well documented that traditionally something like Krakatoa or Renderman would be the first choice to handle large scale particle simulations, but why not Vray/Arnold? Over the last few weeks I’ve done extensive benchmarking, using the same 5 million particle count nParticle simulation as a constant, and I have discovered there is a great deal of nuance with both render engines. Let’s begin with a nice montage…

As you can see in graphic 1a the Arnold particles look a bit more sandy or granular, but Arnold is faster at smaller motion blur levels than Vray by almost half. The motion blur is there, but it is not reacting as strongly as the Vray render at this sample quality. The Vray render is slightly thinner as the Arnold render retains more of the particle density, but overall the Vray render has a smoother more evenly blended motion blur. This motion blur however causes the Vray render to lose a bit of the finer detail in the more dense areas. The colors also tend to bleed a bit on the Vray render due to the more active motion blur and thinner render. Overall at this level of sampling the Arnold render is far more efficient and has more detail, but the Vray version has a smoother quality overall. We will find though that as the motion blur and sampling increases in later examples, the roles will reverse.

In this example the Arnold version rendered fast with a high level of detail and particle density. The Vray render showed better performance being rendered as points as compared to Particle spheres, but a great deal of particle density was lost. Once again the Vray render has far less fine detail, and again has at least 25% less particle density as compared to the Arnold render. Both rednerers showed an increase in performance when it came to a slightly higher motion blur factor, in this case a factor of 3, and this is because both packages render more efficiently when motion blur or depth of field are enabled because they do not over sample the pixels that are being blurred. So you can get away with slightly increasing the quality when you push your post effects to stronger values. (within reason!)

Head to Head Speed vs Quality: Hi-Res

Graphic 3a represents:

Arnold
Sampling 8/1/1/0
Motion Blur value of 3, with a Step of 3
Particles rendered as Spheres with a radius of .01
Total Render Time: 1 hours and 22 minutes

In this example both renderers scored high marks in terms of density and fine detail, with the Arnold render having a slight edge in overall detail. The high AA samples used to smooth out the aliasing in the Arnold version created a much slower render time compared to Vray, but honestly the sample version of 4/4/2/0 in graphic 2a looks just as good as the 8/1/1/0 version of 3a. This can be seen in graphics 5a/5b so setting the AA samples this high would be overkill and unnecessary in my opinion. I cranked up the overall sampling for both Vray and Arnold in this example to see how far you could push it before the renders become unreasonable. Considering this, the 23 minute render of graphic 2a vs the 7 minute render of graphic 3b seems to be a more fair comparison, and it would be up to you to decide if the added detail is worth the extra time. However the Arnold versions colors are a bit more vibrant as the light is more accurately scattered throughout the particles. Naturally these sorts of things can be graded out in Nuke, but it is still worth noting that the Arnold render handles light in a more physically accurate way lending itself towards a finer detail at the expense of render time.

Vray Vs. Vray & Arnold VS. Arnold

In these last examples we pit Hi res vs. Medium Res against themselves for both renderers. In each case you can judge for yourself what level of detail works best for you and the needs of your project vs. the amount of render time it will take.

And the Winner is!!!!!!!

You!!! No matter what package you chose to use you’ll be able to get beautiful renders. Sure the Vray renders were faster on average, but the level of detail was slightly under that of the Arnold render so I call it a wash. You can pull a finer level of detail from the Arnold renders, but it will definitely come at a price. In either case your experience with these packages will come down to your ability to optimize, and streamline your own renders.

For my money on the Arnold side of things I’d say the Arnold point render with a medium quality setting is virtually identical to the Hi-Res Arnold Particle Sphere render at a savings of about an hour a frame. If you are working for a single still shot than by all means crank up the AA samples with the particle spheres and you will get a level of detail that is unmatched, but if a speed/quality balance is the key then particle point render is for you!

As for Vray the speed of the point render with a medium/hi quality is blazing fast, but you’ll need to compensate for the loss of cloud density. I’d say if you want the look of a 5 million particle sphere render with points, jack your particle count up to about 7 to 8 million. Your render will be slightly slower, but you have plenty of wiggle room to buy yourself some extra detail.

***update*** 11/16/2013

I’m happy to say that there has been a tidal wave of interest in this little experiment from around the globe as we have received over 25,000 hits to this article in the first week! We really appreciate all the feedback, and the exchange of ideas! Please keep it coming!

We at MAXDEPTH believe that there will always be many roads that can lead you to your destination, and we’re here to present you with options. Just because we may have illustrated a particular technique or set of render settings does not mean that alternative configurations would not also prove successful. We do these types of tests in the spirit of collaboration, and to promote the exchanging of ideas. In that sentiment I would like to address one frequent topic of discussion about this article. The title of “Particle Deathmatch” was always intended to be tongue in cheek. The heart of this test was never meant to declare a winner or a loser, but rather to illustrate the point that BOTH of these great render engines can be used for more than you might think. I personally love and use both Vray and Arnold on a daily basis, and I see them both as being useful tools for specific jobs. I’m not interested in taking sides as I love them both, and believe in the quality of each. This article was always about showing that no matter which way you go, you’ll be in a great position to achieve amazing results!

Things to consider:

You can use IPR to look dev your particles with Arnold, but you cannot with Vray. This point factored into my decision to call the battle a draw, because while the render time of an Arnold render is slower, the actual time it takes you to set up your shot is much faster with Arnold.

The Vray Particle Sphere render option at Hi-Res can sometimes show itself to be a bit unstable. Numerous times a render would blaze through until it reached about 90%, then it would hang on some small corner of minutia in the render for hours. For example….

Be mindful of this, and keep an eye on your render logs. If you see nodes getting stuck at 90% this is probably the problem. I’ve found that increasing the “Dynamic System Memory” in the settings tab can help alleviate this problem, but it does not work every time. If you find a frame that just wont clear, try directing it towards one of your faster machines, or spot render it locally on a machine that you can control with a render region. Not the most pleasing solution, but if you have to hit a deadline you’ll need to get creative!!!

Optimization:

A few key things to remember for both Arnold and Vray, if you used a fluid container to advect your particle simulation, you must hide the fluid container once you have cached your particles. Even if your particles are cached and the container is not being used to calculate anything, Maya will still calculate rays passing through the volume which is a complete waste of render computation. Leaving this container active caused up to a few hours to be added to previous benchmark renders. HIDE IT!!!!

For Arnold, select your particles, and go into the Arnold tab on the particle shape node and uncheck the “interpolate motion blur” tick box. The Arnold documentation as of 11/13/13 tells you to do this for Realflow particles, but it is necessary for Maya nParticles as well. Also set the “min pixel width” to something like .05.

I hope you found this tutorial helpful, and ask that you please like us on facebook at facebook.com/maxdepthvfx and follow us on twitter @themaxdepth for up to the minute information on new tutorial releases.

SHARING IS CARING:

Due to popular demand we are releasing the scene files for both the Arnold and the Vray version of this test. So feel free to run your own simulation, and remember to follow the directions in the optimization section of this article !! In fact, send us a .jpg and we will create a user gallery where you can compare and share your results with the MAXDEPTH community. Please send your renders, and any information you would like to share with the group to admin@maxdepth.tv

PS. Frame 105 of the simulation is the one we used for the benchmark if you want to stay consistent with our examples. I have also uploaded a zip file with a portion of my particle cache so you can match my render exactly. Keep in mind that if you create your own fresh cache it will inherently be slightly different from mine as this is set up to be a dynamically generated sim that will be different each time. Also be sure to render using the “renderCAM2” and not the default perspective camera if you want to match my Render. For those not familiar with this workflow, please load the scene, select the particle node in the outliner, then go to the nCache menu and select “Attach existing cache”. Then select the .xml, and you are all set to match my render. Also if you create your own simulation please remember to turn off the visibility of your fluid container, or your renders will go from minutes to hours!! Enjoy!

Of course! I sent a number of emails to Deyan a week or two ago, perhaps the one with the maya scene got stopped by a spam filter for having an attached file? I would love to have your input on any possible optimizations. I was hoping you would reach out! I will send you the file as well as information on a few problems I have encountered during these trials. Just give me a few hours its very early in the morning here in LA, and I need a coffee!

I’m currently working with the good people at Solid Angle to optimize this benchmark, and I will be posting the updated results in a few days. I expect the render times to drop dramatically given their current input, as already the Arnold example with sample setting 4/4/2/0 dropped in render time from 1 hour and 22 minutes, to 24 minutes! Quite the optimization!

Absolutely! Some of the optimizations suggested by Solid Angle were not in the current documentation though, so we benchmarked with what we believed to be the most up to date information available. I will be describing in detail the steps taken to decrease the render times when I can update the article.

Absolutely, I’m working on an update now with a few optimizations I was informed about by Solid Angle that were not in the documentation that have decreased the render times dramatically. So far it’s lopped off an hour from example 2a, and 4 hours from 3a!!!! Very exciting!

Hey, no offence but all of the tests are meaningless. The way to test/compare them is to tweak each engine until the output looks exactly the same as a reference point.. then you will get some meaningful data, having said that. I’d love to see this sim/test redone, with outputs as close as can be tweaked reasonably.

Hi Matt, There will definitely be opportunity to run additional testing, but saying that this test was meaningless is a bit heavy handed. We had a specific set of variables we set out to test for, and we got the results that WE intended to find. I think you are comparing apples to oranges, but I respect your opinion. What you are suggesting is just another benchmark with a different set of variables and end goal, which is fine, but that in no way makes this test meaningless. At least not to the guy that spent many a night emailing back and forth with Solid Angle in the wee hours of the morning to bring you the most accurate information possible on my own time and my own dime. 🙂

Hey, thanks for responding, you’re right. It was a bit heavy handed. I think my point may have been put across poorly. The gist of it is that with so many settings in each renderer, surely the best way to approach figuring out which is ‘faster’ is not by trying to match variables such as AA / min/max, but instead, making two scenes that look identical, using the most optimised settings in each renderer, and then comparing speed. I think it would take more time to set up, but equally be more relevant to users. Thanks

hey, do you mind describing the illumination setup? also, are you using gobal illumination in both tests? vray affords the ability to have many gi engines where arnold doesn’t, so was vray set to brute force with the same amount of bounces?

just asking so we are getting closer to a 1:1 comparison. now if speed and quality are the only factors for picking a winner, then vray having those faster gi methods is a point for them!

I can do better!! I just posted the scene files so you can match the benchmark, and create your own versions!

FYI, we didn’t use GI in the Vray scene, just a dome light and two area lights with colors attached to their intensities that drive the color of the scene. I used a semi color neutral material on the particles so that the lights really did most of the work shading the scene. Be careful though, the further away from 50% grey you go will dramatically tip the scale of saturation towards whatever color you’re using.

I ran GI on early tests, but it seemed to wash out the color so I didn’t think it was helping the Vray render quality. Rendering without got the render closer to the quality of the Arnold version. I can include versions with GI when I get the feedback from Chaos Group in the next few days.

I just checked the file, it’s the right one. Make sure you are rendering out of the “RenderCAM2” and not the default perspective camera. I just zipped a portion of the cache file, load the scene, select your particles, then go to nCache and choose attach existing cache. This will match my render exactly. If you create a new cache with your own sim it will inherently be slightly different from mine as it is a dynamically generated simulation, and should be slightly different each time. Hope this helps, let me know if you have any additional trouble.

Arnold is a fantastic render!!!…, but i personally find it extremely slow. Is in fact one of the slowest renders that i have ever try second only to Maxwell specially for backgrounds… But if you have a render farm then Arnold is pure gold.
Vray is also very good.
Nice test by the way. Thanks.

Umm?
I have no idea how it is even possible to get 1h 20min rendertimes?
No matter what I´m doing with Arnold in Softimage it´s typically 1-3min without major optimization and with 8/1/1/1 sampling. And with GI. FullHD frame. 12core machine.

Increasing things like diffuse ray bounces, adding motion blur, using lights to paint the color into the particles. Things like this increase the render times. Sometimes getting a specific look comes at a cost. Not everything works with the default settings, but you do your best to find the best compromise between look and render time. Thanks for the comment! Perhaps you could download the scene file, and share your results with the group?

I’d love to accommodate your request, but we focus mainly on Vray and Arnold with this blog. Frankly Mental Ray is going the way of the dinosaur as the only major place left in LA that I’ve worked with that still uses it as a primary renderer is The Mill, and even they have made a major migration over to Arnold. I do however know of a superb Mental Ray blog with tons of great information run by an equally superb gentleman by the name of David Hackett. We worked together at The Mill in fact, You should check them out at http://elementalray.wordpress.com

Perhaps you can ask them to download the scene file and give it a go? The new Unified Sampling in Mental Ray is light years better, but why settle for quasi-monte carlo when you can use the real thing in Arnold I always say! 🙂

I’m currently trying to render something very similar in Maya Vray. Every time I render spheres, however, there’s always chunks of the render missing. It is different for every frame. It renders fine with points, but as we all know points don’t have nearly the depth that spheres do. I’m out of ideas!!! I’ve been trying to solve this problem for over a week, and have found nothing. Please help!

I was actually talking to support about this issue myself this morning, it’s a known issue and they are working a fix into the next update. In the meantime, I have been able to eliminate almost all flicker by using GI with brute force / brute force. Do not use light cache! Be sure you have your min steps set to at least 2 maybe 3. Let me know if that helps!

Unfortunately (fortunately?) it’s not a GI flicker I’m referring to. Entire chunks of the particles will be missing, in what looks like render bucket errors but is not. I can upload a reference shot, but I’m not sure as to where I should do so.

Are you using distributed rendering? Sometimes a machine can go dark, and their bucket contribution can render black. Just a thought, if this is true try deleting and re adding the machine to your distributed rendering list. As for the picture you can send it to me directly at admin@maxdepth.tv and I’ll take a look!

I know I’m a little late to this party, but I am curious if you tried rendering the VRay spheres and instanced geo? The VRay documentation says the particle spheres aren’t instanced and it recommends instancing sphere meshes. I’d imagine that the render would be much quicker.