PhotonGI cache

Discussion related to the LuxCore functionality, implementations and API.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

lacilaci wrote: Sat Jan 19, 2019 3:02 pm I wonder why that doorframe even has those artifacts when other detailed geometry seems to look clean.
It is also in normal path tracing rendering, I'm not sure if there is something in the geometry or the material :?:
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 »

epilectrolytics wrote: Sat Jan 19, 2019 3:07 pm And yet still without metropolis photon gathering, right?
Yup.
epilectrolytics wrote: Sat Jan 19, 2019 3:07 pm Would this work with an HDRI as well?
Yes, infinite lights like sky, HDR, etc. are the one hard to sample in general (and where a smart sampler like Metropolis can shine).
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci »

This on gpu is going to be a beast(especially with multi-gpu setup)... If memory footprint of photon mapping can be low enough though.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: PhotonGI cache

Post by Sharlybg »

Wow what a progress. Just unbelievable. At this point i really want to have an estimation of the current speed :

We know it is 4x time faster in term of samples/sec but we don't know how fast it is in term of noise reduction performance. So please Dade can you launch twos render one with cache one without and return reached noise reduction on each render in the same amount of time with pre-processing time include in calculation.
Also on wich CPU are you rendering so we can make extrapolation on other hardware. :mrgreen:
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: Sat Jan 19, 2019 8:29 pm We know it is 4x time faster in term of samples/sec but we don't know how fast it is in term of noise reduction performance.
4x faster than previous cache implementation, it is 0.68M samples/sec Vs 0.50M samples/sec faster than normal rendering (36% faster). For a noise comparison, check my previous post with a 15 samples/pixel comparison.
Sharlybg wrote: Sat Jan 19, 2019 8:29 pm Also on wich CPU are you rendering so we can make extrapolation on other hardware. :mrgreen:
I have still an i7 3930K (six cores CPU). The rendering with 150 samples/pixel in my previous post is something like a 3 minutes rendering:

Image
Support LuxCoreRender project with salts and bounties
atair
Posts: 2
Joined: Sat Jan 19, 2019 1:29 pm

Re: PhotonGI cache

Post by atair »

very nice to see some progress on this front!

A few questions / comments regarding tracing from lights vs tracing from the camera:
(I read in the 4th post that view dependent caches are to come)

- isn't tracing photons very scene dependent - e.g. 'bright light outside a building, camera in room, small opening' would always be a worst case scenario for the photon based approach? In an arch-viz scenario there are often huge scenes where the camera is buried inside some small room with lots of indirect light.

- as far as i can tell this is the reason most photon based solvers got abandoned over the years. Vray still has it, but with a very strict use case - caustics. Where directional light sources have a photon emission radius to not waste them elsewhere.

- tracing from the camera is indeed not temporally stable, but there are workarounds: V-ray has fly-through modes where samples get cast and accumulated based on a camera path (stochastic, not by key-frames)

- for a dynamic scene both photon mapping and camera tracing are equally flawed, so for static fly-throughs camera based tracing is still better i would guess?

This is not meant as criticism - i am very happy that finally blender may get a renderer that is suitable for arch-viz!

ps: as i miss the light-cache so much in blender i actually managed to get a light-cache running with a 'trick' in cycles:
https://blenderartists.org/t/cycles-dev ... 21?u=atair
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: PhotonGI cache

Post by Sharlybg »

4x faster than previous cache implementation, it is 0.68M samples/sec Vs 0.50M samples/sec faster than normal rendering (36% faster). For a noise comparison, check my previous post with a 15 samples/pixel comparison.
There is no stat number under each render frame to compare on both cached and brute force how much noise have been removed in the same amount of time (also with pre processing time include).
I mean a number like noise threshold estimation as stat under frame like samples/sec stat.
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 »

lacilaci wrote: Sat Jan 19, 2019 6:40 pm This on gpu is going to be a beast(especially with multi-gpu setup)... If memory footprint of photon mapping can be low enough though.
I added some statistics log message about the memory usage:

Code: Select all

