PhotonGI cache

[Dade]

99.99% is still not cache-able or empty space, it is pointless to use PhotonGI in this scene (viewtopic.php?f=2&t=917).

Yes, I already wrote in that thread that I didn't expect much from the bulk of that scene. Only for the logo in the middle, which is matte-transulcent, shouldn't that be cache-able and have some effect when cached?

Nope, mattetranslucent is a different material from matte.

[lacilaci]

filtering looks fine. Does it help with spikes in cache or is it not affecting the issue?

[Dade]

filtering looks fine. Does it help with spikes in cache or is it not affecting the issue?

Yes, it does, try it.

[lacilaci]

filtering looks fine. Does it help with spikes in cache or is it not affecting the issue?

Yes, it does, try it.

I'm on my way azure should finish linux soon too.

[lacilaci]

Ok, with filtering things start to look very very good.

I am impressed....

here's my observation.
spikes in cache are no more recognizable as leaks/bleeding/fireflies. And even extremely difficult situation/stresstest (sun+sky+interior+small pool/100K photons, + small cache size/100K photons) won't look like bleeding, just weird lighting overall.

Since preprocess time can be very fast even with moderate numbers, I think that lower limit for cache pool and size should be set (we need to figure out where things start to fall apart and/or take too much time with ~mainstream HW) this will enable users to just not care about cache settings and won't allow to break cache.

Also usage threshold of 4 seems very fair to large spaces and still fast to render even on cpu (lookup from 25-35 cm). without requiring too much photons

@Dade, the spikes are not really gone. You know that, but to make sure they are not really visible, a standard of photon count + cache size has to be on a certain level.

Here is a very fast precalc setting of 1 000 000 photons + 500 000 cache size with 35cm lookup and 4 threshold scale:

at first sight, it is clean and super fast (5min on gtx1060 at 4K) but there is a pretty strong blue tint in the small hallway with plane in center of the image, coming from the sky. Yes, it's a big scene and lot of trees and interior and probably 2-4x more photons are needed but I just wanted to say, that spikes are gone in form of leaks, but might still show up in form of weird color cast now when settings/photon counts are low.

So, maybe we should start thinking about defaults and start hiding and limiting some settings.

If preprocess setup would take anywhere from 1 to 4 seconds on HW like my current outdated (4770K and gtx1060) it should be the low end, no less available (to avoid user errors and funky bogus tutorials about performance improvements with extreme settings)

All in all, I'm very happy with how this turned out. Only thing left now is the support for all materials so that complex scenes can be tested.

[lacilaci]

I also think that angle parameter should be hidden and materials should be cached as if no bump was applied.

[lacilaci]

Here's an example of cache failing really bad, I don't know what's going on there:

279_luxcore.zip

(328.81 KiB) Downloaded 160 times

EDIT: This was happening before cache filtering, just to let you know it's not related to that. It seems that light is going through mesh, this might be source of other leaks too...?

[lacilaci]

For better illustration I made a 50% render overlay on cache debug.

You can see here that bright cache is created from sunlight that is actually going through mesh(skylight does that too) and then it is lighting up the box from inside. This is a matte material if you switch it to glossy the bright cache will be seen on right wall in reflecion too.

[Sharlybg]

I had something like this recently but just increase lookup radius to 50cm and it is gone.

[epilectrolytics]

Light leaks, that is light penetrating tight meshes, are a serious problem in Blender and Lux.
In my main 3D app Cheetah3D this problem doesn't exist and whenever I port an interior scene with sunsky into Blender I have to put it into a Box for shielding, and the box has to be black or light will even leak through solid double geometry walls!

It should be investigated if this is a Blender or Lux thing.
We should avoid to adapt the cache for issues that are not internal (splotches) but external (light leak through geometry) and remove the latter.

I have no time to test latest improvements right now but with the filter in place PGI looks ready for initial alpha release.
It is a really great piece of work delivering results at stunning speed.

Regarding parameters: During testing it is important to have as many values accessible as possible.
Only then it can be evaluated if they are vital to certain scenes and configurations by a broader base of users.
Then those no-one needs can be hidden.
I suggest to handle this like the BCD denoise panel:
Expose only the most important parameters like cache maxsize and lookup radius and provide an "advanced adjustments" button for the rest.