LuxCoreRender Forums

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


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


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


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):
You can use the new generic "quality" one:
Or explicit set the new one:
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:


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

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)

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.

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.

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.

I had some issues building the v2.4 branch yesterday, can't wait to test this new feature.

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

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.

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.

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