LuxCoreRender Forums

Posted: **Wed Feb 27, 2019 12:48 pm**

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 ?

Posted: **Wed Feb 27, 2019 1:32 pm**

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?

Posted: **Wed Feb 27, 2019 1:38 pm**

B.Y.O.B. wrote: Wed Feb 27, 2019 1:32 pm 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!

Posted: **Wed Feb 27, 2019 1:42 pm**

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

Posted: **Wed Feb 27, 2019 1:58 pm**

Sharlybg wrote: Wed Feb 27, 2019 1:42 pm 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

Posted: **Wed Feb 27, 2019 2:37 pm**

B.Y.O.B. wrote: Wed Feb 27, 2019 1:32 pm

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.

B.Y.O.B. wrote: Wed Feb 27, 2019 1:32 pm

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.

Posted: **Wed Feb 27, 2019 2:46 pm**

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.

Posted: **Wed Feb 27, 2019 3:00 pm**

Dade wrote: Wed Feb 27, 2019 2:37 pm
B.Y.O.B. wrote: Wed Feb 27, 2019 1:32 pm

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.

B.Y.O.B. wrote: Wed Feb 27, 2019 1:32 pm

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.

Posted: **Wed Feb 27, 2019 3:04 pm**

Sharlybg wrote: Wed Feb 27, 2019 2:46 pm
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...

Posted: **Wed Feb 27, 2019 3:21 pm**

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!

LuxCoreRender Forums

PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache

Re: PhotonGI cache