Also, trying to use photonGI in a really heavy scene (exterior + ton of high poly trees) crashes blender with error:
EDIT: it was some issue with the scene, I've reimported trees in another copy of that scene and caching works just fine!
here's how the scene that crashes with photongi looks like (bidir+metro)
hmm.. there's probably some problem with the scene itself, not luxcore related.PhotonGI cache
Re: PhotonGI cache
Last edited by lacilaci on Tue Feb 12, 2019 1:53 pm, edited 1 time in total.
-
- Donor
- Posts: 790
- Joined: Thu Oct 04, 2018 6:06 am
Re: PhotonGI cache
The last version is a large step forward.
Everything is faster and smoother and easier.
I wonder if the initial photoncount parameter could be dropped and instead photons are continuously shot until maxsize parameter is reached?
And in debug mode the rendering could be stopped after cache is complete and the image drawn.
I'm seeing the same light leak issues as lacilaci in my tests.
Everything is faster and smoother and easier.
I wonder if the initial photoncount parameter could be dropped and instead photons are continuously shot until maxsize parameter is reached?
And in debug mode the rendering could be stopped after cache is complete and the image drawn.
I'm seeing the same light leak issues as lacilaci in my tests.
Both new "usagethreshold" parameters are not exposed?
Re: PhotonGI cache
Probably depth could be default 8 and hidden (4 is too low for interior spaces and it shows a lot, same goes for diffuse and glossy rays for pathtracing)epilectrolytics wrote: ↑Tue Feb 12, 2019 12:51 pm The last version is a large step forward.
Everything is faster and smoother and easier.
I wonder if the initial photoncount parameter could be dropped and instead photons are continuously shot until maxsize parameter is reached?
And in debug mode the rendering could be stopped after cache is complete and the image drawn.
I'm seeing the same light leak issues as lacilaci in my tests.
Both new "usagethreshold" parameters are not exposed?
I wonder if lookup radius could be defaulted as well. From all my tests 20-30 cm would be enough but we now have those lightleaks.
As for photon count and cache size, I've noticed that with fixed lookup (for example 30cm) but higher values for photon count and cache size can give more precise looking result. Maybe there could be a way to estimate some sort of accuracy and have luxcore keep shooting and resizing cache until certain level of accuracy is reached? Is that technically possible?
Re: PhotonGI cache
comparison between
60mil cache + 60mil size - 10cm lookup 10mil cache + 10mil size - 10cm lookup
60mil cache + 60mil size - 10cm lookup 10mil cache + 10mil size - 10cm lookup
Re: PhotonGI cache
I tried to apply the same idea to caustic cache but while it was a LOT faster, the quality of the output was too low to be really usable so I leave caustic cache as it is now. I will do only another test trying to filtering the caustic cache entries to smooth them and avoid the "point-iness" looking it can have sometime.
Re: PhotonGI cache
shame, I was hoping that this could produce reflective causticsDade wrote: ↑Tue Feb 12, 2019 5:17 pm I tried to apply the same idea to caustic cache but while it was a LOT faster, the quality of the output was too low to be really usable so I leave caustic cache as it is now. I will do only another test trying to filtering the caustic cache entries to smooth them and avoid the "point-iness" looking it can have sometime.
Re: PhotonGI cache
I have found a bug: Metal material was claiming to be "GLOSSY | REFLECT" and was misidentified as Glossy material by PhotonGI. This could lead to some problem.
The rendering now looks ok to me:
Your cache is also starving for more photons. Follow 3 rendering with 5, 25 and 250 millions of photons traced:
Tracing 250 millions of photons requires 100secs so it is not a totally insane setting and it gives you the idea of how much light you are missing in your rendering (and 25mils is already a lot better than your 5mils).
Re: PhotonGI cache
I'll try the fix.Dade wrote: ↑Tue Feb 12, 2019 11:35 pmI have found a bug: Metal material was claiming to be "GLOSSY | REFLECT" and was misidentified as Glossy material by PhotonGI. This could lead to some problem.
The rendering now looks ok to me:
render.jpg
Your cache is also starving for more photons. Follow 3 rendering with 5, 25 and 250 millions of photons traced:
5m.jpg
25m.jpg
250m.jpg
Tracing 250 millions of photons requires 100secs so it is not a totally insane setting and it gives you the idea of how much light you are missing in your rendering (and 25mils is already a lot better than your 5mils).
Also, regarding the lighting difference, I don't think it's about photons traced although that makes difference too.
I've seen pretty big differences in open space where it shouldn't be a problem with the number of photons.. Will post more tests
Re: PhotonGI cache
so, no... Amount of photons have some effect on brightness, but not even close to pathtracing.
Higher photon count helps with leaks (which are still present near corners!) but have only limited effect on brightness of GI
here's 250 000 000 photons with 250 000 000 cache size VS pathtracing. Notice that even top right corner which is very easily accessible for GI is still darker. and here's only 250 000 photons and cache size! Note that between 250mil and 250 thousand cache there is only a difference in color balance, but brightness is the same So my conclusion so far is, we don't need hundred of millions photons, we need more brightness, and while we can use more photons and larger lookup radius to combat leaks, there has to be something wrong cause they only appear near corners and are always brighter than samples further from the corner (Or maybe, they have correct brightness but the ones further from corners are wrong and too dark!)!
Another problem, I don't know what are the latest changes to materials (I've read on github material list fix so I assumed now all materials work)
But, now even my matte wall is not able to gather GI samples from sky (note that this scene contains only sky) EDIT: it actually does gather photon gi but it is very very dark, in older builds it wasn't that bad.
Higher photon count helps with leaks (which are still present near corners!) but have only limited effect on brightness of GI
here's 250 000 000 photons with 250 000 000 cache size VS pathtracing. Notice that even top right corner which is very easily accessible for GI is still darker. and here's only 250 000 photons and cache size! Note that between 250mil and 250 thousand cache there is only a difference in color balance, but brightness is the same So my conclusion so far is, we don't need hundred of millions photons, we need more brightness, and while we can use more photons and larger lookup radius to combat leaks, there has to be something wrong cause they only appear near corners and are always brighter than samples further from the corner (Or maybe, they have correct brightness but the ones further from corners are wrong and too dark!)!
Another problem, I don't know what are the latest changes to materials (I've read on github material list fix so I assumed now all materials work)
But, now even my matte wall is not able to gather GI samples from sky (note that this scene contains only sky) EDIT: it actually does gather photon gi but it is very very dark, in older builds it wasn't that bad.
Re: PhotonGI cache
Nothing has changed, cache entries are still created only on matte and glossy material (due to a now fixed bug, before they were created on metal material too).
This was the result of a typo, causing the lookup radius parameter being used instead of the lookup normal threshold parameter. This was stopping PhotonGI from creating entries on some or even all surfaces. I should have fixed this problem.