Re: OpenImageDenoise
Posted: Thu Feb 07, 2019 7:47 pm
yes yes... maybe bidir on gpu? 
In OpenCL v2.2 or CUDA, may be ... in OpenCL v1.2 ? I would prefer to shot on myself ... less painful.
LuxCoreRender Forums
Show your work, get help, participate in development
https://forums.luxcorerender.org/
OpenImageDenoise
Page 23 of 32
Re: OpenImageDenoise
Posted: Thu Feb 07, 2019 10:29 pm
Re: OpenImageDenoise
Posted: Fri Feb 08, 2019 7:09 am
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
+1lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
Re: OpenImageDenoise
Posted: Fri Feb 08, 2019 8:40 am
Agreed, I see huge potential for a better synched combination of adaptivity and denoising.lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
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
Exactly,epilectrolytics wrote: Fri Feb 08, 2019 8:40 amAgreed, I see huge potential for a better synched combination of adaptivity and denoising.lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
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.
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
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.
But aside this I want look again into adaptive samplers in the future.
Re: OpenImageDenoise
Posted: Fri Feb 08, 2019 10:24 am
I guess they are talking about tiling. If the noise estimation is based on tiles that will possibly irritate the algorithm.Dade wrote: Fri Feb 08, 2019 9:53 am Note: Oidn suggests to disable adaptive sampling because it works better with uniform noise.
Re: OpenImageDenoise
Posted: Fri Feb 08, 2019 10:28 am
Well from github I gathered that something like weighted sampling could create a correlation that could break denoiser.epilectrolytics wrote: Fri Feb 08, 2019 10:24 amI guess they are talking about tiling. If the noise estimation is based on tiles that will possibly irritate the algorithm.Dade wrote: Fri Feb 08, 2019 9:53 am Note: Oidn suggests to disable adaptive sampling because it works better with uniform noise.
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
FIXED!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).
Latest build LuxCore of 2019.2.8. works again!
Thanks guys!