PhotonGI caustic cache re-factoring

Discussion related to the LuxCore functionality, implementations and API.
Post Reply
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

PhotonGI caustic cache re-factoring

Post by Dade »

I have re-factored PhotonGI caustic cache to use Vertex Merging (aka SPPM in the specific case used only to render caustics). So there is now:

Code: Select all

path.photongi.caustic.enabled = 1

# An initial look up radius
path.photongi.caustic.lookup.radius = 0.1

# VM works with a quite small amount of photons traced for each pass
path.photongi.caustic.maxsize = 100000

# Samples/pixel between each pass
path.photongi.caustic.updatespp = 4

# Look up radius reduction for each pass (1% each pass with  0.99)
path.photongi.caustic.updatespp.rediusreduction = 0.99

# A lower bound to radius value
path.photongi.caustic.updatespp.minradius = 0.
Note: if you set the minimum radius equal to the starting radius you have pretty much normal photon mapping (i.e. no radius reduction).

Note: OpenCL support still to do.

The rendering will start blurred, this is with 10 samples/pixel:

sppm1.jpg

And will refine over each pass, this is with 200 samples/pixel:

sppm200.jpg

It provides, hand down, the best SDS path rendering I have seen so far:

psor.jpg

However Hybrid looks still a bit superior for normal caustic renderings. So my original plan to use the caustic cache only for SDS paths looks right.

This is my "SDS benchmark" scene:

pool-flat.jpg

The dark edges are still there but they are reduced over time. All the under-water part of the scene is rendered only with SPPM so the result is remarkable.

This is a rendering of the pool scene:

pool.jpg

I'm still trying to figure out the under-water "darkening": if you set the IOR to 1.0, there is no darkening at all, more you increase the IOR and darker the under-water becomes. This looks like the result of the increase of glass internal reflection but it is questionable.
Support LuxCoreRender project with salts and bounties
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: PhotonGI caustic cache re-factoring

Post by epilectrolytics »

Looks great!
Dade wrote: Thu Sep 26, 2019 2:39 pm I have re-factored PhotonGI caustic cache to use Vertex Merging (aka SPPM in the specific case used only to render caustics)
What does vertex merging mean in the context of caustic cache?
I thought it connects light paths and eye paths in BiDirVM?

This looks like old caustic cache with automatic radius reduction (which is great).
Dade wrote: Thu Sep 26, 2019 2:39 pm I'm still trying to figure out the under-water "darkening": if you set the IOR to 1.0, there is no darkening at all, more you increase the IOR and darker the under-water becomes. This looks like the result of the increase of glass internal reflection but it is questionable.
I have tested pool caustics with PathOCL and increased sun diameter which works kinda well but not super fast.
It starts looking dark but over time when the ground caustics already have converged the dark parts brighten up too (>10 000 samples).

It may be improbable paths (SDDS = indirect SDS) indeed due to internal reflection.
Maybe for a fast solution (to the darkening problem) it could be done with indirect cache of PGI?
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: PhotonGI caustic cache re-factoring

Post by B.Y.O.B. »

Dade wrote: Thu Sep 26, 2019 2:39 pm I'm still trying to figure out the under-water "darkening"
I would expect a bit of darkening, because the water surface focuses the light to some areas (the bright bands). So it is only natural that other areas receive less light (it was guided away after all).
But I'm not sure how to check if the current darkening is correct or too much due to a bug. Maybe construct an artifical testscene where you know exactly how much light to expect on certain pixels?
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI caustic cache re-factoring

Post by lacilaci »

B.Y.O.B. wrote: Thu Sep 26, 2019 3:32 pm
Dade wrote: Thu Sep 26, 2019 2:39 pm I'm still trying to figure out the under-water "darkening"
I would expect a bit of darkening, because the water surface focuses the light to some areas (the bright bands). So it is only natural that other areas receive less light (it was guided away after all).
But I'm not sure how to check if the current darkening is correct or too much due to a bug. Maybe construct an artifical testscene where you know exactly how much light to expect on certain pixels?
While you could find light conditions where some "darkening" would be apparent (especially if all underwater surface is in shadow and water surface is reflecing sky for example)...
In very bright daylight with sunlight blasting on the water and under the water you might find water being extremely bright due to all the caustics
24f9298b7e95253a4e420267887248dc.jpg
I think that having hybrid glass mode / transparent shadows could boost this - but I don't know.

