PhotonGI caustic cache re-factoring

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

Re: PhotonGI caustic cache re-factoring

Post by lacilaci »

epilectrolytics wrote: Tue Oct 01, 2019 9:32 am
Dade wrote: Tue Oct 01, 2019 9:30 amit is everything always a trad-off.
Ok I see.
This is the interesting part...
If you have a large pool(cause yes that's my example these days) you will need a LOT of photons... Especially if it's 42m long and you are looking very closely at a very small portion of it...

But you can only trace so much each spp until you hurt performance(same goes for initial radius). So while Dade keeps sugessting tracing lower amount of photons more often...
I might be in a situation where tracing 2M photons per 2spp is too slow (filling pool with photons) but 50M photons per 10spp on cpu is actually fantastic... It is indeed a trade off that you need to test and see how much you can get away with with your scene and your given hw and what are you willing to trade..

However, the problem I was complaining about (radius reduction) is plain stupid and has NO real benefit and only hurts performance and only confuses user cause now you cannot see if you have enough photons per spp... This value cannot be guessed by anyone properly and the "correct" value would also depend on starting radius and target radius so it's just bullshit.
The whole bias part of this solution should be decided by user by defining fixed radius needed for given scene/purpose (+amount of photons, per what spp). Radius reducion is guaranteed to confuse people(general users, archviz or product viz people) and just make this feature very unattractive.

It should be photon radius + X photons per X spp : 3 parameters (photon radius depending on the need and other two depending on performance)

I know I can set both to have the same result... But every parameter exposed that can make people do weird shit is going to be used wrongly and you bet something so useless as radius reduction is just going to do bad stuff..

Anyway, today's hw I can do 4M photons per 4spp with so little tradeoff that in 10min. I get 42M pool filled with 0.0015(scale) photons - fireflies remain a problem
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI caustic cache re-factoring

Post by provisory »

I prefer unbiased solutions, but in this case I think so too, that radius reduction isn't useful.
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: Tue Oct 01, 2019 8:26 am
lacilaci wrote: Mon Sep 30, 2019 2:37 pm here
sds.jpg

on the left set to sds only + lighttracing, on right lighttracing off and sdsonly = 0
What you are observing is the importance of indirect caustic lighting (SD+S paths). It is something we speculated some post before. It is something only using caustic cache can be rendered.

So I flipped the problem, instead of rendering only SDS paths with the cache, I render only SD paths (aka normal caustics) with hybrid rendering. This has also the additional benefit of not requiring any setting, if Hybrid rendering is enabled, the cache will not be used for SD paths.

So "path.photongi.caustic.useonlyforsds" has been removed and not required anymore, just enable/disable hybrid rendering at your will.

P.S. I have the felling you are using 100x more photons of what you should. Using too many photons, both requires a lot of ram and slows down the rendering.
Are you sure lighttracing is working at all now?

Cause sds is now working fine, but If I enable hybrid rendering then I don't really see any lighttracing caustics

here is cache only (the part on the table should be bright, it's photon noise you get the idea)
cache.jpg
here is +lighttracing(hybrid), again the table shadow on the table shouldn't be dark - it should be caustics and it worked with lighttracing before
hybrid.jpg
So it seems to me that now I can have cache doing sds only, but lighttracing isn't doing anything.
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI caustic cache re-factoring

Post by provisory »

lacilaci wrote: Tue Oct 01, 2019 12:37 pm ... lighttracing isn't doing anything.
Isn't it because of the path.hybridbackforward.partition setting?
(Just an idea, didn't have much time to test it yet.)
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI caustic cache re-factoring

Post by lacilaci »

provisory wrote: Tue Oct 01, 2019 1:26 pm
lacilaci wrote: Tue Oct 01, 2019 12:37 pm ... lighttracing isn't doing anything.
Isn't it because of the path.hybridbackforward.partition setting?
(Just an idea, didn't have much time to test it yet.)
rendering with openCL so partition is set to 100% cpu for lighttracing by default. Until this recent change it was working properly
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI caustic cache re-factoring

Post by lacilaci »

Another problem, if I enable photongi I see no sds - no caustic in pool
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI caustic cache re-factoring

Post by lacilaci »

But on the good note, I no longer see any fireflies from reflected caustics, since cache stays within sds and everything renders very nicely
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: Tue Oct 01, 2019 12:37 pm Are you sure lighttracing is working at all now?
Yes, it does, left caustic with light tracing and right reflected caustic with caustic cache:

sds2.jpg
lacilaci wrote: Tue Oct 01, 2019 12:37 pm here is +lighttracing(hybrid), again the table shadow on the table shouldn't be dark - it should be caustics and it worked with lighttracing before
hybrid.jpg

So it seems to me that now I can have cache doing sds only, but lighttracing isn't doing anything.
It is very hard to say by looking only at (the out of focus) image. You have to check if the table material has a low roughness (so it is considered nearly specular) and/or where the light of that caustic is coming from: it looks like a "ripple" caustic so it may be light reflected from the water :?:
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: Tue Oct 01, 2019 1:26 pm
lacilaci wrote: Tue Oct 01, 2019 12:37 pm ... lighttracing isn't doing anything.
Isn't it because of the path.hybridbackforward.partition setting?
(Just an idea, didn't have much time to test it yet.)
An error I do often is to enable hybrid rendering but have 0 CPU rendering threads (I usually set 0 CPU threads because I don't want to mix GPU and CPU rendering for debugging).

But it is unlikely to happen to someone else because the default setting is to use all CPU cores.
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: Tue Oct 01, 2019 3:37 pm
provisory wrote: Tue Oct 01, 2019 1:26 pm
lacilaci wrote: Tue Oct 01, 2019 12:37 pm ... lighttracing isn't doing anything.
Isn't it because of the path.hybridbackforward.partition setting?
(Just an idea, didn't have much time to test it yet.)
An error I do often is to enable hybrid rendering but have 0 CPU rendering threads (I usually set 0 CPU threads because I don't want to mix GPU and CPU rendering for debugging).

But it is unlikely to happen to someone else because the default setting is to use all CPU cores.
If I enable hybrid and disable cpu cores I get a warning from blendluxcore so I can't make that mistake(within blender)
Post Reply