OIDN has been updated to v1.4.1 , so all the improvements OIDN v1.4.X brings should be available in the compositor and render properties.
However, the extra improvements (CleanAux and Prefilter) aren’t available in the compositor node yet.
1 Like
That is time in seconds.
I just compared today’s build (fd9c4f166b61) with yesterday’s build (8c577cd4040a) using my test file. The OIDN render time part in the old build was 12 seconds and in the new build 25 seconds. Changes are noticeable in the image, but they cannot be categorized as improvements.
Thus, OIDN has degraded by a factor of 2.08 (25 seconds to 12 seconds).
I hope that this will be investigated.
The most likely cause for this is the “prefilter” step of OIDN. You can disable it here:
According to Sergey, this step takes “0.5 seconds per pass” to process on a FullHD render with a Intel core i9-11900K. As you increase the resolution of the render, and change the hardware used this processing time will change.
Source: rBfd9c4f166b61
Try disabling it and seeing if that helps.
1 Like
Thank you very much for your helpful hint.
By deactivating I get back to the old fast values.
Since I work with an older PC, it is important for me to disable this most of the time and I hope that Cycles will disable this switch by default in the future, since the qualitative improvement seems to be only marginal for me.
By the way: You are doing a great job here
Update: Just did some more testing. This seems to be a CPU viewport only problem, and it is not really related to the light threshold, turning light threshold to 0 just made it easier to see, but it is not the cause of it. CPU is fine in the final render. GPU is fine both in viewport and final render.
CPU Viewport:
GPU Viewport:
Final render works fine for both CPU and GPU.
Now I am more confident that this is a bug. Hope it gets fixed soon. I still don’t understand why this is happening though, wonder why CPU viewport would look like this.
EDIT: Test Blend File:
@Eary and @rtdietrich With the recent changes made to the Cycles-X branch of Blender in relation to OIDN, two things were changed.
- “CleanAux” is enabled at all times (unless using the compositing node (this may change in the future)).
- “Prefiltering” is an option you can change.
“CleanAux” being enabled at all times can mean you get artifacts like the one shown in the image below if your sample count is relatively low. “Prefiltering” can be used to help avoid this issue. But in the case of @rtdietrich where the use of prefiltering on a old processor introduces a lot of extra processing, it might be preferable to render with “CleanAux” off and “Prefiltering” off, ultimalty getting a blurrier render, but avoiding artifacts and long processing time. At the moment you can not adjust the “CleanAux” value without modifying the source code.
This issue was NOT present prior to the recent changes because the code was designed around OIDN V1.3 which did not have a “CleanAux” option.
sorry if this doesn’t make much sense.
I will bring this use case up with someone and see if the “CleanAux” setting can be exposed to the end user.
2 Likes
Hi. I really don’t understand anything about technical matters. The only thing I can say is that from that commit I get a similar result comparing Cycles-X before the Prefilter option is incorporated, with when Prefilter is ON in the new Cycles-X. In other words, now when Prefilter is OFF the result is worse than old version of Cycles-X before Prerfilter option is incorporated:
All tests performed with the following settings in the View Layer tab: Color+Albedo+Normal and Prefilter changes from that View Layer tab (just in case people think that Viewport similar option influences the final Render result)
Cycles-X (8c577cd4040a) - Fishy Cat 10 samples:
Cycles-X (fd9c4f166b61) - Prefilter OFF - Fishy Cat 10 samples:
Cycles-X (fd9c4f166b61) - Prefilter ON - Fishy Cat 10 samples:
Cycles-X (8c577cd4040a) - My Scene above - 1 sample
Cycles-X (fd9c4f166b61) - Prefilter OFF - My Scene above - 1 sample
Cycles-X (fd9c4f166b61) - Prefilter ON - My Scene above - 1 sample
So in my current state tests, Prefilter ON is the one that is giving similar results to Cycles-X when Prefilter option did not exist. I was really expecting that Prefilter OFF would be the one that looks the most like old Cycles-X when Prefilter option didn’t exist.
You can disable it for all future scenes you create by disabling it then saving that that file as your new default. That way each time you create a new file, the setting is disabled. Ideally this should be done after the Cycles-X branch is merged into the master branch of Blender.
For instructions on how to save a file as your new default, read below:
- Open Blender and make the changes you want to make.
- From the top of Blender select “File → Defaults → Save Startup File”
- Now you’re done. Every time you open Blender and create a new scene, it will start with the changes you made here.
This is correct. These are the results you observe and I observe in my own tests.
This is because of what happened in the recent OIDN changes. Two main settings were changed. “Prefiltering” and “CleanAux”. Actually, here’s a thing that will hopefully explain it better.
Prior to the recent commits, Blender would always denoise the scene with these settings:
CleanAux = off
Prefiltering = off
And this is the result you observe here:
With the recent commits, Blender will denoise the scene with these settings:
CleanAux = on
Prefiltering = Defined by the user in the UI
This means with “Prefiltering” off in the new version of Blender, the results WILL be different when compared to the old version. This is because “CleanAux” is on in this new version when it was not in the old version.
As for why the results with “Prefiltering” off look so much noiser compared to old versions of Blender, that’s because the “CleanAux” setting (which is now enabled at all times) introduces issues like these at low sample counts unless “prefiltering” is turned on.
As for why the “CleanAux” setting can’t be adjusted, that’s still up for debate. I’ve done an investigation into how useful it will be to have the “CleanAux” setting available to the user in the user interface and I’ve given the investigation results to the Blender developers, just waiting on their decision on whether or not to expose this setting to the user or make other adjustments.
Hopefully this helps? I’m sorry, I’m trying to keep messages short, and my though process changes a lot while writing them and I don’t know the technical knowledge of everyone here, so some of this may not make sense. Just ask if you want more information, or if you want a more technical explaination.
1 Like
Ok, I don’t know what to say. In principle I think this could get confusing in the simple logic of simple users like me. What is the new feature in OIDN 1.4? It is Prefilter. Oh, ok. so with Prefilter OFF give me a similar result to the one I got with OIDN 1.3. And that is not happening.
======
Now here a comparison with native NLM:
Cycles - NLM (default settings) - 100 samples
Cycles-X - OIDN Prefilter OFF - 100 samples:
Cycles-X - OIDN Prefilter ON - 100 samples:
What he said was basically, there are two new features, not one. But only one of them has a UI button. This is the current problem and he is trying to:
1 Like
Oh ok. I see. Thanks.
As a side note: This diff returns the behavior @YAFU expects. Turning off prefiltering will return OIDN to the way it was before the recent commits by also turning off “CleanAux”.
https://developer.blender.org/D12094
If you would like to build a custom version of Cycles-X with this change, feel free to do so.
Thanks, I’m going to test the patch. Probably we would have to, through options, still obtain the same results as with OIDN 1.3 (good final result without the extra time penalty of using Prefilter ON). But still a bit confused, I don’t have strong opinions.
By the way, do you think that the not very good results that we are obtaining with OIDN / OptiX compared to the examples that OIDN / OptiX developers publish is due to problematic passes that we are using in Blender? See discussion from here:
https://developer.blender.org/T78571#975299
I’m personally in favor of giving the end user as much control as possible. And allowing them to change settings to make a trade off between performance and quality can be useful.
However, when I made the suggestion to expose extra settings for OIDN to Sergey, this is the response I got:
When exposing option to the interface it needs to have clear semantic meaning and usecases for artists. We should not expose setting in the interface just because it exist in some underlying algorithm. Generally, we should avoid situations like “try this option and see if things are better or worse when it’s ON or OFF” (as it is not practical when working on animation).
⚙ D12043 Cycles X: Support OIDN with guiding pass prefiltering
And this is a valid point. Also, as we expose more settings to the end user, we’re more likely to get “bug reports” as some users don’t understand how multiple different settings interact with each other. For example, turning one setting off might be fine. Turning another setting off might also be fine. But both at the same time produces less than desirable results. So, keeping user adjustable options to the minimum is also preferred in a sense.
I don’t work on the OIDN or OptiX projects, I also don’t know the really technical details of either. As such I can’t comment. However, in the report you linked, there is a issue with the denoiser that is caused by the denoising passes provided by Cycles. In theory a change to Cycles code can fix this specific situation, however I don’t have the technical knowledge to comment on if this issue is Cycles only or if it affects other render engines or if it’s a easy fix or a hard one.
However, I believe part of the “issue” with denoising done by users appearing worse than examples shown on developer websites might just be that Intel and Nvidia will choose the “best case scenarios” to show off their denoisers or use mis-leading examples.
Also, there are a lot of little settings that you can adjust to get better denoising with OptiX and OIDN that aren’t tied to the normal or albedo passes. And it’s possible Cycles doesn’t have an optimal set of default settings for these.
Extra thing: I keep saying “we”. It might imply that I am part of the Blender development team. I’m not.
I’ve seen this before, and developers in principle have a good point there, as long as they decide to name Blender options with its correlative “technical name” in the option. And perhaps that is part of the problem, the end user does not always need to know technical questions in the name of the options. In this case, for example, Options could just be simple understandable names, such as (just as an example ): “Fast”, “Balanced”, “Best” (each option would have different sets of technical things enabled or disabled that the user does not need to know). Then in Tooltip and documentation talk about technical issues and what each option does, pros and cons and which of them is better to preserve textures, etc.
Developers may believe that these things are not important. But you see the success of forks like E-Cycles, where many times you can get results similar to official Cycles or some free fork on github, but the difference is ease of GUI presets/names. Users are willing to pay for these things, regardless of whether they can reach the same results with other free versions of Blender but where option names are very technical or more difficult to configure.
Edit:
Even I am almost in conflict with what I have expressed above, because I prefer to have as many “technical options” available exposed in GUI for greater possibility of different configurations for different scenarios. But I understand that for many Artists this is more difficult and tedious to configure.
Well, that’s one way to solve it, of course, but fortunately I found a much more elegant solution which also solves many other problems.
Part of the solution is already built into Blender in the form of the render presets. Unfortunately, from my point of view, they don’t work very well, because there are far too few settings summarized and therefore I consider it almost useless to use them in this form.
Fortunately, the solution is very simple.
I simply take this file modified in the attachment, create several variants of it and save them as described in the file with the ending “.py”
Extended-Render-Preset.txt (1.7 KB)
.
With one click I have different render settings which not only influence the sampling rate but go far beyond it (see file in the attachment). If you like you are welcome to use them. I don’t want to work without them anymore.
The new Presets will be found in Blender under:
Render Properties ==> Sampling ==> Sampling Presets
A solution would be to simply couple the deactivation of prefiltering with the deactivation of CleanAux in the background, then no one would be confused