Env. Light Visibility Cache

Discussion related to the LuxCore functionality, implementations and API.
kintuX
Posts: 809
Joined: Wed Jan 10, 2018 2:37 am

Re: Env. Light Visibility Cache

Post by kintuX »

I too presumed these issues will occur with lack of portals some time ago, soonish after PGI cache started.
It's simply not as efficient as placing "guides" manually. It brings benefits for sure, but most likely it will take a few more years of headbanging and experimenting for "smart & selective" computation.

Indeed VRay uses "adaptive dome ligh" (I think it's like Env. cache) and portals to use for complex cases as we're witnessing here. Corona only portals. What I had in mind was UHD & other GI/IR caches for which it is commonly known that they are not meant to be used "outside". My bad and sorry for lack of explanation.

But I fully agree, code is not there yet to be fully automated & now we need both ways. For sort of semi-automated workflow. 'Helpers' to add here & there. :)

Here's an animation with Env. cache - Visibility Map on.
And as Dade already mentioned, now Light Tracing needs persistent cache for animations. ;)
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 »

lacilaci wrote: Mon Jul 22, 2019 11:59 am
Sharlybg wrote: Mon Jul 22, 2019 11:30 am
However I'm not sure about cache, if those patches can't be fixed it's unreliable and I would not risk using it at all
Can you provide a small scene that show the issue ?
What do you mean? The scene is in the attachment where I posted some results.
i mean do you get some kind of artefact or splotches when using direct cache ?

i mean this :
Yes it crashes for me too in an interior scene, previous build (not sure which) worked but I was still getting very ugly artifacting form env.cache in more complex scenes and it actually never dissappeared even after ~1000 samples.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

Sharlybg wrote: Mon Jul 22, 2019 4:26 pm
lacilaci wrote: Mon Jul 22, 2019 11:59 am
Sharlybg wrote: Mon Jul 22, 2019 11:30 am

Can you provide a small scene that show the issue ?
What do you mean? The scene is in the attachment where I posted some results.
i mean do you get some kind of artefact or splotches when using direct cache ?

i mean this :
Yes it crashes for me too in an interior scene, previous build (not sure which) worked but I was still getting very ugly artifacting form env.cache in more complex scenes and it actually never dissappeared even after ~1000 samples.
I was talking about environment visibility cache not direct light cache (although that one has problems too)

If you want to see the artifacting, try my testscene which I already mentioned is in my post with results of my testing. Can't try more complex scene cause it's buggy now.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

Another issue I'm getting is when rendering region. It's very random it seems.
Sometimes when I do region rendering with env.cache on I get this:
regionRender_envcache.jpg
I think I managed to isolate the region+envcache problem

If you try render this saved file it should eat up ram for quite a while and then throw the error about framebuffer
279_luxcore_regionBug2.blend
(2.55 MiB) Downloaded 128 times
It seems the issue is with smaller sized regions, bigger sized or no region rendering seem to work. But I'm not sure, might be somewhat random
kintuX
Posts: 809
Joined: Wed Jan 10, 2018 2:37 am

Re: Env. Light Visibility Cache

Post by kintuX »

lacilaci wrote: Tue Jul 23, 2019 9:46 am Another issue I'm getting is when rendering region. It's very random it seems.
Sometimes when I do region rendering with env.cache on I get this:
regionRender_envcache.jpg

I think I managed to isolate the region+envcache problem

If you try render this saved file it should eat up ram for quite a while and then throw the error about framebuffer
279_luxcore_regionBug2.blend

It seems the issue is with smaller sized regions, bigger sized or no region rendering seem to work. But I'm not sure, might be somewhat random
Looks like Map gets too big to fit, for such small area or something alike, relative wise, IDK ;)
but
Yes, works with larger "border" (image size)
and also the other way, smaller "border" works when you minimize the cache Map size (ie. min. size of 16, renders fine & fast!!!)

The one who seek problems will always find at least one ;)
meaning, i wouldn't consider this case an issue, but just a corner case, when things are most likely to go wrong... move camera to 0,0,0 and give another cube 100km wide just to be sure to crash it... and experiment further - the more you know :D
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

