E-Cycles - Faster CUDA rendering and better AI denoising

I didn’t notice anything. So I guess how fake it can look highly depends on the expectations of the client. For me and my work, there is no point in overdoing it to make it looks super realistic if it doesn’t have to - usually my own level of quality is set higher than what is expected of me - which leads to wasted time.

Sure, if you are not ambitious about what you do, that’s fine. But such people should not be a benchmark for creation of rendering technologies.

What does ambition have to do with the clients low budget?

What does that have to do with developing rendering technologies? If renderers were developed with the mentality of catering to low budget work, or in other words fastest performance regardless of quality, we all would still be using Blender Internal. Sure, it could not render photorealistic interior, heck, it did not even officially have GI, but boy could you render them fast on today’s hardware…

Here is the outline of the debate.

  • I argued that if optimizations compromise quality too much, they are not much of use unless you do low quality work.
  • Counterargument to that is that other people may not notice the quality is poor, and find it sufficient for low end jobs.
  • My response to that is that’s fine, but it’s not a valid argument for developing a rendering technology. You can do both high end and low end work with renderer capable of producing high end results. But you can’t do high end work with renderer only capable of producing low end results. And of course, if you are willing to sacrifice that much quality for speed, then you are way better off using Eevee anyway.

bliblubli is showing Cycles renders with very impressive rendertimes, but it’s also worth noting that those Cycles renders are set up in a way that compromises quality to such a degree the resulting photorealism is comparable to Eevee. So yes, you get rendertimes close to Eevee, but you also get quality much closer to Eevee.

1 Like

this utility certainly seems to be personally offending people, for some reason.

given all your snarky/pompous comments, did it not occur to you that the render was simply an example to show the speed increase, and it’s not the fact that that’s the only way it works? it’s a render engine FFS, you set up the render however you want depending on your job/needs. it can be as simple or as complex as you (or your customer) want/need it to be. Render speeds will obviously reflect that, but the overriding fact of this build is that whatever your render set-up is, E-Cycles will probably do it a lot faster than that same set-up in stock. why not supply a file and show us your render times and someone can fire off a comparison for you to cast your haughty eye over?


So just to clarify things, E-Cycles indeed let the user decide. All tricks are optional, so that you can adapt to your client. So the image above is a testimonial of the engine flexibility and speed only. Quality level is up to the artist.

I find it actually a big plus, because you can render as fast as Eevee, just by using the improved AO simplify option, using a render engine you already know and which has a very good eco system of ready to use assets, materials, plug-ins (like Toonkit), etc. And if you notice your client wants more or less quality, in Eevee you must add manual volume probes, fake lights, etc. which requires much more work and has to be redone when the scene is changed by the architect or client. With Cycles, you can just change it with one or 2 sliders to switch from Eevee/UE style to Photorealistic and it adapts instantly when the project is modified.

So the example above was just to show their is no need to learn yet another render engine and that E-Cycles is very flexible and can indeed also be very fast.


Your post reads like selling low budget images is ambitionless. Perhaps a misunderstanding.

Anyway, I disagree that you can necessarily do both high and low end work with a high end renderer. Your last sentence disagrees with it as well. :slight_smile:
Cycles the high end renderer is worse than EEVEE the low end renderer in certain aspects.

So why do you think that improving Cycles low end capabilites so far that it can compete with EEVEE is ambitionless?

1 Like

What is the status for rtx? Is there any e-cycles build already??

cheers, dave

1 Like

It’s on the radar, but I prioritize optimizations that work for all generations first.

Ok, thank you

You, like lukas stockner getting hung up on the trivialities of the scrambling distance patch represent a non-creative take on what is (often) a fundamentally creative technology. Its important but only so much. The ability to have fast and satisfying proxies/samples or even slightly (or very) stylized output frames is hugely significant. I think you know this but you are hung up on projecting ignorance onto others. Your points are well made but I have to ask - are you an artist? You sound like a pathologist talking about the clarity of your scans not an artist with vision for their own creative contributions. I can see you 150 years ago trying to tear down impressionism because its not realistic, lol.

Yes, because like Lukas, I also know what I am talking about. :slight_smile: I recognize the importance of being able to spend most of the time focusing on art rather than tweaking dozens of technical parameters which balance speed and bias in all the various different ways. Artist time is way more expensive than computer time.

I am not saying what bliblubli is doing is wrong. Go take look at my first post of this argument. All I asked about is that I’d like to see how his optimizations perform in a setup that doesn’t have lighting faked to such a degree it looks like a frame from a game. I just wanted to see if the speed difference applies also for use cases where user can’t afford to compromise quality to gain speed.

