PhotonGI cache

Discussion related to the Engine functionality, implementations and API.
Post Reply
User avatar
Dade
Developer
Developer
Posts: 2537
Joined: Mon Dec 04, 2017 8:36 pm

PhotonGI cache

Post by Dade » Mon Jan 14, 2019 4:17 pm

Introduction

There 2 GI cache solutions highlighted during the features poll:

1) A V-Ray like solution mostly based on photon mapping. Characteristics: biased, pre-processing, GPU viable, path tracing only, very fast, sometime tricky.

2) A Corona like solution mostly based on reducing the noise by driving the traced paths according the importance. The name "cache", in this case, is not even appropriate. Characteristics: unbiased, on-line training (very little pre-processing), not GPU viable, bidirectional and normal path tracing, not faster (but with less noise), easy to use (i.e. "fire and forget").

Note: I don't have the V-Ray or Corona sources so the above statements are based on publicaly available information and papers.

I'm currently working on #1 solution. The optimal would be to have #1 for GPU path tracing and #2 for CPU bidirectional so it may be worth work on #2 in the future too.

Direct light cache

This is cache is mostly used for building indirect light cache and it is not usually directly used for the rendering due to far better result you can get with normal direct light sampling. There is still a possible direct light cache application (see below: all caches enabled). The output of the cache looks like:

direct.jpg

You can reduce the "splotch-ness", by tracing more photons, up to the point to have a correct render but normal direct light sampling works well and is already fast enough. Note how this image is rendered using only 1 ray per pixel thanks to the cache (it is fast, very fast). The is true for any cache usage: instead of tracing a long chain of rays, you do a cache look up and it is done.


Indirect light cache


This cache starts to be very useful and it transforms the complete computation of the global illumination in just a cache lookup. The output of the cache is similar the indirect light AOV:

indirect.jpg

And a complete rendering with the cache:

all.jpg

As you can see, the "splotch-ness" in indirect light is not noticeable (because of the very smooth way indirect lighting works). This image is rendered using only 3 rays per sample: 1 to find the first intersection point, 1 for direct light sampling and 1 for indirect light cache lookup. Normally, this scene requires 5-6 rays per samples.


Caustic cache


Caustic cache is used to render caustics. Some scene like the Cornell box doesn't use one for the obvious reason there are not specular surfaces and caustics. However in a scene like the Psor's cube, the output of the cache looks like:

caustic.jpg

And a complete rendering with the cache:

allcaustic.jpg

Note: this is a path tracing rendering, not a bidirectional one. Path tracing is not even vaguely able to render this caustic without the cache. With the cache, it is rendered nearly for free.

All caches enabled

When all 3 caches (including direct light one) are enabled, they will be merged in a single one and used, specular reflections/transmissions aside, after having traced just one single ray. While the direct light cache cause some splotch-ness, it is a view independent cache that can be shared across all the frames of an animation where you are moving only the camera. This makes rendering the preview of an animation a very fast process. The output looks like:

preview.jpg

It is not usable for a final render but it is good enough for a animation preview.

Pre-processing time

The pre-processing time of the above renderings is about 2secs for Cornell box and 30secs for Psor's cube.

Default configuration

Like I wrote, direct light cache is not used by default. The default configuration should be:
  • Direct light cache disabled
  • Indirect light cache enabled
  • Caustic light cache enabled
You can combine the caches as you want and having all 3 enabled triggers the special case described above.

Properties

This is the list of properties (with their default values) currently used:

Code: Select all

# Select the sampler type for tracing photon paths: RANDOM or METROPOLIS
path.photongi.sampler.type = METROPOLIS

# Enable/Disable visibility information usage (for Metropolis)
path.photongi.visibility.enabled = 1
path.photongi.visibility.targethitrate = 0.99
path.photongi.visibility.maxsamplecount = 1048576

# Leave disabled (aside from pre-views)
path.photongi.direct.enabled = 0
# Enable to use the indirect light cache
path.photongi.indirect.enabled = 0
# Enable to use the caustic light cache
path.photongi.caustic.enabled = 0

# Max. number of photons traced
path.photongi.photon.maxcount = 100000
# Max. depth of photon paths
path.photongi.photon.maxdepth = 4

