Page 23 of 32

Re: OpenImageDenoise

Posted: Thu Feb 07, 2019 7:47 pm
by lacilaci
yes yes... maybe bidir on gpu? :D

Re: OpenImageDenoise

Posted: Thu Feb 07, 2019 10:29 pm
by Dade
lacilaci wrote: Thu Feb 07, 2019 7:47 pm yes yes... maybe bidir on gpu? :D
In OpenCL v2.2 or CUDA, may be ... in OpenCL v1.2 ? I would prefer to shot on myself ... less painful.

Re: OpenImageDenoise

Posted: Fri Feb 08, 2019 7:09 am
by lacilaci
Dade wrote: Thu Feb 07, 2019 10:29 pm
lacilaci wrote: Thu Feb 07, 2019 7:47 pm yes yes... maybe bidir on gpu? :D
In OpenCL v2.2 or CUDA, may be ... in OpenCL v1.2 ? I would prefer to shot on myself ... less painful.
Ok, I'm just asking, cause oidn made bidir also attractive in some cases.
So maybe best solution would be:

1. Pathtracing on OpenCL + cache + OIDN
2. BiDir on CPU + pathguiding + OIDN

I personaly think adaptivity should be revisited in general. I remember when good working adaptivity gave quite a boost to corona as well so it shouldn't be left at it's current state where it kinda helps a bit with caustics but otherwise it is not doing anything at all!

Re: OpenImageDenoise

Posted: Fri Feb 08, 2019 8:02 am
by provisory
lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
+1

Re: OpenImageDenoise

Posted: Fri Feb 08, 2019 8:40 am
by epilectrolytics
lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
Agreed, I see huge potential for a better synched combination of adaptivity and denoising.
Basically the path tracing has to stop way earlier (when the noise level is still high but manageable for OIDN) in the easy areas and then concentrate on the difficult areas until those get into "denoiseable" range.
So the threshold for adaptivity becomes relevant here and the question is if it can be tuned that way.

Re: OpenImageDenoise

Posted: Fri Feb 08, 2019 9:16 am
by lacilaci
epilectrolytics wrote: Fri Feb 08, 2019 8:40 am
lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
Agreed, I see huge potential for a better synched combination of adaptivity and denoising.
Basically the path tracing has to stop way earlier (when the noise level is still high but manageable for OIDN) in the easy areas and then concentrate on the difficult areas until those get into "denoiseable" range.
So the threshold for adaptivity becomes relevant here and the question is if it can be tuned that way.
Exactly,

Evenly distribuded noise means even denoising quality accross image.
This also means that in theory you can do a quick crop render to estimate needed samples amount for final render and that means you can exactly predict time and quality of the rendering.

Currently, shadowy area with lot of gi noise and reflection will need way more samples than the rest of image even with adaptivity, and I've seen bunch of situations where adaptivity made it worse since it seemingly actually prefered bright/high power areas.

Re: OpenImageDenoise

Posted: Fri Feb 08, 2019 9:53 am
by Dade
Note: Oidn suggests to disable adaptive sampling because it works better with uniform noise. So all this argument could just lead to Oidn not working anymore if we have a too aggressive adaptive rendering.

But aside this I want look again into adaptive samplers in the future.

Re: OpenImageDenoise

Posted: Fri Feb 08, 2019 10:24 am
by epilectrolytics
Dade wrote: Fri Feb 08, 2019 9:53 am Note: Oidn suggests to disable adaptive sampling because it works better with uniform noise.
I guess they are talking about tiling. If the noise estimation is based on tiles that will possibly irritate the algorithm.

Re: OpenImageDenoise

Posted: Fri Feb 08, 2019 10:28 am
by lacilaci
epilectrolytics wrote: Fri Feb 08, 2019 10:24 am
Dade wrote: Fri Feb 08, 2019 9:53 am Note: Oidn suggests to disable adaptive sampling because it works better with uniform noise.
I guess they are talking about tiling. If the noise estimation is based on tiles that will possibly irritate the algorithm.
Well from github I gathered that something like weighted sampling could create a correlation that could break denoiser.
For example metropolis is suggested to not to be used aswell but, in luxcore it breaks denoiser in very early stages of rendering, after a while it works again.

Re: OpenImageDenoise

Posted: Fri Feb 08, 2019 2:16 pm
by epilectrolytics
epilectrolytics wrote: Thu Feb 07, 2019 10:58 am This morning I downloaded all the latest builds and put them into BlendLuxCore addon:
Indeed it works with Path CPU and crashes with Path OCL.
My Windows says all drivers are "the best" but I installed the latest nVidia game ready drivers anyways: no change, still crashes.
After exporting the scene for LuxCoreUI I found:
From the commits of 2.6.2019:
b21b129 (oidn fix) works
d083c3c (albedo bounce) crashes
53d96c0 (bidir bounce) crashes

Update:
Just tried to render without the wood texture and it works!
With texture it crashes (Texture provided in link above).
Also I can render Cornell scene with PathOCL just fine.
Maybe this should be moved to User support and continued over there?

Update2:
Further testing revealed that generally materials with image textures cause the latest builds to crash when rendered with PathOCL (Win10Pro).
FIXED!
Latest build LuxCore of 2019.2.8. works again!
Thanks guys!
:D