LuxCoreRender Forums

I have exposed the updatespp.radiusreduction and updatespp.minradius parameters in Blender.

B.Y.O.B. wrote: ↑Thu Oct 31, 2019 9:00 pm I have exposed the updatespp.radiusreduction and updatespp.minradius parameters in Blender.

There are a couple of old parameters: https://github.com/LuxCoreRender/LuxCor ... es.cpp#L65

- lookup max. count (removed)
- merge caustic photons (removed)
- radius scale ? What was that ? I don't think there is anymore

Thanks for pointing that out, will remove them tomorrow.
"radius scale" was the merge radius scale.

At the end how many settings will be need to set caustics cache. If only we can find a universal settings and hide all those parameter. It is really intimidating even for a not so young lux user

In my tests so far I only needed to change two values: the lookup radius and the minimum radius.
The minimum radius is the target sharpness you are aiming for, and in my tests I have set the lookup radius just a bit higher (for example, in the scene above, lookup radius = 0.5 mm, minimum radius = 0.1 mm). But I have only tested 2 scenes so far and it's mostly guesswork. So user feedback is very welcome (which settings have stupid defaults, which settings are hard to figure out, which settings never need to be changed and can be hidden, etc.).

In my opinion, and I've said this before. Initial radius and reduction is bs and serves absolutely no purpose. Large random initial photon patches will never look good in any case.

In real cases you just need to pick lowest radius/blurriness that you can get away with and render that. Those big initial ones will be replaced anyways until you have acceptable results.

The whole initial lookup and reduction thing is just to confuse people that they can trade in some bias but you are not doing that, since the large blurred patches will shrink and produce low frequency noise that you still will have to wait out until you reach desired sharpnes and density of photons.

It's extremely stupid thing that has absolutely no real life purpose and you cannot ever benefit from it in any way in any sort of production.
You need to pick desired radius, set how many photons how often to calculate and that's it.

Based on lacilaci's feedback, I think we can reduce the caustic cache UI to the one below.
Maybe we could even hide the "Periodic Update" checkbox if it turns out that you want to have it always enabled.
I would also like to hide the "Normal Angle" property if it's possible to find a default that always works (?)

But I'll wait for other opinions before pushing this change.

B.Y.O.B. wrote: ↑Thu Oct 31, 2019 9:00 pm I have exposed the updatespp.radiusreduction and updatespp.minradius parameters in Blender.

Thanks!

I agree that radius reduction does not really serve any purpose and therefore can be hidden.
Too big radius causes blur, too small increases fireflies, progression from big to small causes both
Also I see no reason to disable periodic update, that checkbox can be removed IMHO.

I'm not sure about the normal angle property which I have not yet tested with bump maps.

The photon count/cache size in millions settings could be more accurate:
When I set it to 0.5 it shows 1.0


Hybrid path with SDS-cache works really well now!

I would hide normal angle, might serve little to no purpose so to avoid errors on user side it might be better hidden. (unless Dade or someone else knows of a reason to manipulate this value)

What is samples per step? It's "the compute each # pass" value? Or is there something sampled 8x every step? Naming here doesn't make sense to me, or it means something I don't know of..?

EIDT: Also, periodic update is absolutely necessary unless you have some super weird case that I cannot even imagine...?

lacilaci wrote: ↑Fri Nov 01, 2019 12:14 pm What is samples per step?

That's the cache update period (path sample count between updates).