i’ve got the same bug than bernardo when using displacement + bump (black shader) , works fine on the regular rc1 and if i switch to CPU.
in my case switching from gpu to cpu and then back to gpu works fine, so that might be a work around. As you said however, this issue is not happening with 2.80 rc1 vanilla
I couldn’t reproduce. As you can see in my answer, it works properly for me even when rendering directly on GPU. Did you both try to clean your preferences to factory settings?
Hey, thanks for that information, I had about 5 people reporting crashes/timeout errors on Windows recently although they had the TDR value set properly. It looks like you found the root Which exact version of the driver works?
As far as I know for Cuda, their is no real benefit of updating drivers. It’s more of a standard recommendation, but if newer drivers are more instable than older, then I can write the working version in the doc.
I have some questions about E-cycles before I buy it:
- Is it a separate built or does it work like a plugin? If it is separate, can I work in the normal version and just open it in the E-cycles and render away?
- Is it 2.8 ready?
- Can I use it on multiple computers? I work alone but have in total 3 machines I work on.
- My best card is a GeForce RTX 2070, any problems with this card I should know about or is it all good?
Thx in advance, looking forward to rendering with E-cycles!
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…
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.
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.
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.
• 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…
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.
@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
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?
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.
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.
Orig: patchelf --set-rpath ‘$ORIGIN’ libOpenImageDenoise.so.0.9.0
patchelf --set-rpath ‘$ORIGIN’ libOpenImageDenoise.so.0.9.0
patchelf --print-rpath libOpenImageDenoise.so.0.9.0
Thus the codeblock pasted into the terminal was corrupted and gave wrong result.
Thank you guys.
I have an Intel CPU. patchelf command corrected by Jens did it.
I have done just fast tests and I am happy to have it, works really nice.