Also, is this vertex merging sds only or full caustics? Will experiment with the build tomorrow if possible.
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI caustic cache re-factoring

Post by provisory »

Dade wrote: Thu Sep 26, 2019 2:39 pm I have re-factored PhotonGI caustic cache to use Vertex Merging (aka SPPM in the specific case used only to render caustics)...
Looks very promising, though we've believed this already several times. (Sorry, didn't mean it! :D )

Questions:
- Could the radius be specified in pixel space? It would be very convenient for the user.
- If this cache will be for SDS paths only, then could it be calculated from the Light Tracing, or these will be two separate passes (double the time)?
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI caustic cache re-factoring

Post by Dade »

epilectrolytics wrote: Thu Sep 26, 2019 3:12 pm What does vertex merging mean in the context of caustic cache?
I thought it connects light paths and eye paths in BiDirVM?
It connects eye paths with light path endpoints stored inside the cache (and they are the light paths only of caustics).

Plus there is a radius reduction exactly like in BiDirVM (i.e. alpha parameters here is called "path.photongi.caustic.updatespp.rediusreduction").
Dade wrote: Thu Sep 26, 2019 2:39 pm I have tested pool caustics with PathOCL and increased sun diameter which works kinda well but not super fast.

It starts looking dark but over time when the ground caustics already have converged the dark parts brighten up too (>10 000 samples).

It may be improbable paths (SDDS = indirect SDS) indeed due to internal reflection.
Yes, that is one of the possibility, SDD*S paths are rendered by normal path tracing and it works only if the light source is intersectable (and easy to intersect so a large sun may produce more SDD*S paths).
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 caustic cache re-factoring

Post by Dade »

lacilaci wrote: Thu Sep 26, 2019 3:50 pm While you could find light conditions where some "darkening" would be apparent (especially if all underwater surface is in shadow and water surface is reflecing sky for example)...
In very bright daylight with sunlight blasting on the water and under the water you might find water being extremely bright due to all the caustics
24f9298b7e95253a4e420267887248dc.jpg
I have the feeling it is indirect light, check the photo you posted, even the underwater pool wall, not reached by direct sun light, is very bright.
lacilaci wrote: Thu Sep 26, 2019 3:50 pm Also, is this vertex merging sds only or full caustics? Will experiment with the build tomorrow if possible.
For the moment, it is a just a better (CPU only for the moment) version of old PhotonGI caustic cache so it does both normal caustics and SDS paths (i.e. do not enable hybrid rendering or the normal caustics will be rendered 2 times).
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 caustic cache re-factoring

Post by Dade »

provisory wrote: Thu Sep 26, 2019 4:17 pm Questions:
- Could the radius be specified in pixel space? It would be very convenient for the user.
This is already done for PGI indirect cache when the radius is set to 0.0 (it uses a radius that cover a fixed % of the image size). I could do the same with caustic cache. However keep in mind that one pixel can cover a near object of 10cm and another can cover a far plane of 1km so I'm using an average at the moment.

In a far, far ... far future I could use variable lookup radius so it cover a fixed amount of pixels no matter of the underlying scene (but it is quite complex and sophisticate stuff).
provisory wrote: Thu Sep 26, 2019 4:17 pm - If this cache will be for SDS paths only, then could it be calculated from the Light Tracing, or these will be two separate passes (double the time)?
Yes, in theory, not in practice: light tracing Metropolis renders (mostly) normal caustics and it will avoid SDS paths because they can not be connected to the eye. So our current light tracing is actively trying to avoid the light paths I need for the cache :!:

Note: Vertex Merging requires a small amount of photons (because they are accumulated over each pass). All above renderings took between 200ms to 500ms to build the caustic cache.
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI caustic cache re-factoring

Post by lacilaci »

Dade wrote: Thu Sep 26, 2019 9:39 pm
lacilaci wrote: Thu Sep 26, 2019 3:50 pm While you could find light conditions where some "darkening" would be apparent (especially if all underwater surface is in shadow and water surface is reflecing sky for example)...
In very bright daylight with sunlight blasting on the water and under the water you might find water being extremely bright due to all the caustics
24f9298b7e95253a4e420267887248dc.jpg
I have the feeling it is indirect light, check the photo you posted, even the underwater pool wall, not reached by direct sun light, is very bright.
I don't know, it definitely isn't so bad as previously. I kinda still wish I could get more light there so I'm experimenting...

