PhotonGI cache

[Dade]

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

[Dade]

And yet still without metropolis photon gathering, right?

Yup.

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).

[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.

[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.

[Dade]

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.

Also on wich CPU are you rendering so we can make extrapolation on other hardware.

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:

[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

[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.

[Dade]

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.

[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.

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...

[Dade]

~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.