PhotonGI cache

[Sharlybg]

So if only we could include more reflective shader with less bias then ***** BOOOMM*****

I know i ask to much but is there any tiny possibility ?

[B.Y.O.B.]

Two ideas from my side:

• Maybe the usage threshold scale should not introduce a sharp border between brute force and cache, but a soft transition instead?
• Is it possible to use the cache for the matte base of a glossy material, but use brute force when sampling the glossy reflections?

[lacilaci]

Two ideas from my side:

• Maybe the usage threshold scale should not introduce a sharp border between brute force and cache, but a soft transition instead?
• Is it possible to use the cache for the matte base of a glossy material, but use brute force when sampling the glossy reflections?

I agree with using soft transitions instead of cutoff..
But in your second point I'd say use 0.1 threshold for glossy rays and 0.0 for diffuse rays. Instead of brute force for all glossy rays, that would hurt performance way too much in many cases!

[Sharlybg]

Another idea : it isn't PGI but usefull.

**__** : Clamping differenciation. We should be able to clamp direct or indirect light only or both.. So we can preserve as much quality as possible. If it is to hard to code Forget

[lacilaci]

Another idea : it isn't PGI but usefull.

**__** : Clamping differenciation. We should be able to clamp direct or indirect light only or both.. So we can preserve as much quality as possible. If it is to hard to code Forget

I've put this on github a long time ago: https://github.com/LuxCoreRender/LuxCore/issues/149

But, actually... with oidn and indirect caching I believe that we should instead use a clamping value of 10 000 by default instead. It gives enough room for realistic sun values and oidn takes care of rest. I would actually keep clamping the way it works now

[Dade]

• Maybe the usage threshold scale should not introduce a sharp border between brute force and cache, but a soft transition instead?

There isn't a sharp border with matte because there is no difference between cache and brute force result. There is a difference with glossy nearly-specular material because the cache can not capture the view dependent part of glossy material and that part is significative if it is a "glossy nearly-specular".
Even if you make a soft transition, you will end with all kind of artifacts in still reflections and animations (it is a view dependent error so if you change the point of view, you change the error).

The point is that must be no error or no transition at all. I'm thinking to change the way material cache on/off works. 3 types of settings:

- AUTO: the current enabled, leave the choose to the code (the current ON options);
- FORCE_ENABLED: always enable the cache usage;
- FORCE_DISABLE: always disable the cache usage (the current OFF options);

The new "FORCE_ENABLED" will allow you to force the usage cache (something not currently possible). So, instead of lowering the global "glossiness" parameter, you can just force the usage in something significative like a floor or a large wall. You really need only few large surfaces to have the performance benefit of PhotonGI cache.

• Is it possible to use the cache for the matte base of a glossy material, but use brute force when sampling the glossy reflections?

It would be possible but a nightmare to write with the current material code interface.

[Sharlybg]

clamping value of 10 000

As clamping value depend on light power i suggest this recently : A kind of artist mod.

For me things should be like this by default (and it is close to what cycles do):

#1 Camera Tonemap = Linear 1 no auto.

#2 light lamp power = 10 and efficacy = 1

#3 Default Env light = Background color

#4 Default clamping = 100

it have some advantage it let you work with small number while keeping all the realism. It is closer to what people know in cycles.

[lacilaci]

• Maybe the usage threshold scale should not introduce a sharp border between brute force and cache, but a soft transition instead?

There isn't a sharp border with matte because there is no difference between cache and brute force result. There is a difference with glossy nearly-specular material because the cache can not capture the view dependent part of glossy material and that part is significative if it is a "glossy nearly-specular".
Even if you make a soft transition, you will end with all kind of artifacts in still reflections and animations (it is a view dependent error so if you change the point of view, you change the error).

The point is that must be no error or no transition at all. I'm thinking to change the way material cache on/off works. 3 types of settings:

- AUTO: the current enabled, leave the choose to the code (the current ON options);
- FORCE_ENABLED: always enable the cache usage;
- FORCE_DISABLE: always disable the cache usage (the current OFF options);

The new "FORCE_ENABLED" will allow you to force the usage cache (something not currently possible). So, instead of lowering the global "glossiness" parameter, you can just force the usage in something significative like a floor or a large wall. You really need only few large surfaces to have the performance benefit of PhotonGI cache.

• Is it possible to use the cache for the matte base of a glossy material, but use brute force when sampling the glossy reflections?

It would be possible but a nightmare to write with the current material code interface.

This is like when back in the days of old vray you had to decide per material on how much samples to use. But in case of luxcore it is cache settings. It is a terrible idea and makes complex scenes even more complex as you have to test and keep track of cache settings by per material options.

I can't imagine when I would want to force enable caching on a particular material. It is generally best to use as low value as you can get away with, if at some point a value breaks how a material looks, you cannot use this value. Why would I force enable this value on that material? Just doesn't make sense.

[lacilaci]

clamping value of 10 000

As clamping value depend on light power i suggest this recently : A kind of artist mod.

For me things should be like this by default (and it is close to what cycles do):

#1 Camera Tonemap = Linear 1 no auto.

#2 light lamp power = 10 and efficacy = 1

#3 Default Env light = Background color

#4 Default clamping = 100

it have some advantage it let you work with small number while keeping all the realism. It is closer to what people know in cycles.

Yes, but then imagine you're a new user and have these defaults, and then you enable sun and sky... everything will look very weird with a clamping of 100 and sky and sun with default values.
Also, I would not use cycles's defaults as a guide...

[lacilaci]

Also on the topic on soft transition between cache and brute force:
vray:

luxcore:

you can see a clean cutoff with usage threshold scale. If it could be softer we could use glossiness threshold of 0.03-0.04 by default which would cover a lot of material types!