What's up with that?
I've noticed few times already that using same settings on opencl gives me all kinds of fireflies. As if it's ignoring clamping, or some other setting or I don't know...
metropolis CPUvsOpencl
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Re: metropolis CPUvsOpencl
Also, can someone explain what is the max consecutive rejects value doing(in human language)?
I'm comparing some final renderings using sobol and opencl with metropolis and very low mcr values and while this low value lowers some highlights it puts rendering speed on steroids.... I love it
ps: only on cpu, seems like this value is ignored by opencl?
I'm comparing some final renderings using sobol and opencl with metropolis and very low mcr values and while this low value lowers some highlights it puts rendering speed on steroids.... I love it
ps: only on cpu, seems like this value is ignored by opencl?
Re: metropolis CPUvsOpencl
Metropolis on GPUs is "problematic": there is a sampler for each rendering thread, the problem is that, for instance, you have 12 threads on a 6 core+hyper-threading CPU while you have 512,000 threads on a GPU (it is not a typo, it is 0.5M threads).
The end result is that the convergence speed of each Metropolis sampler on GPU is a LOT slower (i.e. 512,000 / 12) that CPU version.
In general, the two best solutions in LuxCore are brute force on GPUs (PATHOCL+SOBOL) and being smart on CPUs (BIDIRCPU+METROPOLIS).
The end result is that the convergence speed of each Metropolis sampler on GPU is a LOT slower (i.e. 512,000 / 12) that CPU version.
In general, the two best solutions in LuxCore are brute force on GPUs (PATHOCL+SOBOL) and being smart on CPUs (BIDIRCPU+METROPOLIS).
Re: metropolis CPUvsOpencl
source: LuxRender Render settings (old wiki)Metropolis
The metropolis sampler is an "intelligent" sampler that uses the Metropolis-Hastings algorithm and implements Metropolis Light Transport (MLT). The metropolis sampler tries to "seek the light". This makes it a good choice in almost all situations. It does this by making small random changes to an initial reference sample and looks to see if the new sample is more interesting, I.E. provides more light. If it is not, then the sample is discarded and a new sample is taken. If the new sample is a nice bright sample, metropolis will adopt the sample as the new reference sample. Then it explores the surrounding area using very small path mutations. This process of changing a sample is called a small mutation. This behavior can also lead to fireflies (overly bright spots in the image).
This process of mutation allows the metropolis to efficiently locate and explore paths which are important. However in order to avoid the sampler getting stuck on some small but very bright area it will once in a while generate a completely random sample and force this to become the new reference sample. This is called a "large mutation".
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The "maxconsecrejects" (Maximum Consecutive Rejects) parameter controls when to generate a path mutation. The default value is 512, so if 512 samples are discarded it generates a new path mutation (time to look somewhere else). Then the "lmprob" (Large Mutation Probability) parameter is used to determine the chances of generating a large path mutation (new completely random sample from somewhere else in the image) or a small path mutation (something nearby). Before a sample is added to the film, the metropolis sampler decides if the sample should be accepted as the new base for mutations or rejected (the previous sample is then used instead). Lowering the maxconsecrejects parameter introduces bias and mutes light sources and caustics. For caustics higher values are better. Raising the lmprob value also introduces bias, setting it to 1 turns metropolis into a dumb random sampler. Lower values are less biased and will produce a more realistic result. Be careful not to bring this too low or it may introduce undesirable effects.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
LuxRender's metropolis sampler is based on Kelemen's paper "A Simple and Robust Mutation Strategy for the Metropolis Light Transport".
&
Optimum Max Consecutive Rejects... (@ old LuxRender forums)
Re: metropolis CPUvsOpencl
Thanks guys, so maybe it would be good in blendluxcore disable the ability to run metropolis on both cpu+gpu? I know there is a warning that it can cause trouble but still...
So lowering max con rejects mutes high power samples right? But it's different from variance clamping right? If so, can we have a similar feature for path+sobol on ocl? I'm super hyped now that i see what low mcr values do to metropolis on cpu in terms of performance?
I don't care about bias, as long as it's not obviously wrong.
edit: ok so I was afraid to use variance clamping in night shots cause of how drasticaly it could change sun and sky look... but it seems it's doing really good magic without much of an impact in low light.. I wish this was more intuitive to use.
So lowering max con rejects mutes high power samples right? But it's different from variance clamping right? If so, can we have a similar feature for path+sobol on ocl? I'm super hyped now that i see what low mcr values do to metropolis on cpu in terms of performance?
I don't care about bias, as long as it's not obviously wrong.
edit: ok so I was afraid to use variance clamping in night shots cause of how drasticaly it could change sun and sky look... but it seems it's doing really good magic without much of an impact in low light.. I wish this was more intuitive to use.
Re: metropolis CPUvsOpencl
Ok, so this is the big issue with variance clamping. Low values can have little visual impact on indirect lighting, but will heavily impact direct lighting.
So can we please split direct and indirect light clamping? Or if you are against another editable parameter then maybe just disable direct light clamping...?
Right now it is a super usefull feature that can easily ruin the picture if it kills direct sunlight for example.
So can we please split direct and indirect light clamping? Or if you are against another editable parameter then maybe just disable direct light clamping...?
Right now it is a super usefull feature that can easily ruin the picture if it kills direct sunlight for example.
Re: metropolis CPUvsOpencl
It may be possible but it could mess (a LOT) the MIS so I'm not sure if the outcome would work.lacilaci wrote: ↑Sat Oct 27, 2018 12:59 pm Ok, so this is the big issue with variance clamping. Low values can have little visual impact on indirect lighting, but will heavily impact direct lighting.
So can we please split direct and indirect light clamping? Or if you are against another editable parameter then maybe just disable direct light clamping...?
Right now it is a super usefull feature that can easily ruin the picture if it kills direct sunlight for example.
Re: metropolis CPUvsOpencl
I see, well you rarely(or never) need to clamp direct lighting cause it is usualy not the source of noise and resolves quickly.Dade wrote: ↑Sat Oct 27, 2018 2:27 pmIt may be possible but it could mess (a LOT) the MIS so I'm not sure if the outcome would work.lacilaci wrote: ↑Sat Oct 27, 2018 12:59 pm Ok, so this is the big issue with variance clamping. Low values can have little visual impact on indirect lighting, but will heavily impact direct lighting.
So can we please split direct and indirect light clamping? Or if you are against another editable parameter then maybe just disable direct light clamping...?
Right now it is a super usefull feature that can easily ruin the picture if it kills direct sunlight for example.
This is why corona for example only lets you tweak max indirect intensity and cycles has both direct and indirect, but it just doesn't make sense clamping direct lighting.
The bad effect of clamped direct light is however very prominent and immediately ruins contrast of the image.
Re: metropolis CPUvsOpencl
I think all the frustration around all that biased vs unbiased and tricky features request will mostly be cooled down by LC2 (indirect light acceleration feature). I'm myself facing all the same limitation each time i work on a new project ( mostly interior archviz) , it's so hard to wait and work on path tracing for indirect dominant 3D scene now that we know LC2 is planned.It may be possible but it could mess (a LOT) the MIS so I'm not sure if the outcome would work.
I'm myself working currently on a very serious interior project all Image have to be rendered in 2k (The printer ask for 4K but can't afford this). Compared to old Lux 1.X series it is day and night ( impressive speed and quality at the same time ) adaptive sampling and Visibility map feature help a lot ( Thank Dade and BYOB for that).
Lacilaci i can really understand you sometimes i wake up by night on my bed and just wonder how beautifull thing could be if LC2 was already implemented inside the engine. My heart and my brain are litterally screaming for this feature all the time ( WTF 4X to 8X speed up in interior rendering compared to current already good version is total insanity). The first opensource renderer to support LC2 even on GPUs (opencl) This is terrorism Dade should go to the jail for only mentionning this feature .
This is my confession even if i can look super self controlled sometimes i'm completely burning inside while waiting for this to happen
Now i'm Out