Re: PhotonGI cache
Posted: Mon Jun 17, 2019 3:05 pm
Would it be possible to add this as well?
LuxCoreRender Forums
Show your work, get help, participate in development
https://forums.luxcorerender.org/
PhotonGI cache
Page 93 of 109
Re: PhotonGI cache
Posted: 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.)
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.)
Re: PhotonGI cache
Posted: Mon Jun 17, 2019 5:12 pm
Huuuh do you mean it can be the same for Indirect cache ? so it turn as an online cache ?And this with an update every 16 spp but exactly the same other caustic cache parameters:
Re: PhotonGI cache
Posted: 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.Sharlybg wrote: Mon Jun 17, 2019 5:12 pmHuuuh do you mean it can be the same for Indirect cache ? so it turn as an online cache ?And this with an update every 16 spp but exactly the same other caustic cache parameters:
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).
Re: PhotonGI cache
Posted: Mon Jun 17, 2019 6:13 pm
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.
Re: PhotonGI cache
Posted: Mon Jun 17, 2019 6:26 pm
Sounds amazing, Thank you!Dade wrote: Mon Jun 17, 2019 2:56 pm I added the support for periodic update of the PGI caustic cache to PATHCPU ...
Currently PGI caustic cache doesn't work on volumes. Would it be hard to make it so?
Re: PhotonGI cache
Posted: 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):
And here's a demangled Blender stack trace:
Hope it helps.
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:111Code: 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() 0xe03Re: PhotonGI cache
Posted: Mon Jun 17, 2019 6:57 pm
I still think it would be useful: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.
- 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
)Re: PhotonGI cache
Posted: 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
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
Re: PhotonGI cache
Posted: Mon Jun 17, 2019 8:20 pm
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).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
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.