# Cycles Development Updates **URL:** \ **Category:** Latest News\ **Created:** [May 7, 2018, 5:55am UTC](https://blenderartists.org/t/cycles-development-updates/1110067 "2018-05-07T05:55:12Z")\ **Posts on this page:** 20\ **Page:** 18
**Author:** ![3DLuver](https://blenderartists.org/letter_avatar_proxy/v4/letter/3/9d8465/32.png) [@3DLuver](https://blenderartists.org/u/3DLuver)\ **Post date:** [July 30, 2018, 10:36pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/345 "2018-07-30T22:36:59Z")
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. ---
**Author:** ![lsscpp](https://blenderartists.org/user_avatar/blenderartists.org/lsscpp/32/3452_2.png) [@lsscpp](https://blenderartists.org/u/lsscpp)\ **Post date:** [July 30, 2018, 10:52pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/346 "2018-07-30T22:52:13Z")
> [@3DLuver](#): > > Even AMD’s Pro Render Kills Cycles, So does Luxcore That is surprising to my ears! I tested those engines and found them very slow compared to cycles. What did i do wrong? ---
**Author:** ![Heverton](https://blenderartists.org/user_avatar/blenderartists.org/heverton/32/1121210_2.png) [@Heverton](https://blenderartists.org/u/Heverton)\ **Post date:** [July 30, 2018, 11:28pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/347 "2018-07-30T23:28:51Z")
Besides LuxCore being fast here, it doesn’t compare to Cycles yet… Maybe because I’m using nvidia gpu? ---
**Author:** ![Ace\_Dragon](https://blenderartists.org/user_avatar/blenderartists.org/ace_dragon/32/1067926_2.png) [@Ace\_Dragon](https://blenderartists.org/u/Ace_Dragon)\ **Post date:** [July 30, 2018, 11:43pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/348 "2018-07-30T23:43:47Z")
> [@3DLuver](#): > > 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. 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). ---
**Author:** ![lacilaci86](https://blenderartists.org/user_avatar/blenderartists.org/lacilaci86/32/856025_2.png) [@lacilaci86](https://blenderartists.org/u/lacilaci86)\ **Post date:** [July 31, 2018, 5:41am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/349 "2018-07-31T05:41:01Z")
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. ---
**Author:** ![lsscpp](https://blenderartists.org/user_avatar/blenderartists.org/lsscpp/32/3452_2.png) [@lsscpp](https://blenderartists.org/u/lsscpp)\ **Post date:** [July 31, 2018, 10:01am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/350 "2018-07-31T10:01:39Z")
Not to mention [these news](https://blenderartists.org/t/new-from-tangent-animation-next-gen-is-this-bender/1116159/92) ---
**Author:** ![marcoG\_ita](https://blenderartists.org/user_avatar/blenderartists.org/marcog_ita/32/509385_2.png) [@marcoG\_ita](https://blenderartists.org/u/marcoG_ita)\ **Post date:** [July 31, 2018, 10:14am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/351 "2018-07-31T10:14:34Z")
> [@3DLuver](#): > > cles is more than ever a magnitude slower than ALL production renderers, Even AMD’s Pro Render Kills Cycles, So does Luxcore. I can’t speak about motion blur and animations but this is pure bulls\*\*t for still images. I get interior scenes rendered at 5000px in half an hour. The many lights will help too once finished and polished. ---
**Author:** ![moony](https://blenderartists.org/letter_avatar_proxy/v4/letter/m/a6a055/32.png) [@moony](https://blenderartists.org/u/moony)\ **Post date:** [July 31, 2018, 1:45pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/352 "2018-07-31T13:45:00Z")
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 ---
**Author:** ![zanzio](https://blenderartists.org/user_avatar/blenderartists.org/zanzio/32/38911_2.png) [@zanzio](https://blenderartists.org/u/zanzio)\ **Post date:** [July 31, 2018, 1:55pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/353 "2018-07-31T13:55:13Z")
> [@3DLuver](#): > > Cycles is more than ever a magnitude slower than ALL production renderers, Even AMD’s Pro Render Kills Cycles, So does Luxcore. 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](https://www.blenderguru.com/articles/render-engine-comparison-cycles-vs-giants), but it was made in 2015. Cycles has had a ton of performance improvements since then (for example gpu + cpu). ---
**Author:** ![moony](https://blenderartists.org/letter_avatar_proxy/v4/letter/m/a6a055/32.png) [@moony](https://blenderartists.org/u/moony)\ **Post date:** [July 31, 2018, 2:10pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/354 "2018-07-31T14:10:54Z")
> [@zanzio](#): > > The only one I’ve seen that was that in depth was [this one from blender guru](https://www.blenderguru.com/articles/render-engine-comparison-cycles-vs-giants), but it was made in 2015. Cycles has had a ton of performance improvements since then (for example gpu + cpu). I saw that too - many of the other renders although cited as faster in that test, are also noisier. I’m not sure it’s a fair comparison. Based on when that article was published - I reckon he was using Blender 2.74 or 2.75. I rendered the BMW scene using default settings: 2.75 = 1:15, 2.79 = 1.03 (almost 20% speed increase) 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. ---
**Author:** ![Stuntkoala](https://blenderartists.org/user_avatar/blenderartists.org/stuntkoala/32/442815_2.png) [@Stuntkoala](https://blenderartists.org/u/Stuntkoala)\ **Post date:** [July 31, 2018, 4:26pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/355 "2018-07-31T16:26:18Z")
> [@3DLuver](#): > > Cycles is more than ever a magnitude slower than ALL production renderers This is just plain wrong. ---
**Author:** ![3DLuver](https://blenderartists.org/letter_avatar_proxy/v4/letter/3/9d8465/32.png) [@3DLuver](https://blenderartists.org/u/3DLuver)\ **Post date:** [July 31, 2018, 10:21pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/356 "2018-07-31T22:21:06Z")
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. ---
**Author:** ![Stuntkoala](https://blenderartists.org/user_avatar/blenderartists.org/stuntkoala/32/442815_2.png) [@Stuntkoala](https://blenderartists.org/u/Stuntkoala)\ **Post date:** [July 31, 2018, 10:31pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/357 "2018-07-31T22:31:45Z")
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. ---
**Author:** ![Ace\_Dragon](https://blenderartists.org/user_avatar/blenderartists.org/ace_dragon/32/1067926_2.png) [@Ace\_Dragon](https://blenderartists.org/u/Ace_Dragon)\ **Post date:** [July 31, 2018, 11:30pm UTC](https://blenderartists.org/t/cycles-development-updates/1110067/358 "2018-07-31T23:30:36Z")
> [@3DLuver](#): > > : 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. 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. ---
**Author:** ![numen22](https://blenderartists.org/user_avatar/blenderartists.org/numen22/32/38765_2.png) [@numen22](https://blenderartists.org/u/numen22)\ **Post date:** [August 1, 2018, 6:15am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/359 "2018-08-01T06:15:51Z")
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. ---
**Author:** ![moony](https://blenderartists.org/letter_avatar_proxy/v4/letter/m/a6a055/32.png) [@moony](https://blenderartists.org/u/moony)\ **Post date:** [August 1, 2018, 7:31am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/360 "2018-08-01T07:31:24Z")
> [@3DLuver](#): > > 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. 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. ---
**Author:** ![rawalanche](https://blenderartists.org/user_avatar/blenderartists.org/rawalanche/32/538671_2.png) [@rawalanche](https://blenderartists.org/u/rawalanche)\ **Post date:** [August 1, 2018, 7:57am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/361 "2018-08-01T07:57:05Z")
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: > [@New from Tangent Animation: Next Gen. Is this Bender?](https://blenderartists.org/t/new-from-tangent-animation-next-gen-is-this-bender/1116159): > > Hey folks, I came across this on the Modo forum: Full HD trailer: Trailer and teasers: [https://weibo.com/u/5847877966?is\_hot=1](https://weibo.com/u/5847877966?is_hot=1)[[image] ](https://blenderartists.org/uploads/default/optimized/4X/2/0/6/2067a7f483e069b0fb13acda96196f60976ab050_1_352x499.jpg) UPDATE: So, it’s confirmed through investigation that this is indeed Tangent and they did use Blender and Cycles. They mentioned “next Gen” (their next movie after Ozzy) in a 2016 blender conference video. They said that the budget was about twice that of Ozzy. They show two concept images of the girl and the robot. Th… Particularly in this post: > [@New from Tangent Animation: Next Gen. Is this Bender?](https://blenderartists.org/t/new-from-tangent-animation-next-gen-is-this-bender/1116159/64): > > We averaged 3.76 hours per frame on NextGen - some sequences rendered a lot more quickly, some took a lot longer (think: water effects via Alembic caches, 20-30 VDB’s in a single shot for smoke, fire and explosions, etc). There are obviously many redo’s and artistic retakes involved, but if you eliminate those, here’s a rough breakdown: 93 minute movie == 133920 frames @ 24 FPS We rendered 5 different versions of the movie: English mono, English and Mandarin Stereo (for the Chinese market)… 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. ---
**Author:** ![lsscpp](https://blenderartists.org/user_avatar/blenderartists.org/lsscpp/32/3452_2.png) [@lsscpp](https://blenderartists.org/u/lsscpp)\ **Post date:** [August 1, 2018, 10:01am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/362 "2018-08-01T10:01:30Z")
He also mentions that they did motion blur _in camera_ for pretty much every shot ---
**Author:** ![rawalanche](https://blenderartists.org/user_avatar/blenderartists.org/rawalanche/32/538671_2.png) [@rawalanche](https://blenderartists.org/u/rawalanche)\ **Post date:** [August 1, 2018, 10:13am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/363 "2018-08-01T10:13:21Z")
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. ---
**Author:** ![brecht](https://blenderartists.org/letter_avatar_proxy/v4/letter/b/ecc23a/32.png) [@brecht](https://blenderartists.org/u/brecht)\ **Post date:** [August 1, 2018, 10:19am UTC](https://blenderartists.org/t/cycles-development-updates/1110067/364 "2018-08-01T10:19:14Z")
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. [Previous page](https://blenderartists.org/t/cycles-development-updates/1110067.md?page=17) [Next page](https://blenderartists.org/t/cycles-development-updates/1110067.md?page=19)