PhotonGI cache

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

Re: PhotonGI cache

Post by B.Y.O.B. » 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?
Support LuxCoreRender project with salts and bounties

User avatar
FarbigeWelt
Donor
Donor
Posts: 714
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: PhotonGI cache

Post by FarbigeWelt » Mon Jun 17, 2019 3:14 pm

@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.)
160.8 | 42.8 (10.7) Gfp / Windows 10 Pro, intel i7 4770K@3.5, 32 GB | AMD R9 290x+R9 390x, 4 GB
17.3 | 19.0 ( 4.7) Gfp / macOS X 13.6, iMac 27'', 2010, intel i7 870@2.93, 24 GB | ATI Radeon HD 5750, 1 GB
#luxcorerender | Gfp = SFFT Gflops

User avatar
Sharlybg
Donor
Donor
Posts: 1367
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: PhotonGI cache

Post by Sharlybg » 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 ?
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA

User avatar
Dade
Developer
Developer
Posts: 2612
Joined: Mon Dec 04, 2017 8:36 pm

Re: PhotonGI cache

Post by Dade » Mon Jun 17, 2019 6:05 pm

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: 2612
Joined: Mon Dec 04, 2017 8:36 pm

Re: PhotonGI cache

Post by Dade » Mon Jun 17, 2019 6:13 pm

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: 134
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI cache

Post by provisory » Mon Jun 17, 2019 6:26 pm

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: 2756
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: PhotonGI cache

Post by B.Y.O.B. » Mon Jun 17, 2019 6:36 pm

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.
Support LuxCoreRender project with salts and bounties

provisory
Posts: 134
Joined: Wed Aug 01, 2018 4:26 pm

Re: PhotonGI cache

Post by provisory » Mon Jun 17, 2019 6:57 pm

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: 1153
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci » Mon Jun 17, 2019 7:35 pm

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: 2612
Joined: Mon Dec 04, 2017 8:36 pm

Re: PhotonGI cache

Post by Dade » Mon Jun 17, 2019 8:20 pm

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