PhotonGI cache

[epilectrolytics]

Just discovered that strong bump maps can throw off the cache totally.

sub.blend.zip

(360.12 KiB) Downloaded 167 times

[B.Y.O.B.]

I have exposed glossiness usage threshold and usage threshold scale in BlendLuxCore.
I also switched photon count, indirect cache size and caustic cache size to FloatProperties and multiply them with 1000 internally. This means you will have to set these manually again in your testscenes, they will be reset to the default values.

[lacilaci]

I just hope this won't end up like dlcs, great feature but unreliable because of unfixable splotches.

Regarding bumps, I feel like strong bump mapping throws off shading in general, especially making terminator effect much more prominent. On other hand, with moderate values it is the best looking bump mapping among all renderers I tried.

[Dade]

I just hope this won't end up like dlcs, great feature but unreliable because of unfixable splotches.

Have you tried to increase the usage threshold scale ?

[Dade]

Just discovered that strong bump maps can throw off the cache totally.

There is a check for max. 10 degree threshold for cache entries normal so or you increase the threshold, or trace an insane number of cache entries, or mark the surface as not-cached otherwise the result is expected.

[B.Y.O.B.]

The normal threshold is not exposed in BlendLuxCore. Should I add it, is it needed? Or is this just a very rare pathological case?

[lacilaci]

I just hope this won't end up like dlcs, great feature but unreliable because of unfixable splotches.

Have you tried to increase the usage threshold scale ?

I'm away on photoshoot(probably until monday) so it would be good if someone else could experiment with that during weekend.
So far I've only tested the build with increased default you mentioned(from 2 to 4). But that didn't help at all.

[epilectrolytics]

I just hope this won't end up like dlcs, great feature but unreliable because of unfixable splotches.

I'm confident Dade will fix this too. .
Maybe photon variance clamping to eliminate firefly photons?

But it's possible the fallbacks will diminish the speed gain.
Also glossy with roughness <0.2, this will render a bit faster than pathtracing speed and make fast diffuse converging useless, like with direct light sampling which clears sunlit parts immediately but you still have to wait till the shadows converge.
I think OIDN compatible (smooth) adaptive sampling could help with this (except it has to be invented first ).

Regarding bumps, I feel like strong bump mapping throws off shading in general

Agreed, but still the light balance is not affected in OCL whereas PGI is totally kicked off track once bump noise ruins the cache, that needs to be fixed.

[epilectrolytics]

The normal threshold is not exposed in BlendLuxCore. Should I add it, is it needed? Or is this just a very rare pathological case?

B.Y.O.B., I think during the alpha testing all accessible parameters should be exposed.
Then the users will find out what is necessary for tweaking and what can be hidden with some default value.

I was not aware of this normal threshold and was really confused that most of my Cycles stuff won't work with caching.
Maybe 25° instead of 10° would be better.

[Dade]

Mmmmm, this thing is going to be quite fast on GPUs, check the samples/sec:

For the record, my i7 3930K runs at about 3.5M samples/sec so the AMD R9 290x + NVIDIA GTX980 are about 15 times faster.