Env. Light Visibility Cache

Discussion related to the LuxCore functionality, implementations and API.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

I see, so the problem here is that we have an original solution, but it is yet to become optimized. That is great actually! I'm ok with things being slow now with the prospect of becoming faster in the future. Maybe an excelent task for new developers that might want to help out...

Oh man, this renderer really needs an influx of new users and potential developers. It's come a looong way
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: Env. Light Visibility Cache

Post by epilectrolytics »

lacilaci wrote: Tue Aug 06, 2019 1:34 pm So the main question is... can this be done faster?
I guess all cache building starts with a visibility pass?
Maybe in case of PGI and ELVC the same first pass could be used for both to save time (combined building of separate caches)?
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 »

epilectrolytics wrote: Tue Aug 06, 2019 4:15 pm
lacilaci wrote: Tue Aug 06, 2019 1:34 pm So the main question is... can this be done faster?
I guess all cache building starts with a visibility pass?
Maybe in case of PGI and ELVC the same first pass could be used for both to save time (combined building of separate caches)?
Yes, that is another option (not only for visibility), if everything is integrated together, you can build all the caches in a single pass.
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

This is soo frustrating, I keep running out of memory... Also the performacne in some scenes is pretty bad...
Working on a testscene to post

I'm also still running into artifacting problems:
artifacting.jpg
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

It also appears that the lower the clamping the worse the artifacting is and then the map resolution has to be raised.

You can run into pretty bad situation with this, where if you run out of vram and lower the visibility map resolution then you might see artifacts due to clamping, so you might need to additionally raise clamping.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Env. Light Visibility Cache

Post by lacilaci »

so I finally managed to create the scene for reproducing memory issues...

Basicaly it doesn't matter how big the scene is, it always happens when you want to make a close-up shot on an object in a bigger scene/environment.

here's the scene:
testscene_closeup.rar
Sometimes it helps to tweak the parameters(map resolution) in other cases it worn't help and it can even introduce artifacts if clamping is used.

I would sum up my experience with this feature like this:

Pros:
1. Automatic (almost)

2. Performance boost - in an ideal condition it will perform just as good as portals. (fewer openings, not too many objects in a scene and no close ups and no border rendering on previews)

Cons:
1. None of my production scenes fit the "ideal conditions" and I doubt anyone who would use luxcore for professional use would have a smooth experince with this feature.

2. It's painfully slow and makes previewing complex interior renderings impossible - many times I wait longer on preprocess than on the preview render itself

3. It's unpredictable. I don't know if I'll have enough memory until I do rendering, then if I run out of memory it takes forever for luxcore to figure out it won't fit into vram and then I can try lowering resolution and hope that I will see some rendering done.

4. It's unreliable, in some cases I can get clean and fast rendering using pretty low clamping values, however artifacts from this cache might creep in
renderings and sometimes they are so subtle that I might only notice them a good amount of time in rendering.

5. It's not really an automatic solution, it cannot be used all the time as it will damage performance in open scenes (now you might think, ok but why would you use it in an open scene? Well 3 times already I worked with an interior that had so many openings that this cache was pretty much useless and only added to rendertime with preprocessing)

So all in all, when it works it works well, but I have no time figuring out if it will work and how well it will work during a project.
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 »

First thing your scene is load of normal issues and unclean geometry. Not the kind of thing i like to throw in luxcore mouth :?
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: Tue Aug 13, 2019 12:30 pm First thing your scene is load of normal issues and unclean geometry. Not the kind of thing i like to throw in luxcore mouth :?
It's a cad converted mesh, but the problem happens even with normal objects. The problem is not related to scene objects
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 »

It's a cad converted mesh, but the problem happens even with normal objects. The problem is not related to scene objects
if you can reproduce the issue on a cleanner small scene i will give it a try. In this way we eliminate anything that can add bias to the test.
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
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 Aug 13, 2019 11:53 am so I finally managed to create the scene for reproducing memory issues...

Basicaly it doesn't matter how big the scene is, it always happens when you want to make a close-up shot on an object in a bigger scene/environment.
LuxCore can not know your intentions, so it has no way to know if it is a pre-view or a final render, if it is a close up of a whole image, etc.

I have the feeling you are using caches for pre-views and they are not the right tool by definition: a cache is trade off between pre-processing time and rendering time (increase the first to reduce a LOT the second) however, for a pre-view, you want the smallest possible pre-processing time. This is the reason why LuxCore real-time render engines disable all caches.

The work around to your problem is to specify by hand all caches look up radius and to have, in general, 2 sets of parameters: one for pre-views and one for final rendering. You must use a large radius if you want a fast pre-processing (like for pre-view).

You can optimize other parameters but the radius is the main and most important setting: if you double the radius you increase the number of cache entries by 4 (i.e. increase the pre-processing time by 4). Just set the radius by hand and use a 4x the value for pre-views.

This is applicable to all caches: DLSC, ELVC and PhotonGI.
Support LuxCoreRender project with salts and bounties
Post Reply