# Max. number of photons stored in direct light cache
path.photongi.direct.maxsize = 100000
# Max. number of photons stored in indirect light cache
path.photongi.indirect.maxsize = 100000
# Max. number of photons stored in caustic light cache
path.photongi.caustic.maxsize = 100000

# Cache look up radius
path.photongi.lookup.maxcount = 48
# Cache look up radius
path.photongi.lookup.radius = 0.15
# Cache look up normal angle
path.photongi.lookup.normalangle = 10.0

# Force the visualization of one of the caches
# Possible values: showdirect, showindirect, showcaustic, none
path.photongi.debug.type = none
Materials have a new property to enable/disable PhotonGI on the assigned surface:

Code: Select all

# Enable/disable PhotonGI on the assigned surface
scene.materials.<material name>.photongi.enable = 1
Work in progress

This is the start of the development, not the end. Some current limitation that will be removed in the future:

1) Cache entries are currently created only on generic "DIFFUSE | GLOSSY | REFLECT" materials (all not specular and not transparent materials);
2) You probably want to avoid infinite lights and/or very open scenes because they require to fire a lot of photons (as they have to "irradiante" a large surface);
3) serialization is not supported (aka sharing/saving/loading the cache from file).
4) etc.
Support LuxCoreRender project with salts and bounties

User avatar
lacilaci
Donor
Donor
Posts: 1118
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci » Mon Jan 14, 2019 4:50 pm

So many questions...

Was cache calculation in case of psor's cube so long cause of caustic cache or would it be a problem even for normal gi cache?
So this cache is tracing photons from lights? Not like vray's lightcache which is reversed/tracing from camera(according to some doc's I've read)?
How would this gi cache work with glass if I disable caustic cache? Will it go through glass?

I don't know how many of the limitations can be overcome. The pathguiding way or whatever is the corona like solution based on, sounds like something way more user friendly and something that could be (like in corona) simply be turned on by default when rendering on cpu.

Now this is just my opinion. But I'd say rather have super flexible and easy to use caching even if cpu only. Than a cache that might work on gpu but might also be useless in some situations(exteriors etc...) that sounds like the dead end mental ray went, solutions built on top of other and you have to first master endless settings and troubleshooting before you get to rendering...

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

Re: PhotonGI cache

Post by Sharlybg » Mon Jan 14, 2019 8:23 pm

Thanks you very much for this huge development boost. It is clear 2019 will rock. A bit of hope in a nasty world. Caustic for free are so impressive mind blowing stuff. :shock: .
Very inspiring if everyone (i mean the entire Luxcore community )push like you we are going to be on mars before Elon Team. Thanks a lot. Again what an amazing caustic it is so beautiffull can't imagine it is biased even at 1%. Wow.

Just have problem to understand difference between Direct light cache and indirect light cache. Also don't understand what is a lookup cache. Do direct light cache have something to play with DLSC ? Why direct light cache is off by default ? Do we still have boost from caching when it is off ? How ? Why theses two caches for indirect light compute. Isn't only indirect light cache needed !

Anyway thank you also for considering the optimal possibility to have corona like caching method.just burning waiting for test. :D
Support LuxCoreRender project with salts and bounties

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

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

Re: PhotonGI cache

Post by Dade » Mon Jan 14, 2019 8:30 pm

lacilaci wrote:
Mon Jan 14, 2019 4:50 pm
Was cache calculation in case of psor's cube so long cause of caustic cache or would it be a problem even for normal gi cache?
Yes, caustics are usually very sharp and they are harder to render than smooth indirect light however I wouldn't define a 30secs a long time if you than render, for instance, for 4 hours at 4K. I mean, it still a good deal to have 15 minutes pre-processing if you than save 2 hours in a 4 hours long rendering.
lacilaci wrote:
Mon Jan 14, 2019 4:50 pm
So this cache is tracing photons from lights?
Yes.
lacilaci wrote:
Mon Jan 14, 2019 4:50 pm
Not like vray's lightcache which is reversed/tracing from camera(according to some doc's I've read)?
There are several options:

1) trace the photons uniformly from the light sources;

2) use a Metropolis-like sampler to shoot photons towards the camera (something I have done in the past);

3) backward tracing starting from the camera;