kintuX wrote: Tue Jul 23, 2019 7:41 pm
lacilaci wrote: Tue Jul 23, 2019 9:46 am Another issue I'm getting is when rendering region. It's very random it seems.
Sometimes when I do region rendering with env.cache on I get this:
regionRender_envcache.jpg

I think I managed to isolate the region+envcache problem

If you try render this saved file it should eat up ram for quite a while and then throw the error about framebuffer
279_luxcore_regionBug2.blend

It seems the issue is with smaller sized regions, bigger sized or no region rendering seem to work. But I'm not sure, might be somewhat random
Looks like Map gets too big to fit, for such small area or something alike, relative wise, IDK ;)
but
Yes, works with larger "border" (image size)
and also the other way, smaller "border" works when you minimize the cache Map size (ie. min. size of 16, renders fine & fast!!!)

The one who seek problems will always find at least one ;)
meaning, i wouldn't consider this case an issue, but just a corner case, when things are most likely to go wrong... move camera to 0,0,0 and give another cube 100km wide just to be sure to crash it... and experiment further - the more you know :D
I'm not so sure I would call region rendering a corner case. Especially when I ran into this issue 2x in ~5 minutes.

Latest build locks up my pc completely when I add glass material to testscene (PathOCL) have to restart PC.(witch env.cache enabled)
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 »

lacilaci wrote: Tue Jul 23, 2019 9:46 am Another issue I'm getting is when rendering region. It's very random it seems.
Sometimes when I do region rendering with env.cache on I get this:
This is was a general problem of automatic best radius evaluation affecting PhotonGI, ELVC and DLSC. The radius was seek as a percentage of image resolution. With border rendering, the radius was becoming smaller as the region to render was becoming smaller too.
I modified the code so estimated radius is not affected anymore by border rendering.
Support LuxCoreRender project with salts and bounties
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. »

Dade wrote: Wed Jul 24, 2019 8:14 am
lacilaci wrote: Tue Jul 23, 2019 9:46 am Another issue I'm getting is when rendering region. It's very random it seems.
Sometimes when I do region rendering with env.cache on I get this:
This is was a general problem of automatic best radius evaluation affecting PhotonGI, ELVC and DLSC. The radius was seek as a percentage of image resolution. With border rendering, the radius was becoming smaller as the region to render was becoming smaller too.
I modified the code so estimated radius is not affected anymore by border rendering.
Unfortunately this doesn't help in our Blender addon, because we don't use film.subregion there (instead we use the screenwindow).
If I remember correctly, the reason is that film.subregion returns the full film size and the areas outside the border are filled with black, but for Blender we need only the cropped border area.
Can you add an option to film.subregion to only return the cropped area without black around it?
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: Wed Jul 24, 2019 8:24 am Unfortunately this doesn't help in our Blender addon, because we don't use film.subregion there (instead we use the screenwindow).
This can be a problem in many situations because, at that point, LuxCore doesn't know the original image resolution. It can potentially disrupt any screen space related operation.
B.Y.O.B. wrote: Wed Jul 24, 2019 8:24 am Blender we need only the cropped border area.
Can you add an option to film.subregion to only return the cropped area without black around it?
The only solution, I can think to, is a dedicated helper C++ function in pyluxcore do read the original buffer and fills a temporary buffer with only the cropped border area :?:
Support LuxCoreRender project with salts and bounties
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. »

Dade wrote: Wed Jul 24, 2019 9:09 am The only solution, I can think to, is a dedicated helper C++ function in pyluxcore do read the original buffer and fills a temporary buffer with only the cropped border area
So LuxCore internally uses the full resolution for its framebuffers when using subregion? Isn't that kind of wasteful?
If it's too much of a hassle to change that, sure, a helper function is fine. But the RAM usage will obviously increase compared to the current approach.
Dade wrote: Wed Jul 24, 2019 9:09 am This can be a problem in many situations because, at that point, LuxCore doesn't know the original image resolution. It can potentially disrupt any screen space related operation.
We could also add an additional property that tells LuxCore what the full filmsize would be, even when using screenwindow for cropping (and potentially also the coordinates of the cropped area, in case that's important in the future).
Post Reply