[LuxCore][2.502] Photon GI thread count: 12
[LuxCore][4.536] Photon GI Cache photon traced: 780288/5000000 [15.6%, 383.7M photons/sec, Map sizes (100.0%, 9.4%, 100.0%)]
[LuxCore][6.546] Photon GI Cache photon traced: 1554432/5000000 [31.1%, 384.3M photons/sec, Map sizes (100.0%, 18.8%, 100.0%)]
[LuxCore][8.564] Photon GI Cache photon traced: 2329600/5000000 [46.6%, 384.3M photons/sec, Map sizes (100.0%, 28.2%, 100.0%)]
[LuxCore][10.571] Photon GI Cache photon traced: 3106816/5000000 [62.1%, 385.0M photons/sec, Map sizes (100.0%, 37.7%, 100.0%)]
[LuxCore][12.580] Photon GI Cache photon traced: 3881984/5000000 [77.6%, 385.2M photons/sec, Map sizes (100.0%, 47.2%, 100.0%)]
[LuxCore][14.582] Photon GI Cache photon traced: 4658176/5000000 [93.2%, 385.6M photons/sec, Map sizes (100.0%, 60.9%, 100.0%)]
[LuxCore][15.674] Photon GI total photon traced: 5012480
[LuxCore][15.674] Photon GI total direct photon stored: 2005566 (4456448 traced)
[LuxCore][15.674] Photon GI total indirect photon stored: 1463428 (5000000 traced)
[LuxCore][15.674] Photon GI total caustic photon stored: 0 (0 traced)
[LuxCore][15.674] Photon GI total radiance photon stored: 3122366
[LuxCore][15.674] Photon GI building direct photons BVH
[LuxCore][16.086] Photon GI building indirect photons BVH
[LuxCore][16.389] Photon GI building radiance photon data
[LuxCore][18.389] Radiance photon filled entries: 1851262/3122366 (59%)
[LuxCore][19.808] Photon GI building radiance photons BVH
[LuxCore][20.456] Photon GI radiance cache photons memory usage: 109770Kbytes
[LuxCore][20.456] Photon GI radiance cache BVH memory usage: 126484Kbytes
[LuxCore][20.456] Photon GI total memory usage: 272845Kbytes
It requires 272Mbytes for the above scene. It is not a particularly big number in the era of 16GB GPUs.
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci »

Dade wrote: Sun Jan 20, 2019 9:42 am
lacilaci wrote: Sat Jan 19, 2019 6:40 pm This on gpu is going to be a beast(especially with multi-gpu setup)... If memory footprint of photon mapping can be low enough though.
I added some statistics log message about the memory usage:

Code: Select all

[LuxCore][2.502] Photon GI thread count: 12
[LuxCore][4.536] Photon GI Cache photon traced: 780288/5000000 [15.6%, 383.7M photons/sec, Map sizes (100.0%, 9.4%, 100.0%)]
[LuxCore][6.546] Photon GI Cache photon traced: 1554432/5000000 [31.1%, 384.3M photons/sec, Map sizes (100.0%, 18.8%, 100.0%)]
[LuxCore][8.564] Photon GI Cache photon traced: 2329600/5000000 [46.6%, 384.3M photons/sec, Map sizes (100.0%, 28.2%, 100.0%)]
[LuxCore][10.571] Photon GI Cache photon traced: 3106816/5000000 [62.1%, 385.0M photons/sec, Map sizes (100.0%, 37.7%, 100.0%)]
[LuxCore][12.580] Photon GI Cache photon traced: 3881984/5000000 [77.6%, 385.2M photons/sec, Map sizes (100.0%, 47.2%, 100.0%)]
[LuxCore][14.582] Photon GI Cache photon traced: 4658176/5000000 [93.2%, 385.6M photons/sec, Map sizes (100.0%, 60.9%, 100.0%)]
[LuxCore][15.674] Photon GI total photon traced: 5012480
[LuxCore][15.674] Photon GI total direct photon stored: 2005566 (4456448 traced)
[LuxCore][15.674] Photon GI total indirect photon stored: 1463428 (5000000 traced)
[LuxCore][15.674] Photon GI total caustic photon stored: 0 (0 traced)
[LuxCore][15.674] Photon GI total radiance photon stored: 3122366
[LuxCore][15.674] Photon GI building direct photons BVH
[LuxCore][16.086] Photon GI building indirect photons BVH
[LuxCore][16.389] Photon GI building radiance photon data
[LuxCore][18.389] Radiance photon filled entries: 1851262/3122366 (59%)
[LuxCore][19.808] Photon GI building radiance photons BVH
[LuxCore][20.456] Photon GI radiance cache photons memory usage: 109770Kbytes
[LuxCore][20.456] Photon GI radiance cache BVH memory usage: 126484Kbytes
[LuxCore][20.456] Photon GI total memory usage: 272845Kbytes
It requires 272Mbytes for the above scene. It is not a particularly big number in the era of 16GB GPUs.
~300MB is not much indeed. I wonder how does the ram usage going to be dependant on number of lights in scene and rendering resolution though...
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: PhotonGI cache

Post by Dade »

lacilaci wrote: Sun Jan 20, 2019 9:50 am ~300MB is not much indeed. I wonder how does the ram usage going to be dependant on number of lights in scene and rendering resolution though...
It scales up/down only with the number of photons (not directly with lights number or image resolution) however more lights can require to trace/store more photons. There should be pretty much no correlation with rendering image resolution.
Support LuxCoreRender project with salts and bounties
Post Reply