The flickerfree animation challenge

[mischterlampe]

Thank you for fixing the caustics.

Regarding the flickering, it is still there.
I totally understand your explanation so I rendered it with 4096 samples. This took about 4,5 minutes eache frame.
I have a ryzen7 2700x and two gpus (rtx 2060 super and rtx 2060)
So do you think there is such a imbalance between the calculation of teh eye and the light? I guess not.
Here is the final rendering with the flickering:
https://streamable.com/4ck00g

Here is it rendered with just the cpu 100% light tracing, 1000 samples.
https://streamable.com/zr9tmw

If I render the frames like I did before and move the camera just a bit, I don't get any flicker.
23frames
https://streamable.com/a6br4b

Is it possible that the camera movement/angle influece the light caustic calculation?

[mischterlampe]

I have some further question. I don't know if they are related to that flickering.

When I hit render in the viewport I get a result, which looks pretty like the normal rendering,
in the viewport the caustics are coming very late, meaning after 6s there are no caustics visible in the viewport, but there is also an error on the sideboard in the background. After 8s no visible change.
If I move the camera after 8s this error is gone, and the caustics are visible very fast.
What happens in the first 8s (hardware depending)? Could it be, that I want the "after 8s" result in my final rendering, but I get the other result, with the error on the sideboard.
https://streamable.com/s3d5x9

[mischterlampe]

Another issue, I came across, is that the glosiness threshold of the ind cache does not bahaving like expected.
As long as the material´s glossiness is below the threshod the material is not in the cache, it is black in the indirect debug view. If I change the material's glossiness higher than the threshold, it turns white, because it is in the cache now. But if i increase the threshold so it is higher than the material's glossiness it should turn black again, but this doesn't happen. It feels to me, that the photongi indirect cache glossiness threshold(pretty long) is hard coded to 0.05.
https://streamable.com/kd1p0q

[Dade]

When I hit render in the viewport I get a result, which looks pretty like the normal rendering,
in the viewport the caustics are coming very late, meaning after 6s there are no caustics visible in the viewport,

View port rendering uses by default RTPATHCPU: plain path tracing without light tracing.

[Dade]

Another issue, I came across, is that the glosiness threshold of the ind cache does not bahaving like expected.
As long as the material´s glossiness is below the threshod the material is not in the cache, it is black in the indirect debug view.

This is the correct behavior, indirect cache is about diffuse and glossy-nearly-diffuse materials (i.e. not specular). So everything over the threshold (i.e. not to "shiny" and "directional") ends inside the cache.

Light tracing and specular cache are used exactly for the opposite kind of materials: specular or glossy-nearly-specular materials. So everything under the threshold is considered.

[mischterlampe]

This is the correct behavior, indirect cache is about diffuse and glossy-nearly-diffuse materials (i.e. not specular). So everything over the threshold (i.e. not to "shiny" and "directional") ends inside the cache.

Sorry, but I don't get it. Please exlude the light tracing issue here (I disabled it for this test) and just focus on the indirect cache.
This means, if I rise the threshold, more and more materials should become black. But noting happens. If I rise the threshold to 0.9, which means almost every material should be not in the cache, doesn't exclude the materials, the debug image looks the same like the threshold of 0.05. I lowered the threshold to 0.001, but the result was the same. So changing the threshold of the indirect cache doesn't do anything.
Here is the result.

To sum it up, I can't include or exclude materials by changing the threshold value.

But this is just a side issue.

[Dade]

About the original problem. Metropolis has a warm up period where it works as a RANDOM sampler to estimate the average luminance of the image to render. When the warm up is done, Metropolis kick in.

Knowing the average luminance of the image to render is the only Metropolis requirement but it is not a trivial one: it must be know before doing the rendering (i.e. requires the crystal ball). If the estimation is wrong the result will be brighter/darker than the correct solution.

This the list of estimated average luminance of rendering exactly the same scene and changing only the seed:

Code: Select all

Luminance: 0.0202226	Compared to ground true: 106.6574076%
Luminance: 0.0179165	Compared to ground true: 94.49464672%
Luminance: 0.0180959	Compared to ground true: 95.44083262%
Luminance: 0.0186354	Compared to ground true: 98.28624673%
Luminance: 0.0192264	Compared to ground true: 101.4032805%
Luminance: 0.0196652	Compared to ground true: 103.7175858%

As you see, the estimation error can be really big (from 94% to 103% of ground true).

Why this problem is noticeable only when rendering light tracing for caustic ? Again some number:

Code: Select all

You need 63,234,600 of samples to have 50,000 not black results (i.e. caustic samples).

That is 0.07% of useful samples. It is very very very low. They are very hard to find paths.

I'm working on a better estimation method but FP32 numerical precision is also a huge problem with numbers so large.

[Dade]

Sorry, but I don't get it. Please exlude the light tracing issue here (I disabled it for this test) and just focus on the indirect cache.
This means, if I rise the threshold, more and more materials should become black. But noting happens. If I rise the threshold to 0.9, which means almost every material should be not in the cache, doesn't exclude the materials, the debug image looks the same like the threshold of 0.05. I lowered the threshold to 0.001, but the result was the same. So changing the threshold of the indirect cache doesn't do anything.

Have you disabled persistent cache ? Otherwise the cache is not re-computed.

[mischterlampe]

I'm working on a better estimation method but FP32 numerical precision is also a huge problem with numbers so large.

Thank you for the explanation, I can now understand, why it is flickering and I'm also very very happy, that you are working on the issue.
Do you know how other renderer like octane handle such an issue, or do they have the same issues?
So please keep me updated and don't hesitate to ask if I can do something for you. I can't write one line of code,

[mischterlampe]

Sorry, but I don't get it. Please exlude the light tracing issue here (I disabled it for this test) and just focus on the indirect cache.
This means, if I rise the threshold, more and more materials should become black. But noting happens. If I rise the threshold to 0.9, which means almost every material should be not in the cache, doesn't exclude the materials, the debug image looks the same like the threshold of 0.05. I lowered the threshold to 0.001, but the result was the same. So changing the threshold of the indirect cache doesn't do anything.

Have you disabled persistent cache ? Otherwise the cache is not re-computed.

Yep, the persitent cache was disabled and before that I changed the name of the .pgi to an non existing so blender tells me "no cache file available"