PhotonGI cache

[Dade]

Also on the topic on soft transition between cache and brute force:
vray:
Screenshot from 2019-02-27 16-15-20.png
luxcore:
Screenshot from 2019-02-27 16-17-40.png

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!

For what I can see, VRay falls back to brute force for rendering all the mirror (like Lux with default parameters). The screenshot doesn't show any transition: it could be because the transition works very well ... but also because there is no transition at all !

[Dade]

I have introduce in PhotonGI a way to estimate the surface covered by a cache entry in order to avoid the problems on an object edges or corners where the effective surface area is a lot smaller than cache entry circle surface. This is a debug rendering with the old code:

and this with the new one:

The rendering is brighter due the smaller effective area estimated. It is a very long shot and estimating the covered surface is indeed a very complex topic but the current new solution has no cost and seems to work well.

[Sharlybg]

It's nice how clear the new code is.

[lacilaci]

yes it seems there is some voodoo going on in vray's case.

But that doesn't change the fact that a smooth transition would allow for low values that don't need to be changed

[marcatore]

I have vray next. If you have any question trying some settings about Lightcache and see the results , I'm available to do some tests.
The reference of the Lightcache options is here
https://docs.chaosgroup.com/display/VRA ... e+Settings

Let me know.

Meanwhile, I'm trying to replicate that Vray image posted some posts ago but with no luck.
Is it recent that image?

Cause with Next version they did some refactoring...probably something changed.

[Sharlybg]

yes it seems there is some voodoo going on in vray's case.

But that doesn't change the fact that a smooth transition would allow for low values that don't need to be changed

But look like impossible as Dade said it is a view dependent error.

[lacilaci]

yes it seems there is some voodoo going on in vray's case.

But that doesn't change the fact that a smooth transition would allow for low values that don't need to be changed

But look like impossible as Dade said it is a view dependent error.

my guess is that both vray and corona have a lot of workarounds going on with their caches. That is probably also the reason that they are the only engines(redshift too) that do caching... There is no universal solution to this problem.

[Sharlybg]

Dade said sometime ago that corona cache work a bit like a denoising algorithm according to what they post as paper (not a denoiser in the common sense). Maybe some idea from that. Sure we will find a workarround.

but anyway it already So great So it is now community artists turn to make some noise about it. Some great job to impress as much as possible.

The ball now in our side I wish to all of you infinite creativity

[lacilaci]

Yes, it is definitely usable for stills and I love it
But I think the aim for a final 2.2 release should be a fully automated solution (probably a preview, still frame, animation preset with some values automatically set by engine)

[Mango3]

yes it seems there is some voodoo going on in vray's case.

my guess is that both vray and corona have a lot of workarounds going on with their caches. That is probably also the reason that they are the only engines(redshift too) that do caching... There is no universal solution to this problem.

Nope, Corona just does not use full caching of secondary GI.
Corona's UHD cache uses partly caching for secondary GI, the first GI bounce is still brute force and subsequent bounces cached.
From the corona Forum:
"The UHD cache uses only partial caching, so does not try to interpolate everything. While this is slower than a fully cached solution, it does not create artifacts, only noise that eventually goes away."