lacilaci wrote: ↑Fri Feb 01, 2019 5:53 pm
I see... But this also means that you can only use albedo+normal pass in hdr mode right?
Not sure what you mean?
I think what we will do is: supply to the denoiser the following AOVs:
- Combined aka Beauty (anti-aliased, 4 byte float aka HDR)
- Shading normals (4 byte float)
- Albedo (anti-aliased, 4 byte float)
We will of course use the HDR mode, and I see no reason why we should use a different configuration for viewport renders.
I always thought that viewport rendering would take much longer when rendering extra aov's. But that's me, being a simple person
One way or another, GI caching, proper denoising, and some day also 2.8 support sounds like good times for luxcore... (I can't believe the last time I used luxrender-some hallway benchmark, before I was using blender I though this is a dead end no future renderer)
lacilaci wrote: ↑Fri Feb 01, 2019 5:41 pm
This is precisely the reason I always was complaining about BCD. It has no feature recognition and no aov's that help keep edges and textures sharp.
Me too, I have been using Luxcore for caustic rendering only because for normal stuff Cycles + denoiser was faster.
I'm looking forward to ditch Cycles and do everything in Luxcore once it finally has decent denoising.
Only my GPUs run a little better in Cycles Cuda than Luxcore OCL.
B.Y.O.B. wrote: ↑Fri Feb 01, 2019 5:53 pm
lacilaci and me were talking about the shading normal AOV.
I edited my post to make it less confusing.
Oh boy, albedo pass works wonders, look under table. Recovered from absolute unreadable noise / 32 passes!
However, the shading normal pass is very jagged/aliased so it actually ruins edges instead helping them. This is hopefuly cause I did this test in LDR... So, next I'll try exr's and we'll see. (maybe it would still make sense to have an option for antialiased normal pass?)
lacilaci wrote: ↑Sat Feb 02, 2019 6:10 am
Oh boy, albedo pass works wonders, look under table. Recovered from absolute unreadable noise / 32 passes!
However, the shading normal pass is very jagged/aliased so it actually ruins edges instead helping them. This is hopefuly cause I did this test in LDR... So, next I'll try exr's and we'll see. (maybe it would still make sense to have an option for antialiased normal pass?)
...So HDR works much better, incredible recovery from 32 passes. I still think there's something wrong with shading normal pass, it just doesn't provide enough detailed edges and bumps.
anyway, this + cache + gpu and we'll have 5 minute renderings of interiors and 5 second preview renders.
And one more example.
This is a crop from 10minute 4K rendering(on my outdated 4770K!) that was denoised in 7.5 seconds.
Again, I think that the shading normal pass is rendering very slowly, especially texture bump maps are very noisy for too long, if it was cleaner the details would be even better.
So if I think about your own interior benchmark scene. It is now set for final quality at 3000 samples. With this denoiser you could get the same quality with only 300! samples, that's 10x speedup for rendering. But shading normal needs to provide cleaner edges, it's still crap at 300 samples and it shows in the denoising.
In your examples I notice a clamping effect, all bright parts are dampened.
Also the examples on their site showed less contrast.
That would need correction in post if it cannot be prevented inside the denoiser engine.
epilectrolytics wrote: ↑Sat Feb 02, 2019 7:34 am
@lacilaci: Thanks for testing!
In your examples I notice a clamping effect, all bright parts are dampened.
Also the examples on their site showed less contrast.
That would need correction in post if it cannot be prevented inside the denoiser engine.
There is no clamping happening, it's filmic tonemapping applied after bringing denoised result back to blender. I just didn't really care about postproduction during this testing. I wonder where do you even see any clamping difference since it should be present in both input and output.
epilectrolytics wrote: ↑Sat Feb 02, 2019 7:34 am
@lacilaci: Thanks for testing!
In your examples I notice a clamping effect, all bright parts are dampened.
Also the examples on their site showed less contrast.
That would need correction in post if it cannot be prevented inside the denoiser engine.
There is no clamping happening, it's filmic tonemapping applied after bringing denoised result back to blender. I just didn't really care about postproduction during this testing. I wonder where do you even see any clamping difference since it should be present in both input and output.
I just loaded denoised hdr back to blender and went -6 stops and I clearly see details that would get clamped if there was any clamping. So yeah, no clamping whatsoever.
What you might observe though, is slight loss of contrast with GI in very noisy areas. But that's only in extreme examples cause you have to understand there is little to nothing to work with in those noise heavy areas (It is actually pretty impressive how it can recover even somewhat proper lighting with very few samples)
lacilaci wrote: ↑Sat Feb 02, 2019 7:38 amit's filmic tonemapping applied after bringing denoised result back to blender.
Ah I see, that's another possible source.
But all images you showed have very prominently less contrast in the highlights, in your own example the midtones are brighter.
I'd not accept when the denoiser was messing up the light balance to this extent, but it probably needs more testing.
lacilaci wrote: ↑Sat Feb 02, 2019 7:38 amit's filmic tonemapping applied after bringing denoised result back to blender.
Ah I see, that's another possible source.
But all images you showed have very prominently less contrast in the highlights, in your own example the midtones are brighter.
I'd not accept when the denoiser was messing up the light balance to this extent, but it probably needs more testing.
It doesn't mess with anything, if you look at intel's own examples in gallery and look at those examples that are near final quality (car on street, or house with pool) you can see it doesn't do absolutely anything with lighting.
In my last example you see pretty big difference cause in the extremely noisy render there is simply not enough samples to properly show the lighting.
But I asure you (since I've rendered this scene fully) that the lighting in denoised result is much closer to how a final raw render looks like than the observable lighting in the noisy example. It looks weird cause no postprocessing aside shitty tonemapping preset is used, but if I'd render to 4000 samples the denoised and non-denoised result would look pretty much the same in terms of lighting
