What is map width, is it a size or resolution? Max width on longest edge or?.. If yes, maybe map resolution or size would make more sense I guess..
Is this cache for cpu only now? Opencl can't use it? I did only a quicktest cause I have to go now, but it looks really good in terms of performance, well definitely much faster than old vismap
Env. Light Visibility Cache
Re: Env. Light Visibility Cache
Going to check, I have probably missed something when added constantinfinite code (i.e. it just not possible to be worse than normal infinitelight).
Re: Env. Light Visibility Cache
It is "width x height" and it should be with 2:1 ratio (360 Vs. 180 degree).
I have yet to write the OpenCL code, it is not trivial but there aren't unknown problems to solve so it should work well.
Re: Env. Light Visibility Cache
It's the map width of each entry, the height is automatically computed from it (just width divided by 2).
Yes, I maybe I should rename it to "map size" in the UI.
I'll also add tooltips later.
Re: Env. Light Visibility Cache
How hard memory is affected by this features ?It looks like the cache doesn't work yet with constantinfinite lights (without HDRI)?
(30 sample renders)
Re: Env. Light Visibility Cache
In some quicktest I've seen ~150-200 MB increase in ram usage. In complex scenes it can probably go higher, which isn't problem for cpu ram since we can have plenty there, but for gpus that go up to 8GB in mainstream range it can matter.
I have also noticed that visibility map can even affect a render in bad way!
If you're doing some sort of product viz that is mostly visible only to HDRI (not in an interior) then it is best to disable visibility map completely
In interior "none" setting for visibility map is worst, then default old way helps a bit and cache seems to be best so far
However in some product vis no vismap is best, default introduces some noise and cache is worst!
So clearly visibility map can also do some damage, same as wrong usage of portals in other renderers!
I have also noticed that visibility map can even affect a render in bad way!
If you're doing some sort of product viz that is mostly visible only to HDRI (not in an interior) then it is best to disable visibility map completely
In interior "none" setting for visibility map is worst, then default old way helps a bit and cache seems to be best so far
However in some product vis no vismap is best, default introduces some noise and cache is worst!
So clearly visibility map can also do some damage, same as wrong usage of portals in other renderers!
Re: Env. Light Visibility Cache
There is also another issue I'm seeing with both vismap cache and photongi cache.
If I do render region/border in blender then it takes ages to start rendering. I think it is related to automatic size of cache, because in photongi if I disable automatic size of cache then startup for rendering goes back to normal! Vismap has the same issue I guess there is some automatic size being decided as well.
If I do render region/border in blender then it takes ages to start rendering. I think it is related to automatic size of cache, because in photongi if I disable automatic size of cache then startup for rendering goes back to normal! Vismap has the same issue I guess there is some automatic size being decided as well.
Re: Env. Light Visibility Cache
Here's some of my amateur opninions about mapping and caching visibility.
no mapping: cache: this won't go away unless I'm waiting until the worst area cleans and denoiser might afterwards still pick up the area as pattern and decide not to denoise that. These random artifact can also be near invisible to a later point of rendering where it might be too late to re-render but they would still be picked up by denoiser and the whole render is fucked up at this point. This is a very scary situation for me I would not dare risk that!!
Even normal/default vismap can create a random area of different noise level (not visible by eye) that oidn will pick up and just decide it won't denoise it! The reason I think this, is that this has happened 2-3 times for me so far, so it's a rare situation but only disabling visibility map or slightly changing something in scene so that I get different vismap would help! Although rare situation it can be super annoying when it happens!
By the way raising viscachemap size to 512 lead to 20min preprocessing, so I lost my nerve and killed blender(I think the main issue is region rendering doing something weird to luxcore).
Even if it would help, it is a painful trial and error method that puts a lot of additional work time on the user to troubleshoot a renderer issue that already has a solution in other renderers!
Here's another case I was mentioning. A product or object only lit by hdri! Visibility map is on by default so nobody would consider this a problem, even I did some 5K renderings not knowing I could get them done faster until I tried experimenting with vismap on/off yesterday!
no visibility map: default map: cache: So I say, we need portals and abandon the whole vismap/caching method. People already know the caveats of using portals wrong, it's a pretty much a standard way of dealing with interiors and there is no time spent with setting up resolutions and sampling and then praying it will work.
At this point I rather take no vismap and render for ages than risking something breaks after an hour of rendering.
So Dade please, unless you're 100% sure you can solve this in a way that will always work without any risks or problems or endless testrenders with different settings, just save yourself the time and go with the oldschool method of portals.
It's just my opinion and I know it's early as this just got into luxcore, but I rather say it now since I don't see a happy ending for this cache
no mapping: cache: this won't go away unless I'm waiting until the worst area cleans and denoiser might afterwards still pick up the area as pattern and decide not to denoise that. These random artifact can also be near invisible to a later point of rendering where it might be too late to re-render but they would still be picked up by denoiser and the whole render is fucked up at this point. This is a very scary situation for me I would not dare risk that!!
Even normal/default vismap can create a random area of different noise level (not visible by eye) that oidn will pick up and just decide it won't denoise it! The reason I think this, is that this has happened 2-3 times for me so far, so it's a rare situation but only disabling visibility map or slightly changing something in scene so that I get different vismap would help! Although rare situation it can be super annoying when it happens!
By the way raising viscachemap size to 512 lead to 20min preprocessing, so I lost my nerve and killed blender(I think the main issue is region rendering doing something weird to luxcore).
Even if it would help, it is a painful trial and error method that puts a lot of additional work time on the user to troubleshoot a renderer issue that already has a solution in other renderers!
Here's another case I was mentioning. A product or object only lit by hdri! Visibility map is on by default so nobody would consider this a problem, even I did some 5K renderings not knowing I could get them done faster until I tried experimenting with vismap on/off yesterday!
no visibility map: default map: cache: So I say, we need portals and abandon the whole vismap/caching method. People already know the caveats of using portals wrong, it's a pretty much a standard way of dealing with interiors and there is no time spent with setting up resolutions and sampling and then praying it will work.
At this point I rather take no vismap and render for ages than risking something breaks after an hour of rendering.
So Dade please, unless you're 100% sure you can solve this in a way that will always work without any risks or problems or endless testrenders with different settings, just save yourself the time and go with the oldschool method of portals.
It's just my opinion and I know it's early as this just got into luxcore, but I rather say it now since I don't see a happy ending for this cache
Re: Env. Light Visibility Cache
Camera Obscura with "Piazza San Marco" 4K, Halt time: 150 sec (tonemapping: contrast enhanced),
BiDir PT PT + PGI PT + PGI / Env. Visibility Map Width: 512
BiDir PT PT + PGI PT + PGI / Env. Visibility Map Width: 512
Re: Env. Light Visibility Cache
I don't manage the Dade time so it's just an opinion like others.lacilaci wrote: ↑Wed May 29, 2019 6:09 am ...
So I say, we need portals and abandon the whole vismap/caching method. People already know the caveats of using portals wrong, it's a pretty much a standard way of dealing with interiors and there is no time spent with setting up resolutions and sampling and then praying it will work.
...
I think that eliminate portals will be a good solution looking to the future.
Vray eliminates the need of in the last releases developing adaptive solutions.
I think it's great cause it reduces the scene management and setting.
Sure, and "Captain Obvious mode ON", if we should use a semi-working solution it's better to stay with "old school" portals.
It's "just" a Dade matter in terms of feeling to do the right thing cause he sees a bright future on this method.
Let's see where will be.