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.
Env. Light Visibility Cache
Re: Env. Light Visibility Cache
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.
Re: Env. Light Visibility Cache
I was talking about environment visibility cache not direct light cache (although that one has problems too)Sharlybg wrote: ↑Mon Jul 22, 2019 4:26 pmi 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.
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.
Re: Env. Light Visibility Cache
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 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
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 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
Re: Env. Light Visibility Cache
Looks like Map gets too big to fit, for such small area or something alike, relative wise, IDKlacilaci 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
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
Re: Env. Light Visibility Cache
I'm not so sure I would call region rendering a corner case. Especially when I ran into this issue 2x in ~5 minutes.kintuX wrote: ↑Tue Jul 23, 2019 7:41 pmLooks like Map gets too big to fit, for such small area or something alike, relative wise, IDKlacilaci 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
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
Latest build locks up my pc completely when I add glass material to testscene (PathOCL) have to restart PC.(witch env.cache enabled)
Re: Env. Light Visibility Cache
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.
Re: Env. Light Visibility Cache
Unfortunately this doesn't help in our Blender addon, because we don't use film.subregion there (instead we use the screenwindow).Dade wrote: ↑Wed Jul 24, 2019 8:14 amThis 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.
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?
Re: Env. Light Visibility Cache
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.
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
Re: Env. Light Visibility Cache
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.
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).