LuxCoreRender Forums

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.

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:

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

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

Are there going to be some changes to direct light sampling/caching aswell for 2.2?

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.

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.

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.

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.

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.

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.)

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:
The value sets the update period in samples per pixel.

This is a 512 spp rendering with old code:


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


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).