gave it a quick try and everything seem to work much better, I'll do some more proper testing sometime after weekend.
About that memory problem, it indeed looks like the same issue as with border rendering (memory leak?)
Automatic radius for PGI also has similar issue but rather than running out of memory it tends to just be much slower with border rendering.
I'll try to make a small testscene for this but probably not sooner than sometimes next week
Env. Light Visibility Cache
Re: Env. Light Visibility Cache
I have the same problem, periodic crashes are very annoying, despite the fact that the scenes are not the most difficult.
Actualy sorry for my google translate english :)
Re: Env. Light Visibility Cache
Please, bring it back (or portals).
At least until there's something else to replace it for interior animations.
It was best solution in my interior test animations. Only Light Trace caustics were flickering.
Re: Env. Light Visibility Cache
After several exteriors and interiors testings, I think this is an excelent solution. Except one thing!!!
Computing time... This is crazy slow in complex scenes... You literally cannot do testrenderings with env.cache cause it's incredibly slow to copute...
I think, the fact we don't have to manually define portal entries is great but really, caches on top of caches add time a LOT!.
So the main question is... can this be done faster? if env. cache could be done in miliseconds, that would be superior to all other solutions.
Computing time... This is crazy slow in complex scenes... You literally cannot do testrenderings with env.cache cause it's incredibly slow to copute...
I think, the fact we don't have to manually define portal entries is great but really, caches on top of caches add time a LOT!.
So the main question is... can this be done faster? if env. cache could be done in miliseconds, that would be superior to all other solutions.
Re: Env. Light Visibility Cache
Don't know if this is possible but it is too great to be even thinkable. BTW what is your CPU spec. the more powerfull core you have better it is.So the main question is... can this be done faster? if env. cache could be done in miliseconds, that would be superior to all other solutions.
Edit :
Will be fucking good to have it arroun 5scs or 10sc max
Wonder how VRAY and CORONA deal with that.
Re: Env. Light Visibility Cache
I'm using ryzen 2700 now and rtx2070Sharlybg wrote: ↑Tue Aug 06, 2019 1:51 pmDon't know if this is possible but it is too great to be even thinkable. BTW what is your CPU spec. the more powerfull core you have better it is.So the main question is... can this be done faster? if env. cache could be done in miliseconds, that would be superior to all other solutions.
Edit :
Will be fucking good to have it arroun 5scs or 10sc max
Wonder how VRAY and CORONA deal with that.
corona takes no time for this almost.. it's super fast.
To clarify, I don't mind a little longer preprocessing time to render some neat caustics... But right now we cannot render sds caustics effectively.
The problem is that combined: photonGI + env. vis. cache + caustic cache can take a LOT of pre-processing time and then you still might find out that it is looking terrible, so you have to setup and render again...
Re: Env. Light Visibility Cache
Uh ? Why can not you use the new Env. Light Visibility Cache ?
Re: Env. Light Visibility Cache
May be, one of the many possibility would be to use Embree support for tracing multiple rays in parallel with SSE/AVX/AVX2, it could reduce the pre-processing time by 4-5 times on an AVX2 capable CPU (with a packet of 8 rays traced at the same time).
However, as you have probably already noticed, stuff improves over time (aka "Rome wasn't built in a day").
Side note: this kind of stuff is also "original" as far as I know, it has never been done before. Doing R&D, development, debugging, etc. with our resources (i.e. none) requires a bit of time
Re: Env. Light Visibility Cache
What about doing it on the GPU?