Hi,
thanks for the report, I just fixed the 2.83.6 issue and new builds 20200904 are already available in your downloads (was a faulty commit on Blender side with I reverted, usually, issues not related to rendering are best reported to the BF on developer.blender.org)
For the 2.90 bug, I can’t reproduce, but it sounds like a bug that may be in E-Cycles. Can you please read the “steps for bug reports.txt” file in your downloads and make a bug report by answering a mail about E-Cycles (Gumroad) or messaging me on the Blender Market if you got it there?
I’'ll investigate asap.
New 2.83.6 builds are up:
- a crash in edit mode introduced after 2.83.5 was fixed.
2 Likes
Cool I will retest.
The crash was in : E_cycles_2.83.6_v20200828_win
1 Like
thx :
I will look for the steps for bug doc and get back to you
1 Like
Julien, do you have Gizmo Pro 1.1.6?
If yes, deactivate it and try again.
1 Like
2 Likes
2 Likes
New builds of E-Cycles Nebulae based on 2.90 are available!
They offer:
- state of the art rendering speed
- the specialized AI-Denoiser with high quality detail preservation
- all the improvements of 2.90 on top
- available for Windows and Linux
Tim Barton does awesome animations of Nebulaes with E-Cycles, I recommend to have a look to his work:
2 Likes
that looks great! Have you included some nebula scenes with it as well? all the ones that I could find were made with EEVEE in mind.
Also, if you need beta tester for the new subdivision displacement let me know 
1 Like
I just downloaded a new 2.91 build from gumroad. Today’s release. Thanks mathieu.
1 Like
In 2.90 RTX version (Windows), cycles often hangs while loading viewport rendering. Only solution is force shutdown of Blender. Does anybody else have problems like this on other versions?
EDIT: It also happened in basic version of Blender 2.90. So it is not just connected to E-Cycles.
1 Like
Have there been any updates on drivers? The latest information I could find is recommending Nvidia v436.15.
I am using the latest nvidia driver with a 2070 super and it works better than the 436.15. I cannot however give you any comparisons.
1 Like
Thanks. I guess I’ll give them a shot. I saw major performance degradation on the 441.xx drivers for the 2.83 build so I’ve been holding out on upgrading from v436.15
1 Like
When I tested it, version 436.15 was a bit faster. But it wasn’t a big difference. There seems to be a bigger difference in Mathieu’s test. Each system is different.
1 Like
2.90 is indeed reported to be rather unstable by many users, so the Blender Foundation planned a 2.90.1 release 
1 Like
As other reported, 436.15 is still the fastest and most stable release, but the new 452 versions seem to be pretty good too. I’ll test it a bit more and make it the new recommended driver if it passes all the tests. It also has much better denoising in viewport, which is very useful
1 Like
I’ll try to add some example scenes for the Nebulae version in the coming weeks.
1 Like
New versions of E-Cycles 2.91 are available:
- render times were improved slightly
- includes all the improvements from upstream
Happy rendering!
1 Like
Hi bliblubli, I have an ideas on speeding up E-Cycles by a bit for people who have a fast GPU and CPU.
I’m not sure how to send this idea to the devs, but here it is for you bliblubli. There is a problem with Cycles now where the GPU and CPU working together does not go as fast as one or the other by itself because the render buckets are not broken up right. To fix this problem and get maximum speed I suggest the following.
My suggestion to fix this for Blender would be to have the cpu tile size be a small multiple of what the gpu is. This way lets say you have a 512x512 tile size for GPU. CPU with 64 cores would get 1 GPU tile with each core having a sqrt[(512x512)/64]= 64 so a 64x64 tile or whatever the smallest cpu tiles was set to. If the smallest cpu tiles was set to 128x128 the CPU would have 4 GPU tiles total to have all 64 cores working.
The basic ideas is split the GPU tile set then have a smallest CPU tile set. The CPU renders as few GPU tile sizes as it can at a time. If the smallest CPU tile was set to 8x8 with a 64 core and the GPU tile was 512x512 the CPU would have a ton of little squares that didn’t even take up a single GPU tile at any moment. In that case the CPU would start with 1/64th of a single GPU tile rendering, 8x8pixelsx64cores = 4,096 pixels or 1/64 of a 512x512 chunk, but the tiny cpu tiles in that 512x512 chunk would progress quickly. After a core finishes the last tiny cpu tile in that 512x512 chunk and there is not a new one for that core the core could start in a new 512x512 chunk. As the cores finish the old chunk they could move to the new one started. This way there isn’t those CPU tiles hanging at the end that only have one core working on them and take forever to finish.
1 Like