Ok, then it’s a bug probably. Could you please make a bug report with a .blend file to reproduce by answering any mail you received from Gumroad about E-Cycles (like the confirmation mail) or by messaging me on the Blender Market. I would also need the information from the “steps for bug reports.txt” file (available in your downloads).
I’ve just tried on the default cube, it works in both E-Cycles 2.91 and 2.92. So on the top of my head if it’s not file-specific:
- maybe due to an older driver version, newer E-Cycles versions require version 456+
- maybe an add-on is interfering. Resetting to factory default and re-activating CUDA (with GPU only) may help.
vanilla is baking the diffuse, ecycles not.
I’ll try what you said!
i’m trying there all day now, and slowly i don’t feel like it anymore 
baking_diffuse.blend (951.7 KB)
ok it doesn’t work for me. no idea. i have tried different ecycles versions. 3 different graphics card drivers. i have reset settings, deleted all addons.
mathieu helped me. there are two versions for download. an rtx version and a non rtx version. the non rtx version works. I thought it would be enough if I switch to cuda with the rtx version. I misunderstood his advice at first. with the non rtx version everything works. Thank you!
2 Likes
You’re welcome. My wording could have been better too I guess, still doing my best with English. The naming with only the “_rtx” as difference can also be easily over-viewed. I’ll add “_CUDA” to the standard version to make it easier to catch.
And I love your videos showing your creation process!
1 Like
What is the magic trick to point the adaptive samplerate to dark regions where noise is persistent even at 2000 samples while bright areas in the image are solved at ~50 samples without denoising?
@skw is the best one to ask here as he did code that feature. I’m also not sure to understand what you mean with The magic trick. It’s more of a combination of techniques than a single trick.
The main principle for all adaptive sampling methods I know, including the one which was included, is to use a variance buffer to know if the work you are doing is really significantly changing the result on pixel x,y (relative to the user-defined threshold). This check is done every X samples.
One of the “trick” of the Pixar PMJ approach iirc and which differs from other implementations is that if a pixel gets significant changes (over the threshold), it can “revive” neighbor pixels which were otherwise “marked” as converged.
This way of ensuring no pixel is left to early from the update process is particularly useful as it works wonderfully with the way Cycles tiled rendering works.
“Reviving” pixels is particularly useful for caustics for example, where one path out of 1000s can give a very strong light. Most pixels in that caustic area would be marked as converged after say 100 samples, but one pixel in the area would get a strong light path. To ensure you not only continue to sample that one pixel (would give fireflies), you relaunch the neighbors to get the nice full caustics.
If you want, you can find the original paper from Pixar here if my trial at making it more easily understandable failed 
NOTE: I use the occasion to warn about limitations of Adaptive sampling. As soon as you use AI to denoise your renders, you are killing the results by using adaptive sampling. Adaptive sampling in Blender silently activates PMJ, while all AIs available today in Blender and E-Cycles are trained for sobol. On top of that, most of the time, the slowdown you get from using adaptive sampling is rarely compensated by the savings you get by smartly sampling noisy areas more. Scenes have to contain very high discrepancies in noise distribution to offer significant speed-up with adaptive sampling. Most of the time, dividing your sample count by 2 and using sobol + AI denoising will give way better results at similar render times.
3 Likes
ok, thanks for your deep answer 
i wonder if i’m using the correct settings for such scene! Maybe you could point me to your recommended settings i would like to get almost clean passes to compose the image later.
i noticed the huge noise difference when it comes to archviz… other usecases working good and fast.
is it theoretically possible that:
during a render; the refining takes place only in areas where noise is visible present?
i’m comming from vray and i used following technique to debug visible noise and optimize rendertimes:
here are some tests from an actual scene (one hdri for light):
Samples-10-15sec
Samples-10-15sec-D
Samples-2000-24min
Samples-2000-24min-D
1 Like
Hey Phil!
For your scene I would choose settings like here:
Best for Clamping would be to start with a high number like 50 and then find your way down, until you kill a lot of fireflies without losing other visible color information.
Filter glossy the other way around. Start at a very low number like .01 and find your way up, until you kill a lot of fireflies without sacrificing too much reflection and refraction information.
For outdoor scenes you don’t need that many bounces…
2 Likes
Hi, it seams you don´t use E-Cycles presets, check fast setting, they set AO, caustics and some more. I guess you can render such an image with 200 samples or less using AI denoiser.
Cheers, mib
1 Like
hy @johannes.wilde @mib2berlin
thx for your suggestions i used the presets before but i wasn’t happy with the raw passes and the denoiser in post. now this is a good base to work from. thx guys here’s my first blender archviz exterior WIP
3 Likes
Hi,
I like your exteriors renderings! the noise you have seems to be only in the windows areas. I would recommend watching the short tutorial about transparency changes in E-Cycles 2.83. It’s available in your downloads and may increase the noise level greatly and even render faster!
For more scene-specific tips, I would need a .blend file. You can contact me directly by answering any Gumraod e-mail about E-Cycles or by messaging me on the Blender Market (“ask a question” button on the right panel of the product page)
Kind regards,
Mathieu
This may be an upstream bug but I just updated to the v20201203 E-Cycles 2.92 build and I’m unable to scroll inside a panel using the mousewheel if I’m hovering the mouse over a section/subsection header.
Hi, I can verify on Windows and Linux.
Crosschecked with latest buildbot does not have the lag.
Please report it in reply of a mail from Gumroad or use Marketplace support link to @bliblubli. It is easier for him to follow reports there.
Cheers, mib
1 Like
Hey Matt I just downloaded the latest version of 2.91
I am currently using on Win7 64 - on a 1080ti with all the drivers up to date. My 2.9 still works great but the latest 2.91 seems to be generating errors in the optix side of things. When I turn off optics it seems to work well. 2.9 I can work with optix on or off no problem.
The version of 2.9 is the latest release… Here is the same scene and the results
This is the Windows console for 2.91
No errors being generated in the info as well.
Also to note the 11/19 version of 2.91 also had no problems. Just this latest version.
1 Like
There is new E-Cycles 2.92 alpha version available to donwload, which has functional Optix shader raytracing (bevel & AO), as it was implemented in Cycles. I’m sharing my first tests and I am interested of what kind of speed increases others are having? This is just for info to know about what kind of benefit this will give to see if it is good to change to latest version or not.
I made tests with a photorealistic product render “photo studio” setup that I had prepared for real production in E-Cycles 2.83.6. Almost all shaders have shader bevels. Resolution was 5000x5000px and it had about half of total image space filled with renderable pixels, as I render without visible background to add it in post. First OptiX render test with lower sampling was not having too great difference to CUDA render, but when I pumped sampling up the difference was major. I assume this is because of higher sampling needs more raytracing, so speed difference is more prominent. Strange thing though was that with E-Cycles 2.83.6 version the CUDA render was much faster than newer 2.92 alpha CUDA render. So, seems like updated E-Cycles renders slower with CUDA than before. This is something to notice if others are doing speed tests, as it causes more difference with latest version than it actually is if would use older E-Cycles version to render. Not sure if this is same with standard Cycles as well, as I didn’t make any tests with standard Cycles.
Here are test render times, which are rendered with exactly same render parameters other than 2 different sampling values and resulted 100% same result. In Cycles thread in this forum someone had mentioned OptiX to result different noise pattern than CUDA, but for me it was perfectly same for all test renders. Tile size was 256x256 for all renders and GPU only (no CPU) with RTX 2080. There was no denoising processed in tests. Unfortunately can’t show the image publicly, but this is more about render times with already existing settings rather than the image or exact render settings.
E-Cycles 2.83.6 / CUDA - Sampling 256
Render time: 08:01 (mins:seconds)
E-Cycles 2.92a / CUDA - Sampling 256
Render time: 10:35
E-Cycles 2.92a / OptiX - Sampling 256
Render time: 06:58
E-Cycles 2.83.6 / CUDA - Sampling 1024
Render time: 26:09
E-Cycles 2.92a / CUDA - Sampling 1024
Render time: 29:59
E-Cycles 2.92a / OptiX - Sampling 1024
Render time: 16:52
1 Like
Hey, I’m experiencing some kind of viewport lag. The viewport in E-Cycles updates every 10 samples instead of every sample in the latest stable Blender build.
This is how it’s updating in E-Cycles
This is the stable
Both on 2.91, using OPTIX.
I tried deleting the optix shader cache and I tested it using Studio Driver 457.30 and Game Ready 457.51
Is this a feature or there’s something wrong? I find it quite annoying when testing shaders and object placement.
Thank you, I love E-cycles!
1 Like
@bliblubli
i recieved the coupon for e-cycles 2021 and bought the 2021 rtx version advertised with 224€ using the coupon for users.
Now i am a little shocked and disapointed because paypal showed €270,71 finally because of 16% Tax and some exchange fee. Why do i need to pay exchange fees? Arent you located in the EU? Or is it related to gumroad or paypal?
Hi @mag.py ,
as E-Cycles is 100% like Blender for the UI code, I guess it was a bug in the particular revision I based that alpha on. I can’t reproduce it anyway using today’s build. Is the bug solved for you too in latest builds?