Would it be possible to add this as well?
PhotonGI cache
- FarbigeWelt
- Donor
- Posts: 1046
- Joined: Sun Jul 01, 2018 12:07 pm
- Location: Switzerland
- Contact:
Re: PhotonGI cache
@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.)
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
MacBook Air with M1
Re: PhotonGI cache
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
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).
Re: PhotonGI cache
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
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:111
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
Re: PhotonGI cache
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 )
Re: PhotonGI cache
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
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.