Env. Light Visibility Cache

Discussion related to the LuxCore functionality, implementations and API.
User avatar
FarbigeWelt
Donor
Donor
Posts: 1046
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: Env. Light Visibility Cache

Post by FarbigeWelt »

lacilaci wrote: Wed May 29, 2019 6:09 am Here's some of my amateur opninions about mapping and caching visibility.

no mapping:
nomap.jpg
cache:
cachemap_defaults.jpg


It's just my opinion and I know it's early as this just got into luxcore, but I rather say it now since I don't see a happy ending for this cache :D
Well, what I see is there is a big opportunity for improvements. Your pictures show how well the cache works and that there is not much needed to reach the point of satisfaction.

For me it looks like a little setting issue like e.g. a wrong angle or some kind of threshold.
And if the solution for this issue at your second picture is not that easy to be solved there might be a way to reduce the sharpness of cache/non cache border.
However, It seems difficult to introduce an algorithm that smooths / blends transition from higher to lower converged areas but it would result in much more satisfying renders if there were any smoother for all kind of cached features.

In my open opinion there are more opportunities than threats of this new, great early state feature Dade introduced lately.

My wish is that Dade develops the missing parts to perfect the feature rather than following your ask to spend not more time.
Last edited by FarbigeWelt on Wed May 29, 2019 7:43 am, edited 1 time in total.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

marcatore wrote: Wed May 29, 2019 7:12 am
lacilaci wrote: Wed May 29, 2019 6:09 am ...
So I say, we need portals and abandon the whole vismap/caching method. People already know the caveats of using portals wrong, it's a pretty much a standard way of dealing with interiors and there is no time spent with setting up resolutions and sampling and then praying it will work.
...
I don't manage the Dade time so it's just an opinion like others.

I think that eliminate portals will be a good solution looking to the future.
Vray eliminates the need of in the last releases developing adaptive solutions.

I think it's great cause it reduces the scene management and setting.

Sure, and "Captain Obvious mode ON", if we should use a semi-working solution it's better to stay with "old school" portals.

It's "just" a Dade matter in terms of feeling to do the right thing cause he sees a bright future on this method.
Let's see where will be.
Yes of course, not having to deal with portals would be great. But I'm not so sure caching will work and also default visibility map has issues with productviz scenes too, so obviously I would rather have working portals than nothing at all.

Vray's adaptive lights are great, but it is built on top of probabilistic lighting, not mapping areas and creating new maps. Lightcache data is used only to to do smarter probabilistic lighting:

from chaosgroup:

Probabilistic lighting:

In this method, for every ray hit we randomly pick a small fixed number of lights. The default is 16 lights, in our examples for illustrative purposes we will assume this number is 5. This drastically reduces the number of calculations for the shaded point. Since the next ray picks another 5 lights, and we generally fire millions of rays, on average all the lights tend to be accounted for. Generally speaking, this method can be faster compared to the old method which took into account every light at every ray hit. However one disadvantage is that it may introduce additional noise in the image and may need more samples to clean up. Additionally, some shading points may be taking into account lights that are not visible or don’t contribute illumination to that area.

Adaptive lighting:

This method builds on top of the probabilistic method but makes it smarter about the lights it selects for evaluation. It relies on the Light Cache pass. The Light Cache is generally used for Global Illumination, but it also gives V-Ray a good overview of what is actually happening in the scene. In the end, the result is such that instead of picking 5 random lights, we can pick 5 lights that are the most likely to affect the shaded point. This can help V-Ray achieve a cleaner solution faster.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

FarbigeWelt wrote: Wed May 29, 2019 7:33 am
lacilaci wrote: Wed May 29, 2019 6:09 am Here's some of my amateur opninions about mapping and caching visibility.

no mapping:
nomap.jpg
cache:
cachemap_defaults.jpg


It's just my opinion and I know it's early as this just got into luxcore, but I rather say it now since I don't see a happy ending for this cache :D
Well, what I see is there is a big opportunity for improvement. Your pictures show how well the cache works and that there is not much needed to smooth the shadow to the point of satisfaction.
For me it looks like a little setting issue like e.g. a wrong angle or some kind of threshold.
And if this solution is not that easy there might be a way to reduce the sharpness of cache borders.
It seems difficult to introduce an algorithm that smooths / blends transition from higher to lower converged areas but it would result in much more satisfying renders.

