PhotonGI cache

Discussion related to the LuxCore functionality, implementations and API.
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: Cache combination problem

Post by epilectrolytics »

Dade wrote: Wed May 08, 2019 2:43 pm I should have fixed the problem in the latest sources.
Thanks for looking into this!
Now the cache size is not restricted any more but there are still firefly photons appearing when the indirect cache is added and they persist however I change the settings.
causticcache.png
Note: your caustic merge radius (~0.019) is wrong, just use the default value (0.25).
The quality of refractive caustics at merge radius 0.25 is just awful, see comparison with BiDir and radius 0.02 below:
PGI.jpg
Yes, I could add also glossy nearly-specular materials to the set of materials supported by the cache.
That would be very welcome, for glossy, metal and the upcoming principled materials.
In the image above you see how PGI renders the reflective caustics of the left cube (metal material with fresnel color 0.25 and roughness 0.01) with brute force and produces caustic noise slowly to converge.

In most interior renders there is a shiny floor material made with a glossy material node.
This is slow to render because of brute force caustic noise and also introduces bias because the indirect cache misses the view dependent part of glossy reflections.
Probably with a small (big merge radius) caustic cache for those glossy reflections the caustic noise would be prevented and also the light distribution bias reduced :idea:
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: Cache combination problem

Post by provisory »

epilectrolytics wrote: Thu May 09, 2019 12:07 pm
Yes, I could add also glossy nearly-specular materials to the set of materials supported by the cache.
That would be very welcome, for glossy, metal and the upcoming principled materials.
+1 :!:
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci »

Are there going to be some changes to direct light sampling/caching aswell for 2.2?
User avatar
Egert_Kanep
Posts: 237
Joined: Tue Mar 13, 2018 10:34 am

Re: PhotonGI cache

Post by Egert_Kanep »

Would it makse sense to have photongi defined with bounding boxes in Blender. Like eevee has those separate objects for areas where you want to have gi. It would help in a scenario if you have one object, that would need caustics, then you could just put a gi object around that particular area and use different photon count for that area and only for caustics. The rest of the scene could use another gi object with different settings.
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI cache

Post by provisory »

Can I exclude a light (or Emission node) from PhotonGI caustics?
The Material Output's Use PhotonGI Cache checkbox doesn't seem to work for this.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

provisory wrote: Sat May 25, 2019 3:03 pm The Material Output's Use PhotonGI Cache checkbox doesn't seem to work for this.
The flag is used to decide if you can have cache entries over the surface using that material or just use brute force path tracing (i.e. it is the receiving end of light, not the emitting one).
If you have some PhotonGI artifact, you can use this flag to force normal path tracing and avoid the problem.
Support LuxCoreRender project with salts and bounties
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI cache

Post by provisory »

Thank you!

I have a mirror surface that I would like to reflect a smaller, definite direction light. But there are other, larger lights, that illuminate the whole scene. For the small light small lookup radius would be good, but with that the larger lights make terrible caustics. The simplest solution would be to turn off caustics for those larger lights.
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI cache

Post by provisory »

I think I have found a workaround.
First I turn off those lights that I don't want to include in the caustic cache and compute and write PhotonGI caustic cache to file. Than I turn the lights back on, and use the previously saved cache file.
I didn't have much time to test it yet, but it seems to work.
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI cache

Post by provisory »

I have two ideas how to make PGI cache (more) unbiased. Maybe these are stupid ideas, but I'll write them down anyway; they fit here and don't hurt anyone. :)

1. Cyclically re-generating the cache
If I'm not mistaken, one of the reasons why the PGI cache is biased is that it works with the pre-generated cache entries for the entire rendering time. If we re-generated them at regular intervals during the rendering (of course with different random seed), I think we would take a big step in the unbiased direction.
In this case the cache generations could be less accurate, (thus faster) because the multiple re-generation would give the final accuracy.
(During GPU rendering we could generate the next cache in parallel on the CPU.)

2. Directional cache entries
As far as I know, the other problem is that the cache entries have no direction, so only work well for diffuse surfaces.
All cache entries could have more (say 3-4) values ​​that belong to different incoming light directions. This won't be too accurate on its own, but with the cyclical re-generation it could work well for specular surfaces too.
(The direction vectors would be randomly re-generated too for every cache generation.)
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

I added the support for periodic update of the PGI caustic cache to PATHCPU (OpenCL support will follow as usual). This pretty much rendering like SPPM without radius reduction. It is also very near to do a subset of BiDir paths.
The new property to enable the updated is:

Code: Select all

path.photongi.caustic.updatespp = 32
The value sets the update period in samples per pixel.

This is a 512 spp rendering with old code:

no-update.jpg

And this with an update every 16 spp but exactly the same other caustic cache parameters:

update.jpg

Pretty much the definition of an image is worth a thousand worth. As you can see, you can use some pretty simple caustic cache set up (i.e. very few photons) and the periodic update process will do the rest. The process is still biased (because of the radius look up) but this option remove the bias in term of photons count (i.e. there is no upper bound any more).
Support LuxCoreRender project with salts and bounties
Post Reply