Env. Light Visibility Cache

[Dade]

So LuxCore internally uses the full resolution for its framebuffers when using subregion? Isn't that kind of wasteful?

It was done to match old LuxRender behavior and it is handy to merge multiple renders of different cropped regions (i.e. you have only to sum all the different renderings).

If it's too much of a hassle to change

It is, it would affect hundreds of places and it would be an endless source of bugs.

[B.Y.O.B.]

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

What do you think about this idea?

Just using film.subregion would mean that users couldn't render very high resolution images anymore by splitting them into "big tiles" with border rendering.

[kintuX]

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)

Yes, I consider "in camera border rendering" a corner case, because I only had to resort to it once in my CGI career.
Latest build still works fine on my side. More explanation is needed, preferably separated, scene specific thread.

'libera temet ex inferis'
Add-on : Camera Cropper & Splitter & Set Render Border Add-on

Now, let's stay on the track, please.

[lacilaci]

Just for fun I tried to create an example which favors luxcore(env.cache)
And as I expected this is exactly the very basic setup that works.

All 1 minute rendering (exposure is again eyeballed and not too exact):

cycles+portals

luxcore+env.cache

This looks pretty much great for luxcore, cycles is maybe a little bit cleaner but it's very close and luxcore didn't need to setup portal

Things however start to fall apart fast if even a small complexity is added, in form of knot instead of sphere:

cycles

luxcore

I think in this case it was more of an GI problem rather than env.cache.

and lastly (again just for fun) I added PGI to luxcore and the AO fake trick to cycles

cycles+AO

luxcore+PGI

In very limited cases I got away using this fake trick in cycles, however it tends to look ugly and if overdone it ruins the look of the image. PGI on other hand boosted the exposure quite a bit, not sure if it's the additional bounces or why it changes the lighitng.

PS: env.cache still crashes on bigger scenes so I can't test on any of my existing scenes.

[Dade]

Things however start to fall apart fast if even a small complexity is added, in form of knot instead of sphere:

It is a direct light cache for env. lights, where does it exactly fall apart ? It will affect only direct light and there is PGI for indirect light. Any test for ELVC should be done with direct light only renderings.

[Dade]

BTW, single-map mode is just a very special case of multi-map mode (i.e. it is about the same of using a very large radius with multi-map and still worse in many case) so it should be removed.

[lacilaci]

BTW, single-map mode is just a very special case of multi-map mode (i.e. it is about the same of using a very large radius with multi-map and still worse in many case) so it should be removed.

Did you find out why the new env.cache crashes?

[Dade]

What do you think about this idea?

Just using film.subregion would mean that users couldn't render very high resolution images anymore by splitting them into "big tiles" with border rendering.

As I wrote before, changing the meaning of Film width/height fields is not an option. They are used in more than 100 places across the code, from metropolis sampler, to image plugins, etc.:

It would require do check and update every single place where they are used and it is likely to introduce many bugs.

[Dade]

Did you find out why the new env.cache crashes?

It doesn't crash here. It may be the kind of "crash-only-on-Windows" problem or you may run out of memory due to some setting or mode of usage (like the border rendering problem).

But I can not say more without a test scene, a log, some way to reproduce the problem, more information, etc.

[lacilaci]

Welp...
I'll try to isolate the problem but it crashes with every single production scene I tried without any error and using only 8-15 GB ram out of 32

Also rendering region is pretty much useless now as it also crashes blender or throws an error about memory (after it fills it)

Also, why this happens?
cache

without cache

just hdri+object