LuxCoreRender Forums

marcatore wrote: Fri Aug 14, 2020 12:09 pm Is it normal?

Yes, more "directional" are the materials (i.e. glossy, specular, etc.) a more bias introduces the cache. PGI fallback more often to normal path tracing in order to reduce the bias.

Matte is the less "directional" of all materials and PGI doesn't introduce bias at all so it can use cache entries as often as it can (aside corner, again, to avoid artifacts).

marcatore wrote: Fri Aug 14, 2020 12:09 pm Isn't it possible to caching more with glossy materials?

Yes, if you raise the PGI glossiness threshold over the material roughness (or you rise the material roughness over the threshold).

NOTE: you have to keep in mind that cache can be used only starting from the second bounce, not the first one. So if you see a red/blue pixel means cache was used/not-used on the bounce after the first one.

So if a path hits the glossy floor and the pixel is red, it means the path bounced over the floor and hit another surface where it wasn't possible to use the cache (because it was too near or the surface was considered too "directional").

Dade wrote: Sat Aug 15, 2020 10:23 am

marcatore wrote: Fri Aug 14, 2020 12:09 pm Isn't it possible to caching more with glossy materials?

Yes, if you raise the PGI glossiness threshold over the material roughness (or you rise the material roughness over the threshold).

In your case, you can increase the cache usage by reducing "Indirect light cache => Brute force radius scale" from 8 to 4 or less. It will reduce the maximum distance forcing the usage brute force path tracing (using the cache more often).

Dade wrote: Sat Aug 15, 2020 10:23 am
Yes, more "directional" are the materials (i.e. glossy, specular, etc.) a more bias introduces the cache. PGI fallback more often to normal path tracing in order to reduce the bias.
Matte is the less "directional" of all materials and PGI doesn't introduce bias at all so it can use cache entries as often as it can (aside corner, again, to avoid artifacts).

So...for everything than matte there isn't any shortcut to a fast free-noisy solution like we have with matte mats?
It's a pity because it's very rare to have a scene with just matte materials, and the worst case is when you have most of the image covered by matte materials and some key elements with glossy ones. In this way you have to wait a lot of time (and samples) to clean just the glossy mats
I've done a comparison on a test scene I'm doing...and the difference is big...and consider that the image on the left (walls matte mats and furniture with glossy mats) needs at least 3-4 time the image on the right (just matte mats) and it's still noisy on the glossy parts.

Dade wrote: Sat Aug 15, 2020 10:23 am Yes, if you raise the PGI glossiness threshold over the material roughness (or you rise the material roughness over the threshold).

This is quite a not smart solution because you could have several glossy materials with different roughness values and also because if you control the roughness with textures, it's difficult to find the right final roughness value. At the end you'll spend a lot of time on test renderings to find the right balance...with complex scene where you have several glossy mats...well..it's not doable.

I hope you'll introduce some ways to improve render speed on this kind of materials.

marcatore wrote: Sat Aug 15, 2020 12:31 pm So...for everything than matte there isn't any shortcut to a fast free-noisy solution like we have with matte mats?

As wrote, reduce the "Indirect light cache => Brute force radius scale". You increase bias and reduce the rendering time.

Using Disney instead of Glossy may help too.

What happen when you set the brute force radius scale to 1 for example.

Sharlybg wrote: Sat Aug 15, 2020 3:01 pm What happen when you set the brute force radius scale to 1 for example.

With 1 nothing special, if you set to 0.0, it will disable brute force path tracing so the cache will be always used (i.e. the debug image will be all blue).

Dade wrote: Sat Aug 15, 2020 5:13 pm

Sharlybg wrote: Sat Aug 15, 2020 3:01 pm What happen when you set the brute force radius scale to 1 for example.

With 1 nothing special, if you set to 0.0, it will disable brute force path tracing so the cache will be always used (i.e. the debug image will be all blue).

Yes ! just want to see what happen in marcatore scene when BRS is set to one (I mean it should help improve performance).

Sharlybg wrote: Sat Aug 15, 2020 7:03 pm

Dade wrote: Sat Aug 15, 2020 5:13 pm

Sharlybg wrote: Sat Aug 15, 2020 3:01 pm What happen when you set the brute force radius scale to 1 for example.

With 1 nothing special, if you set to 0.0, it will disable brute force path tracing so the cache will be always used (i.e. the debug image will be all blue).

Yes ! just want to see what happen in marcatore scene when BRS is set to one (I mean it should help improve performance).

Yes but it is likely to get some artifact too, especially near corners. However there is a lot of middle ground between 0.0 and 8.0.

Dade wrote: Sat Aug 15, 2020 5:13 pm With 1 nothing special, if you set to 0.0, it will disable brute force path tracing so the cache will be always used (i.e. the debug image will be all blue).

Uhmm... it doesn't seem all blue. Where am I wrong?



EDIT: rerendered with "normal angle as default value"