PhotonGI cache

Discussion related to the LuxCore functionality, implementations and API.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

kintuX wrote: Sat Apr 13, 2019 9:02 am LuxCore PT, Sobol @ 0.80, PGI on, OIDN on...
It may be better to do the tests without OIDN because it is supposed to not be yet animation stable: there is the risk to mix OIDN problems with PGI problems :!:
Support LuxCoreRender project with salts and bounties
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: PhotonGI cache

Post by epilectrolytics »

Luxart wrote: Sat Apr 13, 2019 7:50 am 2, Manually setting both the Lookup radius and Brute force radius scale parameters reduces 95% of flickering (manageable level)
Sounds good!
kintuX wrote: Sat Apr 13, 2019 9:02 am Another, simple interior animation:
There's some visible flicker, especially on the furniture, looks like doable with better cache.
But then for this kind of camera animation we will get persistent cache with no flicker at all.

Today I started experimenting with a rolling ball in a closed room illuminated indirectly by a mesh light.
The first result (aborted after one hour of rendering) shows visible flickering, especially on the ground which is glossy with roughness at 0.1, a difficult condition but I think shiny floors are common and therefore should be tested.
ball1.mp4.zip
(1.56 MiB) Downloaded 156 times
Lowering the lookup radius didn't get me better results, default automatic seems to be very smooth already.
Then suddenly I got crazy horizontal noise with sobol, I can't figure out what change caused that, random seems ok.
And the flickering got less too, very close to tolerable.
ball2.mov.zip
(1.55 MiB) Downloaded 162 times
room+ball2.blend.zip
(141.95 KiB) Downloaded 151 times
Fox
Posts: 437
Joined: Sat Mar 31, 2018 11:17 am

Re: PhotonGI cache

Post by Fox »

A while ago i had issue with hetero volume rendered dark, even after first scattering volume support was released.
:) Now in latest build it works with PhotonGi cache.
PhotonGi Hetero Volume 4h 55sp.jpg
I was not able to make Blender to stop the render, waited 10 minutes after hitting the cancel. :roll:
It's never an issue when i cancel render in first few minutes, but when render runs longer, it can not cancel.
Hetero Volume Render is not able to stop.png
kintuX
Posts: 809
Joined: Wed Jan 10, 2018 2:37 am

Re: PhotonGI cache

Post by kintuX »

Dade wrote: Sat Apr 13, 2019 12:44 pm
kintuX wrote: Sat Apr 13, 2019 9:02 am LuxCore PT, Sobol @ 0.80, PGI on, OIDN on...
It may be better to do the tests without OIDN because it is supposed to not be yet animation stable: there is the risk to mix OIDN problems with PGI problems :!:
Halt: 128samples, raw, JPG 95%

Debug from Final to Indirect

preview gif
Image

mp4 (h264) video "PGI&PT0001-1000" @ streamable
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: PhotonGI cache

Post by B.Y.O.B. »

I noticed that some properties which are not baked into the photons of a cache file are nevertheless saved/loaded along with the cache file:
- path.photongi.debug.type
- path.photongi.indirect.usagethresholdscale

It would be good if we could replace these when loading a cache from file.
Currently, if you create and save a cache file while using one of the debug modes, the cache will always use the debug mode.
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

How are Photons distributed with PhotonGI cache?

Post by FarbigeWelt »

How are Photons distributed with PhotonGI cache?

I made some obervations which make be think there is potential for optimization of the PhotonGI cache.
First, the reference picture CPU BiDir, 250 Samples
Caustic Pacman CPU BiDir
Caustic Pacman CPU BiDir
Second, the openCL version with PhotonGI cache.
Caustic Pacman GPU Path, openCL
Caustic Pacman GPU Path, openCL
Obviously, there are differences. I could reduce Look up radius for Caustics, This would lead to smaller or invisible spots.
I tried changing different parameters ending with more or less the same result. Largest influence here is Look up radius for Caustics. The other add time for the initial phase, in best cases to a bit denser distributed spots.

