E-Cycles - The fastest render engine for Blender. 3.2 release available now!

yes i try it but same problem , i try to desactivate all addons too and the problem still occurs . I did’nt have this problem with the previous version of ecycles (the july one ) .

I did a factory reset, but I still encounter the same problem…

Hey Matthew,
I am by no means technically qualified, but hope I am good at testing and methodically pin-pointing issues (it’s called stubbornes). I was hoping you could fill the technical expertise to answer. Here is what I know so far:
I use 368.81 (which is truly old, July 2016). Please read this thread for more details about the behavior.
It gets more interesting: have you ever noticed how viewport render in Eevee seems to lag more and more as you do more navigating or change a couple materials, forcing re-renders? very common complaint in Youtube tutorials. Well that improves drastically if not totally goes away with the old driver (it may lag but rarely if ever gets stuck-crashes. The difference with the newer driver is very obvious).
Having read gamers’ forums this is typical memory leak behavior. A dead give away is your video RAM being still taken over (monitored by MSI Afterburner or other tool) after the crash - that doesn’t happen with old driver.
More reading suggested that memory leak may be the result of a combination of programs or more than one instances of the same program. MSI Afterburner was a suggested culprit, but I tried and that wasn’t it… then I found plenty references that NVIDIA’s very own GeForce Experience was commonly responsible!! and guess what : 368.81 driver installation does not automatically load GeForce Experience on startup, coincidence?
I will do testing asap to see if it’s not the actual drivers but the GeForce Experience loaded on startup.
-Christos

EDIT: no, I still can’t get newer drivers to perform well, even without GeForce Experience, not installed.
From the first few seconds, even the scrolling over the outliner list has some lag.
Eventually crash.
The crash leaves crap in memory and next when I try to restart Blender I get a message “1 device not closed”. Rebooting stops at black screen.

1 Like

• Separate build. All addons etc are pulled from user directory. I use all kinds of addons with no probs. No need to use other Blender copies/versions that I can see. But the option is always there.
• It is 2.8 ready, willing, and runs like a mofo.
• I believe you can use on unlimited computers, but someone else will have to confirm…
• No probs with RTX 2070 in E-Cycles. Use every GPU you have available, if you can.

I have all but abandoned Octane Render for E-Cycles, and EC paid for itself in no time flat. You will not be disappointed friend. Hell, just the Quick Settings alone is worth the price of EC, for me at least…

2 Likes

thx @norka!

Just bought it on gumroad. It seems to get stuck with downloading.
Doesn’t want to finish it even when its 119/119mb.
Is this a common problem?

In Windows, the stall at the end of a download when it appears complete is typically your virus scanner checking out the file. I think if Cloud Protection is enabled in Windows Defender, it may even upload the file to Microsoft if it hasn’t been seen before which would take even longer.

1 Like

@bernardo too. Thanks for the details. So it only happen on RC1 of E-Cycles but not Blender RC1 and E-cycles July is also working good. The bug goes away when switching to CPU and back to GPU…
I can’t reproduce myself, even using image texture instead od procedurals. On top of that, the E-Cycles side of the code is 100% the same on July and RC1 version. Could you please provide a file showing the bug with your OS, CPU and graphic card (per PM at best to better follow the discussion)?

No worries. I’ll try to create a little video this evening showing the steps, so hopefully that’ll help. I don’t think that was happening before, but I can’t tell you with 100% certainty, I’ll have to double check, again, this evening

Ok, thank you Bernardo. @kankrela already confirmed only the RC1 is touched, July works good, so a video alone to reproduce should be enough if you want to spare some time. A confirmation is always welcome of course :slight_smile:

hey all,
question about file output:

I am rendering 4k and denoising + cryptomatte (which needs 32bit float iirc) will
bloat my filesize to ~500MB/frame.

Since I like the denoised e-cycles output, I dont need the denoising passes in my exr anymore.
I tried the file output node (see image), but blender will always also save the default output.

There is a workaround to hook up an rgb node to the composite node so it saves
just little data. But thats not very elegant.

So the question is, is there any way to prevent the denoising data to be saved to exr?

thanks!

Hi
I have Linux Mint 19.1, nvidia driver 418.67, cuda 10.1.168. I bought Ecycles 2.8, but when I want to run it (E_cycles_2.8_RC1), it just does nothing. Error output says “error while loading shared libraries: libtbb.so.2: cannot open shared object file: No such file or directory”.
I also downloaded previous July version, but the same problem…

Any Idea how to fix it?

Hi, it seams it is kind of linking error. Regular E-Cycles link to E_cycles_2.8/lib/ but does not work for you on Mint. You can try to link the lib to your system library folder, iirc it is /lib64 on Debian based distributions or install libtbb from your repro.
May better wait for @bliblubli reply instead of messing up your system, depends on your Linux experience.

Cheers, mib

1 Like

Hi,
do you have a ryzen cpu? Their is a known bug on Ryzen with TBB/OIDN which requires to use the ryzen_fix version.
If you have an Intel CPU, the .so files are shipped with E-Cycles, so it’s strange it doesn’t find it. Can you please try to run patchelf --set-rpath ‘$ORIGIN’ libOpenImageDenoise.so.0.9.0 from the E-Cycles’s “lib” folder (near “2.80” folder) and then try to start it again?

Indeed “patchelf --print-rpath libOpenImageDenoise.so.0.9.0” gives an empty result for the rc1 but not last july build.
Do again “patchelf --set-rpath ‘$ORIGIN’ libOpenImageDenoise.so.0.9.0”
!!! Attention !!! mathieu’s command is somewhat invalid cause of wrong ‘$ORIGIN’ it must be ‘$ORIGIN’ ( ’ not , dunno the exact naming of the signs )
else it does not work !!! ( neither “$ORIGIN”, patchelf seems very picky here )
Seems such issue could come from pasting substituting wrong chars here especially when quoted as code.

Test:
Orig: patchelf --set-rpath ‘$ORIGIN’ libOpenImageDenoise.so.0.9.0

patchelf --set-rpath ‘$ORIGIN’ libOpenImageDenoise.so.0.9.0

Result:
patchelf --print-rpath libOpenImageDenoise.so.0.9.0
‘’
Thus the codeblock pasted into the terminal was corrupted and gave wrong result.
Q.E.D.

Jens

Thank you guys.
I have an Intel CPU. patchelf command corrected by Jens did it. :+1:
I have done just fast tests and I am happy to have it, works really nice.

Brano

1 Like

I don’t know of a way to disable it altogether but you could just use the composite node trick + set the output tab to jpeg at 0% quality to a temp folder that you dump every once in a while.

Theres probably a better solution tho!

image
I just tested the RC1,BoneStudio build and the recent E-Cycles build from July.
I’m really wondering if there any improvements E-cycles has besides the imporvements Brecht and other Cycles devs have made over the year.
I’d stick to BoneStudio till there’s any visible performance benefits that worth 25$ a month I can spend on devfund.

2 Likes

Good job mate!

Hi, I wondering something about the results but E-Cycles is all about optimisations.
With exact same settings, without denoising for example, it should still a bit faster than RC1 official build. The idea is to reduce samples and get the same quality result.
i will check the scene with my E-Cycles RC1 version compare to BF RC1 and post results later.

Cheers, mib

So looking at your chart, you say you will stick to a build which is slower than vanilly Blender in your spreadsheet (the BoneStudio version takes 318sec vs 297sec on vanilla Blender.) :smiley: Not even your conclusion makes sens.