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
PhotonGI cache
Re: PhotonGI cache
-
- Donor
- Posts: 790
- Joined: Thu Oct 04, 2018 6:06 am
Re: PhotonGI cache
Sounds good!
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. 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.
Re: PhotonGI cache
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.
I was not able to make Blender to stop the render, waited 10 minutes after hitting the cancel.
It's never an issue when i cancel render in first few minutes, but when render runs longer, it can not cancel.
Now in latest build it works with PhotonGi cache.
I was not able to make Blender to stop the render, waited 10 minutes after hitting the cancel.
It's never an issue when i cancel render in first few minutes, but when render runs longer, it can not cancel.
Re: PhotonGI cache
Halt: 128samples, raw, JPG 95%
Debug from Final to Indirect
preview gif
mp4 (h264) video "PGI&PT0001-1000" @ streamable
Re: PhotonGI cache
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.
- 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.
- FarbigeWelt
- Donor
- Posts: 1046
- Joined: Sun Jul 01, 2018 12:07 pm
- Location: Switzerland
- Contact:
How are Photons distributed with PhotonGI cache?
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 Second, the openCL version with PhotonGI cache. 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. 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.
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 Second, the openCL version with PhotonGI cache. 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. 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.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
MacBook Air with M1
-
- Donor
- Posts: 790
- Joined: Thu Oct 04, 2018 6:06 am
Re: How are Photons distributed with PhotonGI cache?
I agree that the Photon distribution is not smooth enough especially for the caustic cache.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.
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.
Re: How are Photons distributed with PhotonGI cache?
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.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.
The problem on above test is also the very wrong merge radius, just use the default values.
-
- Donor
- Posts: 790
- Joined: Thu Oct 04, 2018 6:06 am
Cache combination problem
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.
. .
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
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.
. .
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
Re: Cache combination problem
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.epilectrolytics wrote: ↑Thu May 02, 2019 11:52 am As if the indirect cache was limiting the size of caustic 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).
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.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).