#1 is good for animation and it is view independent while #2/#3 are more efficient but create heavily view dependent caches. #2/#3 are good for single image rendering but they require to re-run the pre-processing for each animation frames.
I think we need both and, clearly, once we have #1, it is easier to implement #2 than #3.
lacilaci wrote:
Mon Jan 14, 2019 4:50 pm
How would this gi cache work with glass if I disable caustic cache? Will it go through glass?
Yes and yes: a caustic cache will be still internally built to create the GI cache but it can be of low quality because of the indirect light smoothness.
lacilaci wrote:
Mon Jan 14, 2019 4:50 pm
that sounds like the dead end mental ray went, solutions built on top of other and you have to first master endless settings and troubleshooting before you get to rendering...
I think Mental (and may be V-Ray) can (or have optins to) use irradiance caching with interpolation (something similare to the old Radiance https://www.radiance-online.org). Irradiance caching is veeery tricky and can easily lead to a lot of artifact. It is the fastest possible solution but it is really hard to use.
At the end of the day, we don't have the sources so we don't really know what they are doing.

The caches are quite a mine of useful information, for instance:

- DLSC could be built out of them instead of being a separate process.

- Corona-like importance driven rendering could be done using photon (direction) information too.

- etc.

Like I wrote, it is the beginning of the development of this topic.
Support LuxCoreRender project with salts and bounties

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

Re: PhotonGI cache

Post by Dade » Mon Jan 14, 2019 8:40 pm

Sharlybg wrote:
Mon Jan 14, 2019 8:23 pm
Just have problem to understand difference between Direct light cache and indirect light cache. Also don't understand what is a lookup cache.
A cache look up is the search of a result inside the cache. The result is (more or less) the color of a sample.
Sharlybg wrote:
Mon Jan 14, 2019 8:23 pm
Do direct light cache have something to play with DLSC ?
DLSC tell the code what light source is better to sample than you still have to trace a shadow ray, etc. Direct light cache returns a the color/intensity of direct light illumination. Indeed, the cache is a lot faster (and biased). DLSC is more a Corona-like, reduces a lot the noise but the cost of each sample is still the same.
Sharlybg wrote:
Mon Jan 14, 2019 8:23 pm
Why direct light cache is off by default ?
Because it is too "splotchy" to be directly usable (pre-views aside)
Sharlybg wrote:
Mon Jan 14, 2019 8:23 pm
Why theses two caches for indirect light compute. Isn't only indirect light cache needed !
A sample is the result of multiple illumination components: light received directly, light bouncing over other diffuse/glossy surfaces, light going trough or bouncing over spectacular surfaces (i.e. glass, mirrors).

They can be computed independently and with different techniques (tracing rays, searching a cache, interpolation of near values, etc.).
Support LuxCoreRender project with salts and bounties

User avatar
epilectrolytics
Donor
Donor
Posts: 403
Joined: Thu Oct 04, 2018 6:06 am

Re: PhotonGI cache

Post by epilectrolytics » Mon Jan 14, 2019 8:51 pm

Most exciting thing ever!

I have always wondered why no-one used a photon map to do importance sampling of indirect illumination similar to direct light sampling.
But I don't know if I understand what is going on here.

A point of a (matte) surface is illuminated mainly by the bright parts of its environment (no matter how close).
If those bright parts are actually lights, direct sampling will quickly deal with those.
But if the bright parts are other bright surfaces, a path tracer with random sampling will find them by chance only.
But if there was a (photon)map of the illumination of all surfaces (camera independent, because occluded parts contribute to illumination), at each bounce a lookup of the photon map / cache could be used for importance sampling with regard to where to aim the ray instead of choosing a random direction.
(Also each successfully traced path finding a light yields information about the illumination at each bounce which could be additionally stored in the photon map.)

Now this would be unbiased and work with GPU.
The problem would not be the creation of the map (which does not need to be very accurate or detailed, it just needs to tell the bright areas apart from the dark ones) but the creation of a local hemispherical representation at each bounce.
Also specular surfaces are tricky because their brightness is directional so their map entries must be vectors, even multidimensional ones because directionalities of different sources can mix.

From what I read here #1 and #2 work both differently to what I thought but then I'm no expert and probably have a wrong understanding.

I am thinking in the case of GPU path tracing the CPU could do the photon mapping simultaneously and refine (simplify as large homogenous areas like ceilings don't need much entries) it over time while the path tracer's convergence estimation could tell the photon mapper where to send more photons, like they are talking to each other.

But however it actually works, it is definitely a most welcome improvement, thanks Dade for providing this awesome stuff!
MBPro 15" 16GB i7-4850HQ GT750M, MacOS 10.13.6 & Win10Pro PC 16GB Ryzen 2700X, RTX 2070, GTX 1060

User avatar
lacilaci
Donor
Donor
Posts: 1118
Joined: Fri May 04, 2018 5:16 am

Re: PhotonGI cache

Post by lacilaci » Tue Jan 15, 2019 6:38 am

Dade wrote:
Mon Jan 14, 2019 8:30 pm

I think Mental (and may be V-Ray) can (or have optins to) use irradiance caching with interpolation (something similare to the old Radiance https://www.radiance-online.org). Irradiance caching is veeery tricky and can easily lead to a lot of artifact. It is the fastest possible solution but it is really hard to use.
At the end of the day, we don't have the sources so we don't really know what they are doing.

The caches are quite a mine of useful information, for instance:

- DLSC could be built out of them instead of being a separate process.

- Corona-like importance driven rendering could be done using photon (direction) information too.

- etc.

Like I wrote, it is the beginning of the development of this topic.
All of mentioned renderers have actually the possibility to use 2 gi engines(one for primary bounces, one for secondary), in case of mental ray it was photon mapping and final gathering. Vray was mostly using irradiance cache for primary bounces and lightcache(based on photon mapping - traced from camera) for secondary bounces back in the day, now it is mostly brute force/pathtracing+lightcache and corona in it's beginning had some experimental primary engines(including irradiance mapping-never fully developed) but now it's pathtracing+uhd cache.

Anyway, looking forward to see where this goes. (any estimate for experimental daily builds?)

zeealpal
Posts: 11
Joined: Wed Jan 10, 2018 12:25 pm

Re: PhotonGI cache

Post by zeealpal » Tue Jan 15, 2019 2:45 pm

Daily builds are available through here:

viewtopic.php?t=736

Will test when I have time tomorrow

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

Re: PhotonGI cache

Post by Dade » Tue Jan 15, 2019 7:02 pm

zeealpal wrote:
Tue Jan 15, 2019 2:45 pm
Daily builds are available through here:

viewtopic.php?t=736

Will test when I have time tomorrow
Note: lately, the Windows builds fail because they run apparently out of memory: https://dev.azure.com/LuxCoreRender/Lux ... nitionId=1

Code: Select all

d:\a\1\luxcore\src\luxrays\utils\ocl.cpp(252,0): Error C1002: compiler is out of heap space in pass 2
LINK(0,0): Error LNK1257: code generation failed
d:\a\1\windowscompiledeps\include\tbb\concurrent_hash_map.h(891,0): Error C1002: compiler is out of heap space in pass 2
LINK(0,0): Error LNK1257: code generation failed
d:\a\1\windowscompiledeps\include\tbb\concurrent_hash_map.h(891,0): Error C1002: compiler is out of heap space in pass 2
d:\a\1\windowscompiledeps\include\tbb\concurrent_hash_map.h(892,0): Error C1002: compiler is out of heap space in pass 2
d:\a\1\luxcore\deps\openvdb-3.1.0\openvdb\tree\treeiterator.h(116,0): Error C1002: compiler is out of heap space in pass 2
Process 'msbuild.exe' exited with code '1'.
Not sure if Azure has reduced the amount of VM memory or we are just starting to be too "big" to compile.

@Acasta69 , would be nice if you could look into the problem, I'm not very experienced with VisualStudio :idea:
Support LuxCoreRender project with salts and bounties

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

Re: PhotonGI cache

Post by Dade » Tue Jan 15, 2019 7:04 pm

lacilaci wrote:
Tue Jan 15, 2019 6:38 am
V-Ray [...] now it is mostly brute force/pathtracing+lightcache
This is what I'm aiming for at the moment.
Support LuxCoreRender project with salts and bounties

Post Reply