I have a problem with the noise pattern it looks blotchy, tried in 3 projekts.
- which E-Cycles version did you use (2.79x or 2.8x)?
- is it the imaged done with the old denoiser or the AI denoiser?
- If AI, which level ?
In any case, I need a file and steps to reproduce the error.
No Denoiser. Just noise compatibillity turned on first render, turned off second render.
Latest 2.79 build.
ok, please provide a file and the steps, I’ll have a look. (you can PM me or send email)
The new weekly build for E-Cycles 2.79x is up. It has the latest AI denoiser addon and a bug that occurred at very high sample (over 4000spp) is fixed. 2.8 based version will follow soon.
Known bugs left: The AI denoiser may not work on some distros. Ubuntu 18.04, 16.04, Linux Mint 18.x and 19.x are known to work.
Thanks for your fast replies, your support is fantastic.
Yes. WAY better!
The documentation has been updated.
The Linux versions now support the same distributions as the official buildbots, even a bit more (glibc 2.23+ in E-Cycles vs 2.24+ in buildbots)
A new beta version of the AI denoiser addon is up:
- It will test available materials to recommend using SSS for example if it find a material using it in the scene. As actual visibility of said material is unknown to python, it’s still a user decision to activate it.
- It has a new button to regenerate the tree with the new settings.
- it will automatically disable the old denoiser if AI denoising is chosen to avoid denoising twice
- the image details quality is enhanced in some scenarios
- the next version will spare a lot of memory. The very first bits toward memory usage optimizations are in this beta. Documentation on how to use it will follow soon.
To install it, just download it from the bottom of the product page and replace the one from your build (located in 2.80 oder 2.79\scripts\addons) with the new one.
The Gumroad sales start on Thursday.
Thank you for all the updates!
And constant responses!
Since release of the update 20190326 the final result of the render image has a lot of strong fireflies this was mainly caused because MIS was deactivated, that en the project Im working on improved a lot the render time per frame but take the posibilit of decrease a bit the denoise amount, I should use it now at 1 yes or yes, If not you can notice this strong fireflies everywhere.
Other thing is now im working on another scene of the same project and the denoise before and after the AI update you uploaded yesterday is giving me super strange result, Is like is changing colours and more…Ill upload a reference wiht denoise and without it. I just need to try to the version before the 26 realese.
you’re welcome, the march month was indeed full of improvements to the AI denoiser addon, generally for the April release, I concentrated on user experience, more is coming in the next release together with memory optimizations.
Looking at the plant, it seems you are using level 3 and didn’t check the transmission option in the denoise panel?
Regarding the fireflies, it seems you deactivated MIS for your HDRi in the world panel? if you reactivate it, it should render properly. If not, I didn’t change anything to the path tracing code for the 26th march release, so it sounds more like a bug introduced in master/official buildbots? If the problem persists, please provide a file and steps to reproduce (per PM or email).
There is a beta including many of the improvements of the April update available (2.8 version). It includes:
- a memory optimization when using level 3 of the denoiser with all material types (SSS and transmission). It uses only a half of the memory compared to latest version.
- If it’s still not enough, there is a low mem option. It’s still in very early stage. At the moment, to use this option, you have to click “prepare low mem denoise” after rendering and grab one link somewhere in the compositor tree, just to trigger the compositing. There is at the moment no API call in 2.8 for that as far as I could see…
- I also reworked the UI for the quick settings panel, I’ll update the doc accordingly later, comments are welcome.
Coming next to the April update is an option to make the noise more AI friendly. Here an example on the classroom scene where the AI had a hard time denoising the blades in front of the window with the march update. The April update option gives much better results (2x magnification)
Thanks for the response!
The plant was the SSS i didnt activate on the denoise.
On the hdri wasent activated the MIS, but still is in gray the option like will not affect, but It helped.
About the fireflys in the other FIle i was woking on, I didnt change anythign and with 1 week ago update the fireflies was much less, compared with exactly the same file with the last updates.
But in one of the shoots last updates reduce the render time from 2.30 minutes to 1:30 minutes… and with the denoiser at 100 percent the image was quite right!!!
Ill try this new version now!!
I cant complain about this , but which will be the price?
Happy to here your problem are solved and you got great speedup
I think it will be fair enought for me the price!
Thanks for this.
why i dont have colored wireframe option for the last march built
" Release_multi_gpu_fast_AIdenoising_3" ?
its an old build ?
also what are those 5 newe exec in the blender folder ?
is this the reason why the blender devs arent so cool putting your speed-up in the main branch ?
As I said, it’s a bug in vanilla Blender introduced by animation denoising. It is more visible in E-Cycles because E-Cycles is faster, so the impact appears to be bigger. This beta build is build on top of master before the bug was introduced. It’s one bug that added on top of more than thousands already present, so it may take time to get fixed in master. I’ll have a look if I can backport wireframe to it, after the April update is finished.
Regarding the 5 exe, they are only used during build process, you can ignore them, I’ll remove them in the next build.
Regarding putting my speed-up in the main branch, it’s the other way round I guess, they respect other devs. If they committed it now to master, I would just have to stop working on E-Cycles as I can’t afford to work for free my whole life. Last time we discussed the subject, the BF prefered having Cycles devs to be external, paid by studios, companies selling Cycles like Insidium or render farms, etc. so that 2.8 has all the workforce.
One idea would be to introduce the new code to E-Cycles, then delay its submission to the dev. site for 3 or 4 months. That way your branch always has an edge in some respect, and you always have to keep working anyway so people stay on the subscription.
That’s exactly what happens, but with one year instead of 3-4 month. If someone manages to bring a 2x speedup on a renderer that was worked on by many PhDs and other smart people over many years every 3-4 month, that’s great, but I don’t know any devs capable of it.
Eventually, you’re going to run into the law of diminishing returns unless some revolutionary new technology comes along, but there’s a lot of room where smaller improvements can be made so a product only gets faster month to month (over a course of years).
If you want to wait a year that is fine, but please don’t be like a corporate patent holder who would prevent other devs. from submitting similar patches to the dev. site.