This has been some great work by the GSOC student, But Seriously catching up with Vray are you smoking crack? Cycles is more than ever a magnitude slower than ALL production renderers, Even AMD’s Pro Render Kills Cycles, So does Luxcore.
If anything Cycles has been falling back for 6-12 months now, Shame as less and less reason to stick with Blenders main renderer anymore. Far better open source solutions right now.
Cycles needs far more love, But with 2.8 going on it’s lost a lot of dev time. Maybe long term that’s a good thing if better renderers are developed.
There were early examples of the project’s code in action. A room full of lights converged at a rate that was far faster than Cycles as seen in 2.79.
And yes, Cycles has lost a bit of dev. time to 2.8, but Brecht has recently been hired again by the BF and part of his job description is to work on Cycles (which is already making a difference with various patches being committed).
I wonder, do cycles devs at least consider having some sort of secondary GI caching? Luxcore will be getting one afaik. Vray and corona has this and it makes a night and day performance difference in interior and complex lighting scenarios.
I too think Cycles is pretty fast compared to other renderers of comparable quality. It’s certainly not an ‘order of magnitude’ slower than any comparable quality renderer.
Whilst any additional speed up it welcome - I personally would like to see Cycles feature set expanded to allow materials to better simulate real world effects like microroughness, microfacet specular (for glints/glitter), nested dielectrics (to help with refractive materials in contact with each other), MLT (for caustics) - perhaps even isosurfaces for volumetric materials etc
This comes as a surprise to me. I always had the impression that modern cycles had render times which were comparable to most of the other path tracers (except for redshift and octane).
Has anyone done a recent comparison between cycles and all the other path tracers out there? I’m talking about a comprehensive comparison where the majority of render engines available are tested against the same scene, but with settings appropriate for each engine. The only one I’ve seen that was that in depth was this one from blender guru, but it was made in 2015. Cycles has had a ton of performance improvements since then (for example gpu + cpu).
Using the latest 2.79 daily build which has combined CPU and GPU rendering with a 32x32 tile size yielded a render time of 33 seconds (227% increase in speed compared to 2.75).
Throwing Simplify (3 AO bounces) and Denoising into the mix too - with a lower number of samples (75) yields render times a little over 11 seconds (more than a 600% speed increase) for an almost comparable quality render.
Personally I have no complaints about how rendering speed has been progressing in cycles.
Hey im all in with the updates being added as early as possible, Im not hating on Cycles. Just that as Blender needed massive changes this was going to have to happen when dev moves to the DCC rather than the renderer.
But to say Cycles is anywhere near Vray or the main other contenders is false hope, lets just look at features in Lux core 2+,
: Adaptive sampler (and others like Metropolis sampler)
: Network rendering (that works)
: New development Direct light sampling
: De-noiser that actually works, aimed at higher sample rates for production work.
etc etc etc, And that’s just Lux. Much more on the way
In scene’s ive been testing it took 2 hours to render 1000 sample interior scene only lit by HDRI enviro map with Cycles (which still was no where near being noise free), In Luxcore new beta even with a nvidia card I got 3321 samples for the exact same scene with comparable render settings and materials at the same 2 hours. And of course I can denoise at any point with Lux.
Im not trying to piss people off (well maybe a little) but maybe people should take a look at what the other Open source renders are achieving right now before you start spitting the dummy because your poor old cycles gets a little bad press.
Just some thoughts about that - I have tried all mayor Renderengines that I could get my hands on. Compared to Cycles:
LuxCore: Faster for interiors because of MLT etc. for generic Scenes Cycles is faster.
Renderman: Slower than Cycles except on extremely heavy scenes with complex lighting (GPU support on the way though)
Arnold: Same as Renderman but without the added benefit of VCM. Very fast volumes.
Redshift: the fastest Renerer out there - so no competition here.
Prorender: Faster with default settings - kind of the equal to Cycles speed when tweaked to the same quality (GI Bounces etc.)
VRay: For interiors faster than Cycles - the rest depends. With a goot GPU, Cycles might outperform VRay CPU on outdoor scenes. VRay on GPU was not fully featured last time I checked - might be better now. VRay is not really a Pathtracer so the comparison is hard.
Octane: With the latest Cycles additions it might be kinda even. Probably Octane is slightly faster.
Maxwell: Didn try that one but I bet Cycles is faster. Maxwell has other advantages.
Appleseed: Interresting project but still very slow.
One of the nice things about Luxrender 2.0 is that it is under the Apache 2 license. That means it and Cycles can borrow algorithms and code from each other to advance the Open Source ecosystem. I would still prefer Cycles because of its now extensive node-based shading system (with missing pieces now in place like bevel shading and AO/curvature) and because I have a huge collection of older scenes with objects and group nodes I can append to other projects.
That’s a nice list. I agree and add some more.
Cycles execution speed is quite decent in most circumstances but it is not a universal engine for all types of scenes. A statement like Cycles is slow has not much meaning without further context.
Like all unidirectional path tracer (e.g. Arnold) it has difficulties with complex visibility scenes (scenes lit mostly by indirect lighting) or strong concentration of rays within a small region in space due to refraction or reflections on specular surfaces (caustics).
For vfx heavy scenes with motion blur, volumetrics and heavy particle instancing you will find much better options (Arnold, RenderMan, Mantra).
If you want to render jewellery accurately you would need a spectral renderer to get correct dispersion effects for diamonds and complex ior for metal shine (Maxwell, Indigo)
So Cycles can be fast or slow depending on your type of scene and use cases. And pure execution speed is just one issue to consider when selecting a render engine. Like @Ace_Dragon mentioned, Cycles has a bevel shader, which could save considerable modelling time for complex hard surface models. Render time Boolean are another example, important for architectural visualizations. With it, one can easily render a scene with a cut-plane sliced through revealing the interior of a building. If the render engine does not support it, you cannot easily compensate with a slightly faster execution speed.
But your example is one very specific case (a case that is known to cause issues with Cycles currently). To state that it’s a magnitude slower than ALL production renderers implies that is under all use cases too - which is simply false and more than a little unfair.
Incidentally - did you use portals for your interior scene - these can help massively.
There are advantages and disadvantages with many renderers - as people above stated, out and out speed isn’t the be all and end all. The great thing about Blender is, if you don’t want to use cycles, you are free to chose from one of the many other renderers out there - and in some cases, this may even be necessary depending on the type of work you are doing.
Cycles has made huge strides with regards to speed (see my example above) - and that is likely to continue, especially now Brecht is back.
I’d love to see things like MLT intergrated formally into Cycles. The proof of concept build a few years back was awesome and hopefully this type of function will make it into Cycles.
I have tested almost every renderer in the existence and rendering has been my main focus for past 9 years. Statement that Cycles is significantly slower than other mainstream renderers is factually true. The speed difference is somewhere between twice slower to the order of magnitude slower depending on the scene. This applies for CPU rendering.
For GPU rendering, on a really fast GPU, like GTX1080Ti, the performance of Cycles is somewhat acceptable, but you are limited to quite trivial scenes, otherwise you run out of GPU memory pretty much instantly.
The slowness is actually confirmed even by Tangent Animation in this thread:
Particularly in this post:
The guy states that AVERAGE, not MAXIMAL, but just AVERAGE rendertime per frame for them the was 3.76 hours, nearly 4 hours. For 4k that would be acceptable, but that was for 2k (2048*1080). Average of 3.76 hrs per frame means somewhere between 1 hour and 7 hours per frame for just pretty much fullHD resolutions.
So those shots must be really heavy, lots of translucent foliage, closeups of refractive and SSS surfaces in DoF, etc… right? Well, no… Check the screenshots at the beginning of that thread. The scenes are nice, but completely trivial from the shading point… Exterior scenarios, very friendly for path tracers and mostly flat surfaces with no transmissive properties. These are the kinds of shots that take about 20-30 minutes per frame in FullHD to get to final quality in something like V-Ray or Corona. Hearing 3.76 hours/frame in 2k for such type of shots is horrifying.
On top of that, keep in mind that Tangent has own Blender developer which optimized Cycles significantly, so the Cycles you are using in official branch is even slower.
Of course. Motion blur in modern path tracers is not that costly to performance, but more to memory these days. The days where MB was rendertime multiplier are gone. These days, it’s just a few % hit.
Corona and V-Ray are definitely faster. For comparing Next-Gen render times though, you have to know which CPUs were used. Animated features are basically all rendered in 2K, and a few dozen hours render time is not uncommon, but then we are talking about much more detailed shots.