Page 1 of 4

2-Levels Env. Light Visibility Cache

Posted: Sat Feb 29, 2020 5:01 pm
by Dade
Introduction

This is an evolution of original Env. Light Visibility Cache described in this post. The code is available on "for_v2.4" branch (CPU already available, I have still to write the OpenCL code).

Results

An 1 samples/pixel without any cache (only importance sampling):

imp.jpg

An 1 samples/pixel with old Env. Light Visibility Cache:

c1.jpg

An 1 samples/pixel with new 2 levels Env. Light Visibility Cache:

c2.jpg

Note: all 3 methods are unbiased and converge to the correct solution on the long run.

As you can see, the new version deliver a more uniform and slightly less noisy result (at a fraction of the pre-processing time). You can think at the new solution like a mix of the first two:

1) at first level, the map is used;

2) than each pixel map corresponds to a tile where importance sampling is used.

The main advantage is that using, for instance, 32x16 tiles size is a bit like accelerating the pre-processing time by 32*16 = 512 times (!).

Parameters

The old 3 parameters have now no effect (i.e. default settings will be used):

Code: Select all

scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.width = 256
scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.height = 128
scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.samplecount = 4
You can use the new generic "quality" one:

Code: Select all

scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.quality = "low" or "medium" or "high"
#
# Set any of the following to 0 to enable the automatic "quality" setting
#
scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.tilewidth = 0
scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.tileheight = 0
scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.tilesamplecount = 0
Or explicit set the new one:

Code: Select all

scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.tilewidth = 32
scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.tileheight = 16
scene.lights.__WORLD_BACKGROUND_LIGHT__.visibilitymapcache.map.tilesamplecount = 4
Pre-processing time

The new code reduce the pre-processing time by an order of magnitude but it is still a good investment to spend few seconds in pre-processing time.

This is a 1 sample/pixel render with low quality setting and few millisecond of pre-processing:

low.jpg

This is a 1 sample/pixel render with high quality setting and and about 10 seconds of pre-processing:

high.jpg

Re: 2-Levels Env. Light Visibility Cache

Posted: Sat Feb 29, 2020 6:58 pm
by lacilaci
Hm. Ok, how about memory footprint

and how about the situation where old solution time and mem usage would vary heavily depending on camera placement?
(for example old/current env. Cache can skyrocket mem and preprocess times when you put camera next to a small object in an interior)

And how about open-space situations where using current env cache can cause excessive noise on objects directly visible to env light?

I like that there is progress on this solution but also a 3-5 or 10 sec. preprocess is incredibly long for previews and without env cache interior previews could look too bad even for previews.

Can this be a progressive feature? Like start quickly with weak settings for env cache and update cache during rendering? 10 seconds of preprocess is noticeable much more than 10seconds during a rendering (perception)

Re: 2-Levels Env. Light Visibility Cache

Posted: Sat Feb 29, 2020 9:04 pm
by Sharlybg
Really nice global improvement thanks you for that. Look like 2.4 will be an interesting version.
The main advantage is that using, for instance, 32x16 tiles size is a bit like accelerating the pre-processing time by 32*16 = 512 times (!)
Is that can be applied to PGI cache too ?

I remenber somewhere you said that this take way less memory also.

Anyway it is more than welcome.

Re: 2-Levels Env. Light Visibility Cache

Posted: Sun Mar 01, 2020 9:53 am
by Dade
lacilaci wrote:
Sat Feb 29, 2020 6:58 pm
Hm. Ok, how about memory footprint
It reduced by the same amount of pre-processing time: visibility maps have less pixel so they are both faster to compute and take less memory.
lacilaci wrote:
Sat Feb 29, 2020 6:58 pm
And how about open-space situations where using current env cache can cause excessive noise on objects directly visible to env light?
It doesn't make sense to use ELVC in an outside scene, it is a tool aimed to solve the same problem portals are used for (would you use portals in an outdoor scene ?).
lacilaci wrote:
Sat Feb 29, 2020 6:58 pm
I like that there is progress on this solution but also a 3-5 or 10 sec. preprocess is incredibly long for previews and without env cache interior previews could look too bad even for previews.
Low quality setting usually takes milliseconds.
lacilaci wrote:
Sat Feb 29, 2020 6:58 pm
Can this be a progressive feature? Like start quickly with weak settings for env cache and update cache during rendering? 10 seconds of preprocess is noticeable much more than 10seconds during a rendering (perception)
It would be possible only on the CPU, not the GPU.

Re: 2-Levels Env. Light Visibility Cache

Posted: Sun Mar 01, 2020 9:54 am
by Dade
Sharlybg wrote:
Sat Feb 29, 2020 9:04 pm
Is that can be applied to PGI cache too ?
No, one is about visibility, the other is about values of indirect light.

Re: 2-Levels Env. Light Visibility Cache

Posted: Sun Mar 01, 2020 5:06 pm
by Fox
I had some issues building the v2.4 branch yesterday, can't wait to test this new feature.

Re: 2-Levels Env. Light Visibility Cache

Posted: Sun Mar 01, 2020 6:03 pm
by juangea
Great improvement, 2.4 is already being awesome, I’m eager to get Blendluxcore 2.4 as soon as there is a first version on git :)

Re: 2-Levels Env. Light Visibility Cache

Posted: Mon Mar 02, 2020 10:31 am
by marcatore
yes.. 2.4 seems being great.

About the outdoor vs indoor I really don't understand because they're interpreted as two worlds apart.
I know that speaking about the lighting setup there is differences due to the less aperture you have in an interior than an outdoor... but if I'm rendering an image where I have my cam in a garden of a villa and I'm point the view to the living of the house (I'm probably describing 90% of the archviz rendering situation), you're considering this as an outdoor rendering or interior?
why should I consider the noise inside the living as good thing cause I'm outdoor so any environment lighting feature is useful?

In my opinion, a way to have a good-less-noise-as-possible solution for environment lighting is good as itself, not because you're indoor or outdoor.
I mean, if it works, it should works well in both situation.

In any case, as soon as we'll start to test a nightly build we'll check with some real case.
I'm doing some tests about env light and I can't find a way to clean it and I dont' understand why, at the moment, env light add noise.

Re: 2-Levels Env. Light Visibility Cache

Posted: Mon Mar 02, 2020 10:44 am
by juangea
I think the outdoor/indoor thing is more of "where" is your camera placed, more than "what do you see in the picture", of course there will always be extreme cases where the camera is outside and the inside is filling the view, in that case maybe the env cache makes sense, but if you are outside in the garden, I bet evn cache makes less sense, or maybe it does if it detects the windows, but I'm not sure TBH.

Re: 2-Levels Env. Light Visibility Cache

Posted: Mon Mar 02, 2020 11:07 am
by Dade
juangea wrote:
Mon Mar 02, 2020 10:44 am
I bet evn cache makes less sense, or maybe it does if it detects the windows, but I'm not sure TBH.
It would work (while portals wouldn't) but you have the problem that in outside rendering you have usually a lot more surfaces to cover with cache entries than in an indoor rendering: outdoor would require some kind of variable cache entry radius to cover near objects (with a small cache entry radius) and far large objects (with a large cache entry radius).

The automatic cache entry radius estimation already works in screen space (so it doesn't matter if you are rendering a 10cm room or 10km room) however the cache uses a fixed entry radius at the moment so it is problematic to render something with both visible small and large objects. This could probably be the next improvement (i.e. variable cache entry radius).