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
However, it should be noted that you can get a better looking render with “CleanAux” on and “Prefilter” off in certain situations.
Here’s an example (the results aren’t perfect, there is an artifact in part of the image, but other parts do look better. It all depends on your scene):
“CleanAux” off, “Prefilter” off: Link
Yes, I can see a little better preservation of the textures. But CleanAux=ON when Prefilter is OFF is giving artifacts/noise in scenes not only in Fishy Cat eyes, but also in Classroom on metal part of chairs for example (zoom in):
My understanding is the use case for “CleanAux” on and Prefilter off is when you have a relative noise free image and you want to preserve as much texture detail as possible. That is use case where NLM does better than OIDN at preserving detail for relative clean image.
“CleanAux” on is telling ODIN that you have relative clean image when it does it’s denoising to preserve more texture detail. For noisy or low sample image you would need to turn on “PreFilter” to clean the image and avoid artifacts, but with loss of some texture detail.
IMHO the NLM is still preserving texture detail slightly better than ODIN for relative clean image with “CleanAux” on and “PreFilter” off. It has improve considerably and does such fantastic job with noisy/low sample images.
CleanAux propably means “clean auxiliary channels”. ODIN’s 1.4.1 new ace feature is that if you give it clean/noisefree auxiliary channels like normals and albedo it will denoise the final image much better than older ODINs. CleanAux has nothing to do with the combined rendered image only with the albedo/normal channels. “Prefiltering” enable filtering those then feed them to ODIN in hope ODIN will do it’s magic and denoise like the aux channels are clean. If your aux channels are noisy and you don’t prefilter ODIN will introduce new artifacts by assuming the aux are clean (CleanAux is set). Too low on samples won’t clear the aux channels and therefore give you a bad result. Turn on prefilter for those. But with clean aux channels you get a much better denoise.
Sorry, but your view is very shortsighted, the qualitative improvement is huge with prefiltering. I can see that for veeeery low sample counts and render times of only a few seconds it might be not worth the +2 sec (+13 on your side), but boy for normal to higher sample counts you get a much better render. I would need to almost double the sample count to get the same quality without the new ODIN with prefiltering. Try it you may save a LOT more time with prefiltering than the 13 sec you put more into. Render times for prefiltering are under 2 seconds for FullHD on my many years old i7-8700K home CPU. Are you rendering on your Texas Instruments calculator? More than 6-7x slower than a CPU from end 2017? Please understand that CyclesX can’t do magic on prehistoric hardware and need to move Blender into the future not anchor it in the past. Do yourself a favor and try to get a better machine (CPU for working and denoising) plus a descent GPU for rendering, it will blow your mind.
I would wish that such a post that contains pinpricks for users who unfortunately cannot afford a decent PC will be filtered out by an administrator in the future.
I believe that it is possible to also objectively put forward his arguments without anyone must feel bad about it
Ok let’s put it this way: he’s bragging about a fantastic feature, which massively cuts down on render times because it adds a few seconds on his ancient pc. What about the much bigger amount of time it saves by creating cleaner renders? So let’s stop adding fantastic features because some guy don’t understand the benefits because his PC is so abysmally weak that he never renders normal scenes with normal sample counts, where the advantages of a short 1-2 sec additive denoising time pale in contrast to many minutes/hours rendertime saved? I don’t think that a CPU from end 2017 is somewhat of an expensive machine for 3d animation. Nor is a CPU from 2014, but come on, 7 times slower than a 8th gen Intel or or even 13x times slower than a modern consumer CPU?
2 square samples are about 4 samples right? First of: “What a time to be alive !” if we can get that cool results with only 4 samples, but Ii you use real production sample numbers for the real deal in quality (roughly 128 and above, sometimes up to 4096) then you will see how beneficial the new ODIN is. If the Albedo and Normal auxiliary passes (the “Aux” in CleanAux) don’t get clean by itself or prefilter denoising they can’t benefit the new 1.4.1 algorithms to create a better overall denoising and introduce new artefacts. But with realistic sample numbers they get much cleaner and can be prefiltered much better and then the overall denoising is much better than with the old ODIN. Give it a try with higher sample counts. You won’t get cleaner renders with ODIN 1.4.1 if you start with thrash, but inside the usable descent range of quality you get better denoising. I’m totally hooked up for the new ODIN it’s a blast.
I can see that volumes in front of geometry are giving the new ODIN a hard time because the Albedo and Normal passes don’t get clean so easy. Hope they find a solution for this.
Has Cycles-X killed Ambient Occlusion additive light from World Properties?
I see it only in fast GI, but no more additive scene AO based light’s
Very usefull for some scenerys reducing noises, fast lighting or artistic purpose.
I really expected that with OIDN there would be no noise/artifacts in any circumstance. Blurry images or lack of detail at low samples is one thing I could expect. But noise/artifacts is something I was not expecting.
Also in the current state with CleanAux=ON when Prefilter=OFF we will not have a fast noise free result at low render samples for Viewport with OIDN (Prefilter takes more time in my tests, almost double the time at 5 samples in viewport and working for each frame). If most of the users think that it is fine in its current state, ok, no problem.
I “abandoned” the patch and didn’t add any reviewers because this wasn’t a patch I thought should be reviewed, just a patch I thought I would upload to the developer.blender.org website so people like YAFU can more easily apply it to their branch of Blender.
The other thing is, if the patch was left open for review by the developers and they asked me to make other changes, then I may not be able to do them as I have very limited knowledge with programming and the Blender source code.
Besides, it’s also a very simple patch, so if someone wanted to recreate it for a commit, it would be very quick to do.
