PhotonGI cache

Discussion related to the LuxCore functionality, implementations and API.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci »

Dade, have you thought about interpolation? Would it be too much of a bias?
In cases where there isn't enough photons covering the scene and black spots appear ,they are very visible in reflections. I think some small amount of interpolation could help greatly. Even better if the amount of interpolation could be decided automatically based on coverage.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

Dade wrote: Sat Feb 09, 2019 9:52 pm From V-Ray documentation (https://docs.chaosgroup.com/display/VRA ... e+Settings):
Retrace – Enables retracing of GI near corners. This helps prevent light leaks and flickering. Normally, this should be enabled. The value specifies the extent to which GI near corners are retraced instead of being read from the light cache. A value of 0.0 disables retracing. A value of 2.0 is good for still images, and 8.0 is good for animations. Higher values will result in more rays traced at render time. For more information, see the Retrace example below.
So I'm using exactly the same solution but I'm using a fixed scale factor of 2.0 x <cache lookup radius> while the expose the "2.0" as a user defined parameter so it can be adjusted. I will do the same.
I have introduced the new "path.photongi.indirect.usagethresholdscale" property. It is a scale factor for the threshold of when using indirect cache or just brute force path tracing. It replaces the old fixed "2.0" scale factor of cache lookup radius.

It is pretty much the same of V-Ray retrace. 0.0 always uses the cache, infinity never uses the cache. The default value should be ok for any scene.
Dade wrote: Sat Feb 09, 2019 9:52 pm About Glossy material:
The second scene in this example shows how the Retrace option can be used to improve the appearance of glossy reflections and refractions with the Use for glossy rays option. In this case, V-Ray dynamically decides whether to use the light cache or not, based on the glossiness of the surface and the distance from it.
So they use both the distance and the roughness. I can do the same.
I have internally introduce the concept of material "glossiness". It is the Min(<avg. U roughness>, <avg. V roughness>) for glossy materials (glossy2, car paint, glossytranslucent, etc.).

I have also introduce a new "path.photongi.indirect.glossinessusagethreshold" parameter. It can be used to set the "glossiness" threshold under which brute force is used instead of the cache.

The default value is 0.2 and it should work with any scene.

I have also discovered a new problem related to the fireflies created by brute force Vs. the clean rendering of when the cache is enabled:

ff.jpg

See the border of fireflies around the glossy, nearly specular, left wall ?

At the moment, caustic cache is used only for pure specular surfaces. I'm thinking to use the caustic cache also for glossy "nearly-specular" surfaces. Something I can do thanks to the new concept of "glossiness". This should solve the problem and also add a lot of quality to the rendering (it is the kind of fireflies path tracers just cut with variance clamping, etc.)

P.S. the above image also show how "path.photongi.indirect.glossinessusagethreshold" works well: there are no splotches inside the reflected room.
Support LuxCoreRender project with salts and bounties
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

lacilaci wrote: Sun Feb 10, 2019 11:49 am Dade, have you thought about interpolation? Would it be too much of a bias?
In cases where there isn't enough photons covering the scene and black spots appear ,they are very visible in reflections. I think some small amount of interpolation could help greatly. Even better if the amount of interpolation could be decided automatically based on coverage.
I don't think we need interpolation with the latest round of fixes because black spots should not be visible anymore (are they ?).

Anyway, interpolation is a can of worms, I would like to not open: there is noway to know what is pinch black and what is not so there is the risk of a lot of light leaks.

I'm also going to change the way cache entry points are picked: at the moment 1 out of 10 photon hit is chosen as cache entry point. It is a very rude method. I will use visibility map entry points to pick well and regularly spaced cache entry points.
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci »

Dade wrote: Sun Feb 10, 2019 12:50 pm
lacilaci wrote: Sun Feb 10, 2019 11:49 am Dade, have you thought about interpolation? Would it be too much of a bias?
In cases where there isn't enough photons covering the scene and black spots appear ,they are very visible in reflections. I think some small amount of interpolation could help greatly. Even better if the amount of interpolation could be decided automatically based on coverage.
I don't think we need interpolation with the latest round of fixes because black spots should not be visible anymore (are they ?).

Anyway, interpolation is a can of worms, I would like to not open: there is noway to know what is pinch black and what is not so there is the risk of a lot of light leaks.

I'm also going to change the way cache entry points are picked: at the moment 1 out of 10 photon hit is chosen as cache entry point. It is a very rude method. I will use visibility map entry points to pick well and regularly spaced cache entry points.
Good news all around. Regular spacing between picked samples and enough photons with good defaults could cover areas nicely so maybe you're right and no interpolation is needed.

Can't wait to try these new upgrades. Have to do a photoshoot all day today though :(
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

lacilaci wrote: Sun Feb 10, 2019 1:06 pm Good news all around. Regular spacing between picked samples and enough photons with good defaults could cover areas nicely so maybe you're right and no interpolation is needed.
There is also another feature I want to try: by accumulating photons over visibility points I can establish a convergence condition making the cache size definition automatic (i.e. I can stop the process of tracing photons when I have accumulate "enough" photons).
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci »

Dade wrote: Sun Feb 10, 2019 3:00 pm
lacilaci wrote: Sun Feb 10, 2019 1:06 pm Good news all around. Regular spacing between picked samples and enough photons with good defaults could cover areas nicely so maybe you're right and no interpolation is needed.
There is also another feature I want to try: by accumulating photons over visibility points I can establish a convergence condition making the cache size definition automatic (i.e. I can stop the process of tracing photons when I have accumulate "enough" photons).
If this would work ,we could make presets like (low, medium, high) or (still image, animation) instead exposing all parameters for users... right?
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

lacilaci wrote: Sun Feb 10, 2019 3:07 pm
Dade wrote: Sun Feb 10, 2019 3:00 pm
lacilaci wrote: Sun Feb 10, 2019 1:06 pm Good news all around. Regular spacing between picked samples and enough photons with good defaults could cover areas nicely so maybe you're right and no interpolation is needed.
There is also another feature I want to try: by accumulating photons over visibility points I can establish a convergence condition making the cache size definition automatic (i.e. I can stop the process of tracing photons when I have accumulate "enough" photons).
If this would work ,we could make presets like (low, medium, high) or (still image, animation) instead exposing all parameters for users... right?
Yup (aside from the cache look up radius that is something very scene specific but could be inferred by the avg. scene area covered by a pixel).
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 »

Dade wrote: Sun Feb 10, 2019 3:00 pm There is also another feature I want to try: by accumulating photons over visibility points I can establish a convergence condition making the cache size definition automatic.
Sounds great!
Does that mean you can automate both photon count and cache size (progressively shooting photons until cache is completed)?
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: PhotonGI cache

Post by Sharlybg »

If this would work ,we could make presets like (low, medium, high) or (still image, animation) instead exposing all parameters for users... right?
Oh this sound so nice. Meaning that artist will concentrate more on they art than on unpredictable settings. Thanks you so Much. this kind of things have a serious impact on how we process art.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci »

Dade wrote: Sun Feb 10, 2019 12:43 pm
At the moment, caustic cache is used only for pure specular surfaces. I'm thinking to use the caustic cache also for glossy "nearly-specular" surfaces. Something I can do thanks to the new concept of "glossiness". This should solve the problem and also add a lot of quality to the rendering (it is the kind of fireflies path tracers just cut with variance clamping, etc.)
In other words, caustic cache will also handle reflective caustics... right?
Post Reply