Env. Light Visibility Cache

Discussion related to the LuxCore functionality, implementations and API.
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 »

P.S. the solution the problem is to have cache entries with variable adaptive radius (more entries, with smaller radius, near the camera and less entries, with larger radius, far from the camera) however it is not going to happen in v2.2.
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 »

I'm sorry, but compared to dlsc and indirrect cache this is a terrible and counterintuitive solution and portals are much more versatile and problem free... for example.

cache:
using different settings for previews and finals, trial and error finding out good and fast settings, slow, eats ram, doesn't work well with large openned scene for hdri

portals:
you put them in the openings of the scene if there are any, known concept to everyone, usable for previews, no preprocess and no settings and no extra memory usage and stable for animation without storing additional data.

I understand that you want modern and automatic solution and it is what vray has and corona will have. But the way it works right now is very problematic and inferior to portals.

I'm in no position to tell you what to do, but right now my opinion is that the best course would be to have portals until this automatic solution evolves enough to make portals obsolete.
frank_yifei
Posts: 16
Joined: Fri Mar 09, 2018 1:46 pm

Re: Env. Light Visibility Cache

Post by frank_yifei »

I did a test with my internal scene. How to avoid the artefacts?
The scene is lit by sun and flat colour world. Both results were rendered 100 samples.
This is without env. cache
untitled1.jpg
with env. cache. map width 256 ,samples 1
untitled.jpg
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

frank_yifei wrote: Sat Aug 31, 2019 5:53 am I did a test with my internal scene. How to avoid the artefacts?
The scene is lit by sun and flat colour world. Both results were rendered 100 samples.
This is without env. cache
untitled1.jpg
with env. cache. map width 256 ,samples 1
untitled.jpg
What's your clamping settings... If you want to use very low clamping you cannot avoid artifacts.
In this case you need to raise clamping until the artifacting is not visible...
frank_yifei
Posts: 16
Joined: Fri Mar 09, 2018 1:46 pm

Re: Env. Light Visibility Cache

Post by frank_yifei »

lacilaci wrote: Sat Aug 31, 2019 6:23 am
frank_yifei wrote: Sat Aug 31, 2019 5:53 am I did a test with my internal scene. How to avoid the artefacts?
The scene is lit by sun and flat colour world. Both results were rendered 100 samples.
This is without env. cache
untitled1.jpg
with env. cache. map width 256 ,samples 1
untitled.jpg
What's your clamping settings... If you want to use very low clamping you cannot avoid artifacts.
In this case you need to raise clamping until the artifacting is not visible...
That solved my problem, thanks.
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 »

Increasing the number of cache warm up samples may also allow you to lower clamping values (because the cache entries will be more accurate and will relay less on MIS to render the right image: strong clamping can break MIS).
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 »

Dade wrote: Sat Aug 31, 2019 10:44 am Increasing the number of cache warm up samples may also allow you to lower clamping values (because the cache entries will be more accurate and will relay less on MIS to render the right image: strong clamping can break MIS).
Yes, but how much you increase the warmup samples, or how much to increase the clamping..? Can't be determined automatically can it? :idea:

Can you tell when it breaks in the code? Can you design a safety net auto-setting for low clamping values?

Because, since people in general don't know there is a difference between clamping values in some renderer vs clamping in luxcore, values from 1 to ~25 will very likely be what users try since these are values found from cycles to corona...
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 »

Estimation of clamping value is not hard but it can be done only by doing a (test) rendering. I could do it as (yet another) pre-preprocessing step :idea:
Support LuxCoreRender project with salts and bounties
Racleborg
Posts: 621
Joined: Sat Apr 07, 2018 10:31 am
Location: UK

Re: Env. Light Visibility Cache

Post by Racleborg »

Does it matter which way around the PGI/Environment Cache and the Max Brightness clamping is set up?

So, if I render a scene with Max Bright clamp ‘OFF’ and with 'Compute and Overwrite' the PGI/Enviorement Cache ‘ON’, and then re-render with the MAX BRIGHT ‘ON’ and the PGI Compute and Overwright ‘OFF’ is that correct?

Thanks you (I hope my question makes sense)
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

Dade wrote: Sat Aug 31, 2019 12:55 pm Estimation of clamping value is not hard but it can be done only by doing a (test) rendering. I could do it as (yet another) pre-preprocessing step :idea:
how about this crazy idea.
Instead of preprocessing and "testing" we start rendering few samples without env cache contribution.

Gather needed info about samples values/clamping during rendering.

Then process those during rendering (on fewer cores) and give results back - boosting rendering... Basicaly on-the-fly calculation.

This way we could have fast preview feedback without preprocessing and when we decide to keep rendering then the env.cache contribution kicks in. Maybe the actual rendering data could be even more valuable for env.cache optimization than forcing everything to preprocess and sticking with what was decided?

Maybe take it even further and make it progressive? Some form of adaptivity? Where we start lightweight and with very low res env.cache and slowly refine it based on rendering data?

My point is fast startup and no setup for this solution. If it was smart enough it could even decide that scene is too much open space and it should self-disable, so that we have a true full "auto-portals" solution.
Post Reply