PhotonGI cache

[marcatore]

Lower the radius and increase the photons number have any kind of impact on rendertime (excluded the preprocessing phase)?

I asking this cause, also to remove the light leaks , with a small radius we should easily avoid that problem without affecting too much the rendering speed.

[Sharlybg]

So in a real scene, things just can't be solved using more and smaller cache entries.
Note that 1milion photons at 15cm give even brighter scene as 100 milion photons at 1 cm.

I've the felling that if you reduce the amount of light by placing plane with small hole on each windows(not by reducing light power) the problem will appear. Look like hard lit scene need more photon and smaller radius as Dade suggest.

[Sharlybg]

I just reduce windows. 1.mn each render on 1080ti

PGI + 1.000.000 photon +15cm

PGI + 10.000.000 photon+1cm

Path

[epilectrolytics]

Sorry for not being precise, I used a flat white background from the world tab in Blender:
Screen Shot.png

I should have fixed the problem.

Thanks!

[Sharlybg]

BUT this is how it look with extreme settings :

Debug

It is Darker than ever

[provisory]

A circle with 1 cm radius has 225 times smaller area than a 15 cm one, so mayble it needs that much more photons.

[lacilaci]

A circle with 1 cm radius has 225 times smaller area than a 15 cm one, so mayble it needs that much more photons.

Both corona and vray seem to use pretty big entries by default and at least in case of corona there seem to be no difference... Maybe there is some trick to counterbalance the loss of light or something...

Anyways, I'm happy with cache even as is. Can't wait to get to work on some interiors with this, currently I'm flooded with productviz so I can only utilize oidn for now.

[Fox]

Both corona and vray seem to use pretty big entries by default and at least in case of corona there seem to be no difference... Maybe there is some trick to counterbalance the loss of light or something...

Back in LuxRender with SPPM render mode, there was huge brightness difference when store on glossy was enabled and there was lack of photons and eye rays compared to when high number of eye rays like 50M with 10 000 000 000 photons per pass was used.

[Dade]

I may have a bit confused my explanation talking about the number of photons traced: photons are like samples, more you have and more accurate the result is. However, after some point, there is a diminished return, it becomes quite pointless to trace more photons.

The key point of my post was about the radius. If the circle around a cache entry goes outside the surface, it will introduce an error, it doesn't matter how many photons you trace, it is a fixed error and will be always there (i.e. the bias).

I'm playing with the idea of cache entries with variable radius (to reduce the error near borders) but it has not an high priority compared to other stuff: the very foundation of PhotonGI cache is to trade bias for rendering time and it is very good at that.

If you want to explore this topic, always change a single parameter, the radius or the photon count, not both, otherwise you will confused by 2 orthogonal problems.

[Sharlybg]

No problem if it isn't a bug it is something we can deal without problem. We just want be sure to understand better so we are not going to spread bad interpretation arround the internet

Thanks you for this historical Boost Dade