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.
PhotonGI cache
Re: PhotonGI cache
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.Dade wrote: ↑Sat Feb 09, 2019 9:52 pm From V-Ray documentation (https://docs.chaosgroup.com/display/VRA ... e+Settings):
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.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.
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.
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.).Dade wrote: ↑Sat Feb 09, 2019 9:52 pm About Glossy material:
So they use both the distance and the roughness. I can do the same.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.
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:
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.
Re: PhotonGI cache
I don't think we need interpolation with the latest round of fixes because black spots should not be visible anymore (are they ?).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.
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.
Re: PhotonGI cache
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.Dade wrote: ↑Sun Feb 10, 2019 12:50 pmI don't think we need interpolation with the latest round of fixes because black spots should not be visible anymore (are they ?).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.
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.
Can't wait to try these new upgrades. Have to do a photoshoot all day today though
Re: PhotonGI cache
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).
Re: PhotonGI cache
If this would work ,we could make presets like (low, medium, high) or (still image, animation) instead exposing all parameters for users... right?Dade wrote: ↑Sun Feb 10, 2019 3:00 pmThere 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).
Re: PhotonGI cache
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).lacilaci wrote: ↑Sun Feb 10, 2019 3:07 pmIf this would work ,we could make presets like (low, medium, high) or (still image, animation) instead exposing all parameters for users... right?Dade wrote: ↑Sun Feb 10, 2019 3:00 pmThere 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).
-
- Donor
- Posts: 790
- Joined: Thu Oct 04, 2018 6:06 am
Re: PhotonGI cache
Sounds great!
Does that mean you can automate both photon count and cache size (progressively shooting photons until cache is completed)?
Re: PhotonGI cache
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.If this would work ,we could make presets like (low, medium, high) or (still image, animation) instead exposing all parameters for users... right?
Re: PhotonGI cache
In other words, caustic cache will also handle reflective caustics... right?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.)