E-Cycles - one week left to get up 4x faster rendering + upcoming AI techs with 100€ off!

Errr… I’ll have to load up a heavy scene with tons of geo, 4k PBR maps, and render a nice high-res image… I have a feeling they are not going to heat up much. It’s all good, E-Cycles is kinda getting me over a hump until Octane Blender 2.8 is ready… sadly, in a couple months…

EDIT: Temps after 15 minutes on highest settings with a 4k render cooking: GPU1 (display) 51°, GPU2 47°, GPU3 43°… so definitely warmer than my simple-ish animation test, but still not terribly warm. I’m not budging from my contention that if a GPU render engine is not creating a real nice fat chunk of heat, it is not pushing itself hard enough. I wanna heat this :pizza: on the top of my case…

Indeed. Instancing is broken in 2.8 and render preparation takes way longer than in 2.79. I hope this gets fixed soon.

its in high priority, it need to

that’s good to know. @BD3D, do you have a link to the issue on the bugtracker?

You can try to replace every mass instanced object by instance collection who doesn’t have the bug and see if it’s the problem

Il my forest scene I had the bug and using this code was fixing my vray usage by 18gb to 3gb with a forest scene


yes, everybody taking the course can get any E-Cycles version with 50% off. Many missed the Gumroad day or had trouble with the high traffic, so I’ll redo the sale for a week-end in May, when the upcoming may update is stable (first May feature update builds should be up next week).

There is currently a bug indeed with instancing in Blender 2.8. It uses huge amount of Vram and makes the pre-processing very slow. 2.79x works as expected, fast and memory efficient.

As 2.8x starts to stabilize, the E-Cycles May update will bring a first part of the 2.79x optimizations to 2.8x, bringing around 8-20% faster rendering depending on the scene and reducing memory usage.
After answering everyone, I’ll start doing the new builds. If I somehow oversee someone’s message, poke me and I’ll answer asap.

Thanks to all for the kind words and support per PM, Email and here in the thread :slight_smile: I was impressed to see nearly everyone I spoke with actually has or had the same trouble with the mouse hand. I’ll try every solution I got and report so that it can maybe help other too.


Welcome back :slightly_smiling_face:


Yeah, welcome back Bliblubi! Back to work you! Chop chop!

So guys, I am getting random crashes to desktop when doing 1080p PNG sequence renders (w/ alpha, moblur, and a screen made of beveled curves – nothing else of noteworthiness)… this happened twice on two different scenes… went to go eat a sammy last night and my 300 frame animation apparently pooped out at frame 210… then basically same thing happened again this morning on another scene with only 240 frames it crashed at frame 189. Anyone else experiencing random crashes during animation renders?

Under 2.8 yes, and not only related to E-cycles.
Got a trick to fix this using an operator looking for output of a background session actually rendering and restart render from last known saved frame when bg session crash.

It does freeze your main session until full render done.

  • Setup your render in main session, including start / end frame, engine and output path, then save your file.
  • F3 -> Background render
    background_render.py (3.4 KB)

Thanks, I may need to try that! I’m never away from my desk for so long that this is anything more than annoying, and of course doing image sequences makes this even less of an issue, since you can pick up right where it left off… but yeah, this sounds pretty cool and I should try it. Thanks again!

Hi, master has a lot of new UI improvements. When we can expect a new e-cycles build?

I’m currently testing the windows builds, I can upload a beta today if you want.

1 Like

Sure, it’ll be great

Are fancy icons not the killer feature we are waiting for, after all ? :thinking:

So guys, when editing HKEY in RegEdit to add TdrDelay, we use a DWORD (32-bit) even if we have 64-bit Win10Pro, and not a QWORD (64-bit), right? Please advise.

yes 32bits, exactly.

Great! Thanks B! I was really thrown off by this page that I found:

Where it says:
For 32 bit Windows
Select DWORD (32-bit) value.
Type TdrDelay as the Name and click Enter.
Double-click TdrDelay and add 8 for the Value data and click OK.

For 64 bit Windows
Select QWORD (64-bit) value.
Type TdrDelay as the Name and click Enter.
Double-click TdrDelay and add 8 for the Value data and clickOK.

A first version of the may update beta for 2.8x on windows is available. It’s more than 10% faster in most cases and uses around 20-30% less memory in my test.

On the 2080 TI, render time for BMW went from 27,3sec on april update to 23,8s with may update = 1.15x faster than previous E-Cycles. Memory usage went from 1483MB compared to 1927 MB on April update or latest buildbots. The memory usage reported by Blender is not exact, if you want to see the real saving, you can monitor it with MSI Afterburner for example.

It’s available at the bottom of the page and is based on latest master so you have all the nice UI improvements and bug fixes.


D’oh! Still crashes on png sequences (average 10 seconds per frame - w/ three 980Ti), using latest (today’s) E-Cycles and adding TdrDelay of 40. Almost made it though… with 219 frames done of 240. Can anyone shed some light on the discrepancy between bliblubi’s suggestion of doing 32-bit DWORD HKey for 64-bit OS (as opposed to 64-bit QWORD HKey), and the info that is given on that page two posts up? This is perplexing. I just want to make 100% sure I am trying everything. I have a lot of crap to render in the coming days…