PhotonGI cache

[CodeHD]

However this is a bit hard to do in a convenient way. It would require to evaluate the whole nodetree that goes into the roughness socket, just for the Blender UI, and would probably slow things down if run constantly. Or you have to run it with a button, which kinda defeats the purpose as well.

Is it not possible to evaluate it with an event handler when the socket in question is linked?

[lacilaci]

It sounds to me like Sharlybg wants a text in the node UI that says something like "this material will be cached because the roughness is higher than the threshold" (or the opposite)?

Simple way : just have roughness number still displayed evenif i have node texture pluged in just to show the average roughness value the cache will be compared to.

rf.png

I like this solution but...

that estimated average doesn't give any info to new users unless they somehow already know that there is a specific threshold.

Also wonder what would be the performance impact on pluging and unplugging textures. If there is no impact then great. If there is and especially with high res textures, then it might not be worth it.

Like I said before, we must avoid overcomplicating stuff and confusion. If there is a performance problem you can investigate with debug mode, otherwise continue working and don't waste time with useless info!

Edit: Also, imagine your texture creates very glossy material with very low roughness so it woul not work with cache. What then ,you would force caching and look at cache entries in reflections? I'm personally against overrides of cache per materials too, just makes people think that there must be something wrong with it if it needs extra control and just adds a bit more to the confusion.

[Sharlybg]

Of course if performance are impacted it is not worth it. But if it available with small impact it is far from useless.

[B.Y.O.B.]

The problem is this:

It would require to evaluate the whole nodetree that goes into the roughness socket

It would require some new interface in LuxCore that allows to read in material properties and evaluate the node tree, then return the result.
It would be a lot of work.

And I'm not sure we even need it.
When you see that a material will be cached or not cached, what will you do next? Just knowing this is pointless, usually you want to act on it, right?
So, if the material won't be cached because the roughness is too low, but you want it in the cache, then you will either tweak the roughness or you will tweak the glossiness threshold.
Either way, that is what you really wanted: make sure that the material will be cached. Is that correct?
If yes, the "force on/off/auto" switch would be the best solution in my opinion.

[lacilaci]

but why would you force cache on a highly reflective surface? I probably won't look pretty

[zuljin3d]

Guys, in new debug mode, that mean blue and red colors?

[Dade]

Guys, in new debug mode, that mean blue and red colors?

This:

It shows in red the pixels where brute force path tracing [i.e. slow] is used and in blue where cache [i.e. fast] it is

so it gives you a good idea of how well cache can work with your current scene (i.e. red is "bad/slow", blue is "good/fast").

P.S. keep in mind that, in some case, red just means cache can not be of any use: think of an plane facing empty space, there is no indirect light at all so it will be red (but it is not "bad/slow" at all).

[Sharlybg]

Got my answer from here :

viewtopic.php?f=4&t=957

Nice to see how smart the cache is now. But still fear to just fall back to normal speed if my scene look require more reflection

So i hope that with development going on we get at some point where we can lower the default reflection ( without introduce to much bias).

[Dade]

I have added automatic indirect cache best radius evaluation. So, now on, if you set the path.photongi.indirect.lookup.radius to 0.0, PhotonGI will evaluate the best radius for your scene.
The radius will have the value required to cover about the 2% of the image plane with a cache entry. This value is trivial to translate in pixels with Max(2% * <image width>, 2% * <image height>). For instance, the radius will cover about 16 pixels in a 800x800 rendering.
The result is printed in the log output:

Code: Select all

[LuxCore][0.992] PhotonGI evaluating best radius
[LuxCore][1.213] PhotonGI evaluated values: 985296
[LuxCore][1.213] PhotonGI best indirect cache radius: 0.151526

LuxCore doesn't have full support for ray differentials so I'm using a simplified process, it seems to work quite well but don't try wired stuff like looking at the scenes through an highly deforming glass/mirror object (i.e. a lens).

This is the result setting the radius to 0.0 in Cornell scene:

[lacilaci]

Sounds great, will test once azure finishes building...
But I have to wonder:

1. What will happen if I try to render through reflection ? I actually did render like that in past to get a bit of spherical distortion using corona and you bet people will be doing stuff like that
2. What are those ray differentials - is this the ability to differentiate between glossy, specular, diffuse... rays?