Env. Light Visibility Cache
Re: Env. Light Visibility Cache
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.
Re: Env. Light Visibility Cache
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.
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.
-
- Posts: 16
- Joined: Fri Mar 09, 2018 1:46 pm
Re: Env. Light Visibility Cache
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 with env. cache. map width 256 ,samples 1
The scene is lit by sun and flat colour world. Both results were rendered 100 samples.
This is without env. cache with env. cache. map width 256 ,samples 1
Re: Env. Light Visibility Cache
What's your clamping settings... If you want to use very low clamping you cannot avoid artifacts.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
In this case you need to raise clamping until the artifacting is not visible...
-
- Posts: 16
- Joined: Fri Mar 09, 2018 1:46 pm
Re: Env. Light Visibility Cache
That solved my problem, thanks.lacilaci wrote: ↑Sat Aug 31, 2019 6:23 amWhat's your clamping settings... If you want to use very low clamping you cannot avoid artifacts.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
In this case you need to raise clamping until the artifacting is not visible...
Re: Env. Light Visibility Cache
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).
Re: Env. Light Visibility Cache
Yes, but how much you increase the warmup samples, or how much to increase the clamping..? Can't be determined automatically can it?
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...
Re: Env. Light Visibility Cache
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
Re: Env. Light Visibility Cache
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)
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)
Re: Env. Light Visibility Cache
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.