Env. Light Visibility Cache

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

[Sharlybg]

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.

[lacilaci]

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.

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

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 234 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]

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

[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

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

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)

[Dade]

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.

[B.Y.O.B.]

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?

[Dade]

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.

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

[B.Y.O.B.]

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.

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