By the way, your minradius of 0.04 is still pretty big imho...
mir004.jpg
this is 0.01
mir001.jpg
but for closeup on the pool I'm gonna still need lower, like 0.005.

The problem with that is, what you see on the sphere, it gets some low frequency noise... Again, rounded surfaces have hard time gathering photons, while bottom of the pool/flat surfaces sharpens nicely, anything rounded is super hard to render.

Performance seems good, however in a case of "juice in glass" scene where you have glass with volume within another clear glass, my rendering went to 0 samples/sec and I watched individual pixels appearing (this was in a scene with only hdri and objects so I guess you're not killing photons that bounce into infinity?!)....

Another amateur observation:
When I focus on sds only, it doesn't make sense to me starting with such big initial lookup. It only helps with very noisy caustics (non sds) but I guess we will have lighttracing for those anyways, right?

For example starting with 0.01 and minradius of 0.005 I'm getting pretty nice super sharp caustics in big 42m pool within 100 samples (and no visible dark edges too) - of course reflected caustics and normal non sds is a bunch of low frequency noise

here's a quick render ~5min. 131passes
pass131.jpg
If I use high initial lookup I have very visible dark lines where the steps in the pool are(that kinda don't go fully away), but with these settings you can't see any edges and overall it is pretty bright in the pool!

I think it could be pretty awesome if we could have 50%cpu runnig VM sds, 50%cpu running lighttracing and gpu doing pathtracing :lol:

thick volumes within glass
dp.jpg
it's pinacollada so it should be pretty white (maybe it's again the issue that it is round and photons don't catch on?)

I think this would be solved with hybrid glass for the glass itself though.


hmm... further testing...
even starting at 0.005 and minradius 0.005 is pretty awesome... Great performance and I would say much better as big initial radiuses
If I clamp at 2 000 000 and render with only 0.005 radius even OIDN can denoise that!

this is only 3min rendering at full hd res + oidn (yes it's still messy but it's 3 minutes!!)
3min_oidn.jpg
I'm also getting 4X the samples/sec with this low radiuses!
...which means I can shoot 10x more photons and still get a great performance
initial 0.005 minradius 0.005 and 750 000 photons are fantastic and fast for my pool it seems
with these settings this is what 3min rendering looks like!!
750Kphotons.jpg
this is amazing, even shooting like 5 000 000 photons is almost instant and has very small impact on performance when using low radiuses
this is 0.005 both min and initial radius and 5M photons in 10 samples! (that sphere looks still terrible though)
10passes.jpg
There is also no darkening (edges or overall) bellow water, we just need a lot of photons and small radiuses

look at this, it's blurry and low res but I'm so happy this is doable now... (except the gray pinacollada though)
yes.jpg
2minutes..

OK, so in the end I'm rendering with 0.001 for radiuses and 5M photons and still get amazing performance and results :D
I think your defaults are way too slow and problematic with those edges(btw pool was also more brighter with smaller radiuses!).

maybe reflected caustics could work too if you could somehow filter out these fireflies
100samples.jpg
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI caustic cache re-factoring

Post by Dade »

lacilaci wrote: Fri Sep 27, 2019 5:10 am The problem with that is, what you see on the sphere, it gets some low frequency noise... Again, rounded surfaces have hard time gathering photons, while bottom of the pool/flat surfaces sharpens nicely, anything rounded is super hard to render.
Try to set "path.photongi.caustic.lookup.normalangle" to something big like 90 degree, the default is 10 and is very small. It should help to smooth curved surfaces.
lacilaci wrote: Fri Sep 27, 2019 5:10 am I think it could be pretty awesome if we could have 50%cpu runnig VM sds, 50%cpu running lighttracing and gpu doing pathtracing :lol:
It is one of the 2 options:

1) uses the cache like now, both on CPU and GPU. Indeed this can be fast but the periodic update at each passes is detrimental for GPUs because they have to wait for the new pass data from the CPU. This slow down the renderings at low resolution (i.e. a lot of pass updates) but should have no real impact at higher resolutions where instead the GPU speed up will help a lot.
Remember that caustic cache look up is done with eye paths so it can be done on GPUs.

2) Have a dedicate process for SDS rendering on the CPU with a static partition of CPU with light tracing. However having a static partition (like 50% + 50%) isn't very elegant and can be sub-optimal.

At the moment I'm think more to #1 solution.
Support LuxCoreRender project with salts and bounties
Post Reply