And yes, I’d consider myself an artist: https://www.artstation.com/rawalanche


Here are some more benchs i did using new intel denoiser:

-OS: W10
-Simple Studioscene
-Tiles Size 16
Always Rendering with:
-GPU: 2x GTX1080 (cuda)
-CPU: I9-7940 (using 28 Threads)

1000 Samples
bfBuiltbot: 1m24sec

1000 Samples
e-cycles: 1m01sec

1000 Samples/ mblur
bfBuiltbot: 2m44sec

1000 Samples/ mblur
e-cycles: 2m00sec

800 Samples/ mblur/ Denoise
bfbuiltbot: 3m02

800 Samples/ mblur/ Denoise (intel/comp)
e-cycles: 2m44sec

200 Samples/ mblur/ Denoise
bfbuiltbot: 1m15

200 Samples/ mblur/ Denoise (intel/comp)
e-cycles: 1m12sec

cheers, dave

1 Like

…but the general consensus is that Lukas is wrong in his take. He is a perfect example of tunnel vision that ignores even the technical director on some of the most prominent uses of Blender to date. And thats in a traditional realism based useage - not even getting into more fine art / stylized uses of Blender.

And I see that you are now moving the goalposts/diminishing how aggressively you started because you see you overdid it. Thats good.

But this idea that a render that looks painted at worst:

A. resembles an EEVEE render in any way (artifacts are entirely different)
B. is a direct indicator of “low quality” to anyone, anywhere
C. isn’t eminently helpful while developing work

are all completely fallacious.

All that being said - you have very nice work!

A, No they aren’t. Eevee isn’t capable of producing accurate enough global illumination, so it relies on ambient occlusion for contact shadows. That’s exactly what I am seeing on that Cycles render.

B, Yes, by today’s standards of lighting quality it’s considered low quality.
I am talking about the lighting quality, not the other aspects, such as modeling or texturing work. They are actually on good level, which makes the lacking lighting quality that much more apparent.

C, No, the final workflow isn’t much helpful, if you have to switch 10 different knobs every time you jump between preview quality and final quality. All the more problems arise when you are not working in the conditions of final image. We should be pushing towards interactivity and WYSIWYG workflows, not away from them. Having different settings for previews and finals is legacy workflow that should die as soon as possible.

On top of that, there ARE solutions which can make Cycles several times faster, and at the same time actually increase the resulting quality of the artwork by allowing artists to use more realistic amount of indirect light bounces without worrying about destroying performance. More on that here: Cycles Performance

But I still strongly believe that achieving that by regressing back to ancient primitive methods like constant ambient light with small, strong ambient occlusion shadows is not a way to go about it. It generally causes users to produce lower quality work while taking even more time to do so.

Well, I’m not sure it’s what you want to say, but anyway, E-Cycles doesn’t use any AO trick to be faster. It’s an option because as you can see, different artists have different needs and different clients have different budget. So it’s also not about having preview quality and final render quality with 10 knobs to move: If you like photo realism, you set 128 bounces everywhere, disable clamping, disable filter glossy, etc. and E-Cycles will render that 2x faster than master.

1 Like

Yes, absolutely. I am not arguing about that. What I mean is that based on that picture, Evermotion guys, or whoever has set up that scene, decided to use AO. All I wanted was just to see how the speed difference would look in a scene where such fakes as AO/simplify bounces are not used :slight_smile:

I’ll give an example soon :slight_smile:

I’m ok with you all discussing what is good art in the E-Cycles thread, but what you say give the impression to many that I use biased tricks in E-Cycles by default. It’s not the case. The 2x faster render gives the same results as master, whatever the settings are. Using tricks, it becomes 4 up to 10x faster and I showcase that also because some are going to Eevee and my point is to show them Cycles can be as fast with better results.

And on top of that, it’s much easier to switch between cheap rendering to HQ rendering in one engine then to be stuck in an engine that can only do cheap renders :slight_smile:

1 Like

Yes, again, not disputing that. :slight_smile:

I’d just like to see some comparison. For example Cycles in master vs E-Cycles in scene with no fakes. And then E-Cycles with no tricks vs E-Cycles with tricks. With both rendertimes and side by side pictures. That will make it a lot easier to judge what kind of speed/quality tradeoff is actually going on.

The whole reason I started this conversation was just to let people know that those bombastic 20 second rendertimes do come at a price. Even though it may be not that obvious on that particular image to everyone, it may come to bite them in the back in some other scenes, which rely on accurate light transport a bit more.


Renders are coming :slight_smile: