PhotonGI cache

Discussion related to the LuxCore functionality, implementations and API.
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: PhotonGI cache

Post by B.Y.O.B. »

Dade wrote: Mon Jun 17, 2019 2:56 pm This pretty much rendering like SPPM without radius reduction.
Would it be possible to add this as well?
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: PhotonGI cache

Post by FarbigeWelt »

@provisory and Dade

Your ideas and their realization are ingenious!
openCL with parallel cache computing on CPU will rock for sure!

(I wonder if there is more potential like that to further improve quality of openCL, maybe other caches.)
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: PhotonGI cache

Post by Sharlybg »

And this with an update every 16 spp but exactly the same other caustic cache parameters:
Huuuh do you mean it can be the same for Indirect cache ? so it turn as an online cache ?
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

Sharlybg wrote: Mon Jun 17, 2019 5:12 pm
And this with an update every 16 spp but exactly the same other caustic cache parameters:
Huuuh do you mean it can be the same for Indirect cache ? so it turn as an online cache ?
The same process would be trivial to do for indirect cache (i.e. it would require to change only one line of code) but it would be practically useless: indirect cache already works well as it is.

This is not online cache building. Each update the old cache is scratched and a new one is built, this is different from building the cache on the run (i.e online building).
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 cache

Post by Dade »

B.Y.O.B. wrote: Mon Jun 17, 2019 3:05 pm
Dade wrote: Mon Jun 17, 2019 2:56 pm This pretty much rendering like SPPM without radius reduction.
Would it be possible to add this as well?
Yes, but it would require a lot of work and be of quite little use. The current solution works transparently for all other code, reducing the radius would require some weight computation and explicit support in all code (CPU and OpenCL). And, as usual, it would be a pain to modify all OpenCL code. If the starter radius is about of the size of a pixel, there will be no difference in the final output anyway.

On other side, I could use the part of the current PGI solution for tracing light paths (with Metropolis, etc.) to finally update BIDIRVMCPU and have a fully functional render engine (i.e. the code for weights computation is already all in place in BIDIRVMCPU).

However it should something for the next version: it is time close pending stuff, release v2.2 and move on. This "update" change should be finally offer a good PGI caustic cache solution and close the PGI chapter for the current release.
Support LuxCoreRender project with salts and bounties
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI cache

Post by provisory »

Dade wrote: Mon Jun 17, 2019 2:56 pm I added the support for periodic update of the PGI caustic cache to PATHCPU ...
Sounds amazing, Thank you!

Currently PGI caustic cache doesn't work on volumes. Would it be hard to make it so?
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: PhotonGI cache

Post by B.Y.O.B. »

Very reasonable plans.

By the way, I get a crash when I cancel the render while the periodic update is running.
OS is Linux.
Here's a gdb backtrace (from a non-debug build):

Code: Select all

(gdb) bt
#0  0x00007fffdb4b45de in slg::TracePhotonsThread::RenderFunc() () from /home/simon/.config/blender/2.79/scripts/addons/BlendLuxCore/bin/pyluxcore.so
#1  0x00007fffdc0f33b9 in thread_proxy () from /home/simon/.config/blender/2.79/scripts/addons/BlendLuxCore/bin/pyluxcore.so
#2  0x00007ffff79bc184 in start_thread (arg=0x7fff957ff700) at pthread_create.c:312
#3  0x00007ffff628a03d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
And here's a demangled Blender stack trace:

Code: Select all

slg::Scene::Intersect(luxrays::IntersectionDevice*, bool, bool, slg::PathVolumeInfo*, float, luxrays::Ray*, luxrays::RayHit*, slg::BSDF*, luxrays::RGBColor*, luxrays::RGBColor const*, slg::SampleResult*, bool) const 0x501

slg::TracePhotonsThread::TracePhotonPath(luxrays::RandomGenerator&, std::vector<float, std::allocator<float> > const&, std::vector<slg::TracePhotonsThread::RadiancePhotonEntry, std::allocator<slg::TracePhotonsThread::RadiancePhotonEntry> >&, std::vector<slg::Photon, std::allocator<slg::Photon> >&) 0x695

slg::TracePhotonsThread::RenderFunc() 0xe03
Hope it helps.
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI cache

Post by provisory »

Dade wrote: Mon Jun 17, 2019 6:05 pm The same process would be trivial to do for indirect cache (i.e. it would require to change only one line of code) but it would be practically useless: indirect cache already works well as it is.
I still think it would be useful:
- The cache could be re-generated periodically on CPU parallel with the GPU rendering (no performance loss :!:)
- The bias would be reducing constantly during the rendering

Maybe this would be good enough for dynamic videos too. (No flicker :idea:)
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci »

Fantastic work as always. Can't wait to finaly try some cached caustics in some production. :)

Btw. I do hope by "closing pending stuff" you also mean fix for vis. cache bug and also make that env cache work on gpu :)
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: Mon Jun 17, 2019 6:57 pm I still think it would be useful:
- The cache could be re-generated periodically on CPU parallel with the GPU rendering (no performance loss :!:)
It has a cost: we do hybrid rendering so if we use the CPU for cache update, we have to stop the CPU rendering (i.e. the cost).

The main reason I see for indirect cache update is to avoid artifacts but still renderings are totally free of artifacts and animations too if you reuse the same cache. However cache update works well on the long run (i.e. after several updates) so doesn't seem to fit well in the animation rendering context.
Anyway, like I wrote before is really trivial to add if someone want to try it.
Support LuxCoreRender project with salts and bounties
Post Reply