PhotonGI cache

[Sharlybg]

Luxcore = Total Luxury

[Dade]

What puzzle me is that I'm quite convinced now that the problem is not in PhotonGI at all but in backward Vs.forward ray tracing results (aka Path tracing Vs. Light tracing). PhotonGI incidentally just does light tracing.

This is a rendering with PATHCPU (no PGI involved):

path.jpg

And this with LIGHTCPU (no PGI involved):

light.jpg

The difference is striking. I'm starting to think the problem may be in using "true" HDR and importance sampling (i.e. LIGHTCPU ends to emit only 1 out 1000 particles from low power HDR pixels).

This problem was driving me crazy than I have finally noticed that test scene was using variance clamping of 1 .... damn, variance clamping requires different values between forward and backward ray tracing. It was the source of the above problem. Another strange setting of the scene was the 64 max. path depth ... 64 ?!?

Anyway back to square one and looking for the source of problem.

[lacilaci]

What do you mean by different values? I though that photongi doesn't even use clamping...
About path depth... if too low values like 4 and lower are a bit low, and above 8 seem to not make too big diffrence... maybe we should simply have hardcoded 8 or 16 and get rid of it. Especially if it can break stuff!

EDIT: unclamped rendering (also used photon depth of 8) shows just as big difference, if not bigger. So I don't know if clamping even matters in this issue.

unclamped no pgi:

unclamped + pgi:

[lacilaci]

I might be missinterpreting stuff here, but to me it looks like cache looks at first hit ok, then it somehow got overwriten by weaker entries but then at some places bounces with proper power, might also be source of some leaks.... no?

[andreymd87]

I might be missinterpreting stuff here, but to me it looks like cache looks at first hit ok, then it somehow got overwriten by weaker entries but then at some places bounces with proper power, might also be source of some leaks.... no?

cache_entries.jpg

not sure about this but fully biased solution always will come with these leaks if no proper settings are used. maybe a better solution will be a partial caching method wich is slightly slower but with light leaks free, like corona has

[lacilaci]

I might be missinterpreting stuff here, but to me it looks like cache looks at first hit ok, then it somehow got overwriten by weaker entries but then at some places bounces with proper power, might also be source of some leaks.... no?

cache_entries.jpg

not sure about this but fully biased solution always will come with these leaks if no proper settings are used. maybe a better solution will be a partial caching method wich is slightly slower but with light leaks free, like corona has

Corona's solution isn't completely problem free, it's basicaly two presets, one for stills and one for animation.. And I think some general multiplier value if you need even more precise cache to avoid flickering.

I think this cache works really well and we could eventually establish preset modes instead all setings exposed as well.. But this brightness issue is something different and it definitely looks like a bug. Although for me personally this bias isn't too big and I'm ok with it. Many people will definitely have issues with such difference.

[andreymd87]

I might be missinterpreting stuff here, but to me it looks like cache looks at first hit ok, then it somehow got overwriten by weaker entries but then at some places bounces with proper power, might also be source of some leaks.... no?

cache_entries.jpg

not sure about this but fully biased solution always will come with these leaks if no proper settings are used. maybe a better solution will be a partial caching method wich is slightly slower but with light leaks free, like corona has

Corona's solution isn't completely problem free, it's basicaly two presets, one for stills and one for animation.. And I think some general multiplier value if you need even more precise cache to avoid flickering.

I think this cache works really well and we could eventually establish preset modes instead all setings exposed as well.. But this brightness issue is something different and it definitely looks like a bug. Although for me personally this bias isn't too big and I'm ok with it. Many people will definitely have issues with such difference.

maybe you are right. let's just follow the development and see how this problem is resolved.

[Dade]

What do you mean by different values? I though that photongi doesn't even use clamping...
About path depth... if too low values like 4 and lower are a bit low, and above 8 seem to not make too big diffrence... maybe we should simply have hardcoded 8 or 16 and get rid of it. Especially if it can break stuff!

EDIT: unclamped rendering (also used photon depth of 8) shows just as big difference, if not bigger. So I don't know if clamping even matters in this issue.

unclamped no pgi:
unclamped_nopgi.jpg
unclamped + pgi:
unclamped_pgi.jpg

Your no pgi rendering is very different from before while the pgi one is about the same: viewtopic.php?f=5&t=840&start=640#p10692

You are mixing different tests.

[Dade]

I might be missinterpreting stuff here, but to me it looks like cache looks at first hit ok, then it somehow got overwriten by weaker entries but then at some places bounces with proper power, might also be source of some leaks.... no?

It is because the geometry is bad: check the roof, it is a single plane, not a real wall with a depth, this is a bad idea, it can cause light leaks even with normal path tracing.

[lacilaci]

What do you mean by different values? I though that photongi doesn't even use clamping...
About path depth... if too low values like 4 and lower are a bit low, and above 8 seem to not make too big diffrence... maybe we should simply have hardcoded 8 or 16 and get rid of it. Especially if it can break stuff!

EDIT: unclamped rendering (also used photon depth of 8) shows just as big difference, if not bigger. So I don't know if clamping even matters in this issue.

unclamped no pgi:
unclamped_nopgi.jpg
unclamped + pgi:
unclamped_pgi.jpg

Your no pgi rendering is very different from before while the pgi one is about the same: viewtopic.php?f=5&t=840&start=640#p10692

You are mixing different tests.

no I'm not. they're different but just a little bit

unclamped gi caching:

clamped gi caching:

EDIT: also fixing roof/ceiling geometry doesn't change anything...