In my open opinion there are more opportunities than threats of this new great early state feature Dade introduced lately.
Yes I understand, but I'm also worried that it will end up like DLCS which is mostly useless since you always have the risk that it will introduce artifacts that cannot be dealt with and so it's a no-go for production purposes.
marcatore
Donor
Donor
Posts: 463
Joined: Wed Jan 10, 2018 8:04 am

Re: Env. Light Visibility Cache

Post by marcatore »

I was thinking about these feature speaking about environment lighting.

The first one is this (that should be similar of what Dade developed before this Env Lighting Visibility Cache)
https://docs.chaosgroup.com/display/VRA ... eLight-IBL

And the next one is this

"Adaptive dome (WIP)* – Speeds up the rendering by optimising the sampling algorithm for the dome light. No light portals are needed with this setup. Light Cache must be set as the GI engine for this feature."
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

marcatore wrote: Wed May 29, 2019 7:44 am I was thinking about these feature speaking about environment lighting.

The first one is this (that should be similar of what Dade developed before this Env Lighting Visibility Cache)
https://docs.chaosgroup.com/display/VRA ... eLight-IBL

And the next one is this

"Adaptive dome (WIP)* – Speeds up the rendering by optimising the sampling algorithm for the dome light. No light portals are needed with this setup. Light Cache must be set as the GI engine for this feature."
Well this still says it's based on the way adaptive lights work...

Look all I'm saying is that if this thing can't work on it's own without user input, then we might be better off with portals until something more reliable can replace it.

But I also might overreacting to these artifacts too soon and it might have a solution...

BTW. I managed to start the rendering with vismapcache at 512 and samples at 8, but artifacting is pretty much the same.(not a region render)
User avatar
B.Y.O.B.
Developer
Developer
Posts: 4146
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Env. Light Visibility Cache

Post by B.Y.O.B. »

Note that like always, I first expose all parameters and later hide the ones that do not need adjustment.

In my tests so far changing map width or samples didn't change anything, so I hope we can hide these parameters.
The visibility map has similar extra parameters by the way which are completely hidden because the defaults are good for all cases.

So in the end, I hope that the trial&error will be reduced to "try the cache and see if it makes the render faster".
marcatore
Donor
Donor
Posts: 463
Joined: Wed Jan 10, 2018 8:04 am

Re: Env. Light Visibility Cache

Post by marcatore »

lacilaci wrote: Wed May 29, 2019 8:38 am Look all I'm saying is that if this thing can't work on it's own without user input, then we might be better off with portals until something more reliable can replace it.
I'm with you, I prefer an "old school" but reliable method than a "random-working" one but, in my opinion, at the moment it's early.
It's the first days of this feature and I hope there will be margin to solve the main issues.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Env. Light Visibility Cache

Post by Sharlybg »

Dade wrote: Sun May 26, 2019 3:23 pm
lacilaci wrote: Sun May 26, 2019 3:10 pm This is looking really nice, won't it fall apart with more complex situation/obstacles?
I don't know, there are millions of possible combinations to tests.
lacilaci wrote: Sun May 26, 2019 3:10 pm Is it fully automated solution?
Yes, you can control the resolution of the visibility maps to use more/less memory (and have more/less accurate maps) but it is pretty much automated.

For me it is simply too early to judge anything. I remenber the PGI caching day development where artifact killed everything and people worried alot. Finally we have a game changer.
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: Env. Light Visibility Cache

Post by Dade »

B.Y.O.B. wrote: Tue May 28, 2019 2:58 pm It looks like the cache doesn't work yet with constantinfinite lights (without HDRI)?
I should have fixed this problem.
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

some more testing, assets are in empty space only lit by hdri

cache on:
kitchenasset_CACHEvismap.jpg
cache off:
kitchenasset_novismap.jpg
artifacting seems pretty random to me, also like I mentioned before in mostly hdri lit case like product viz best performance is without visibility map altogether.
Post Reply