These observations lead be to the question at the start of this post: How are Photons distributed with PhotonGI cache?
Probably the PhotonGI cache and its radius behave like showed on the left side in the picture below.
How are Photons distributed?
How are Photons distributed?
I'd like to suggest PhotonGI cache should follow the pattern of the right side of the picture above. The reason for the growing radius is it warrants overlapping of the caching space.
A solution could be to introduce one or two factors. Default would be values for an constant radius. And advanced would change the radius with distance to emission source. Advanced would enable to change one or two factors meaning (a) r_n+1=factor_1*r_n or (b) r_n+1=factor_1*(r_n)^2+factor_2*r_n.

EDIT: But maybe the cache rather looks like the following picture.
How are Photons distributed?
How are Photons distributed?
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: How are Photons distributed with PhotonGI cache?

Post by epilectrolytics »

FarbigeWelt wrote: Sun Apr 28, 2019 1:00 pm How are Photons distributed with PhotonGI cache?

I made some obervations which make be think there is potential for optimization of the PhotonGI cache.
I agree that the Photon distribution is not smooth enough especially for the caustic cache.
One problem here is that the photon pass is not progressive like with SPPM, so it won't converge (probably it would get way too big memory wise).
Perhaps it is related to the distribution of visibility particles (first PGI pass)?

In your example you have dispersion turned on which is worsening the problem significantly, even with BIDIR wavelength sampling will converge only after very high sample count, likely that won't work with the limited photon numbers of PGI.
Dade made a PGI dispersion render of the Psor Cube somewhere but that were rather blurry caustics IIRC.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: How are Photons distributed with PhotonGI cache?

Post by Dade »

epilectrolytics wrote: Mon Apr 29, 2019 5:45 am In your example you have dispersion turned on which is worsening the problem significantly, even with BIDIR wavelength sampling will converge only after very high sample count, likely that won't work with the limited photon numbers of PGI.
Yes, it is nearly impossible to render dispersion because it requires to trace too much photons. You have to sample an additional dimension: the visible wave length spectrum.

The problem on above test is also the very wrong merge radius, just use the default values.
Support LuxCoreRender project with salts and bounties
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Cache combination problem

Post by epilectrolytics »

When trying to combine indirect and caustic cache I'm getting strange results:
The caustic cache gets much smaller once indirect cache is added, to the point it is unusable (splotches).
As if the indirect cache was limiting the size of caustic cache.
.
cache.gif
concreteC.blend.zip
(259.89 KiB) Downloaded 142 times
.
EDIT: I'm using 2.2beta1
fabi has reported a similar issue.
.
EDIT2: It seems to me there are no reflective caustics from the black cube (object "cube 001", glossy material IOR 1.5, diffuse=black).
In order to test this I disable the glass cube (object "cube") from rendering and render with caustic cache only:
Blender crashes after photon cast :?:
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Cache combination problem

Post by Dade »

epilectrolytics wrote: Thu May 02, 2019 11:52 am As if the indirect cache was limiting the size of caustic cache.
The problem was caused by indirect cache automatic size test: it was ending the process of tracing photons when the indirect cache was considered done (ignoring the status of the caustic cache). As work around you can explicitly set the size of indirect cache.

I should have fixed the problem in the latest sources.

There was an additional problem when using both caches instead of only caustic one: PGI Metropolis sampler was focusing in tracing both indirect and caustic paths even when the indirect cache was done; this was generating a LOT less (about 100 times) caustic photons.
I have modified the code so PGI Metropolis sampler will focus on the type of photons required to fill the last not full cache (i.e. caustics when indirect is done and vice versa).

Note: your caustic merge radius (~0.019) is wrong, just use the default value (0.25).
epilectrolytics wrote: Thu May 02, 2019 11:52 am EDIT2: It seems to me there are no reflective caustics from the black cube (object "cube 001", glossy material IOR 1.5, diffuse=black).
Only specular materials (i.e. glass or mirror) can fill the caustic cache, not glossy. Yes, I could add also glossy nearly-specular materials to the set of materials supported by the cache.
Support LuxCoreRender project with salts and bounties
Post Reply