Show your work, get help, participate in development
http://forums.luxcorerender.org/
Direct light sampling is done for each path vertex so after the first bounce, it contributes to indirect lighting too (here and in PhotonGI).epilectrolytics wrote: ↑Tue Oct 15, 2019 10:51 am It sounds like this does not only help with direct light like ELVC but indirect light also?
Would this work with BiDir(VM) too?
(Looks like a simple way of path guiding (MIS) to me.)
Maybe you understand there is further puzzleDade wrote: ↑Mon Oct 14, 2019 11:13 pmHowever the good news is this paper has the piece of the puzzle I was missing for ELVC: the last step. I'm using an env. light visibility map (i.e. a pixel image). ...
I sample the tile according the usual light intensity (i.e. classic importance sampling), I can use visibility maps that are a loooot smaller and so also a loooot faster to build.
Now, it is optimal: ...
I ... need ... to ... write this code ....
for an additional performing boost, at least according to my thought experiments.Clarisse IFX Rendering improvements: Fireflies Filtering
Some information from Sam:
The attribute is called Fireflies Filtering, this new solution works all the time even on LPEs. It removes 1st generation fireflies and other generation too.
Which means that we will remove clamping: it gives results that are far beyond clamping while minimizing the loss of energy. More importantly the more sample, the more it converges to the ideal result. It can also reduce considerably noise (albeit loosing some energy). The great thing is that it always gives results that are way better than clamping and is only applied when detecting problematic path. Which means that it has no effect whatsoever on general paths that are "easy" to sample unlike clamping. It's the best solution to the problem, plus no render hit. Not planned for the next SP.
eagerly awaiting further news 
Hhm.
Well, sometimes you need a simple mind to get a simple solution. Smart people care about complex questions, they see the horizon but not the fruits in bushes along their way.
Is last Build contain this improvement ?Dade wrote: ↑Mon Oct 14, 2019 11:13 pmOhoh, their solution, when compare to LuxCore Env. Light Visibility Cache, is a classic trade off between memory usage and quality: ELVC requires a LOT more memory/pre-processing to works well but it deliver better results (if you use enough memory/pre-processing). Otherwise the 2 solutions are quite similar.
However the good news is this paper has the piece of the puzzle I was missing for ELVC: the last step. I'm using an env. light visibility map (i.e. a pixel image). The ELVC problem is you need very high resolution maps to work well. This cost both a LOT of memory and pre-processing time: more pixels, more shadow rays to trace.
This is 1 level hierarchy solution. If I use 2 levels hierarchy where one map pixel point to an env. light tile and I sample the tile according the usual light intensity (i.e. classic importance sampling), I can use visibility maps that are a loooot smaller and so also a loooot faster to build.
Now, it is optimal:
- one visibility map pixel => one HDR pixel
While, for instance, with tiles:
- one visibility map pixel => one HDR 8x8 tile (64 times less pixels to stores and 64 times faster pre-processing !!!!!!) => a HDR tile pixel picked according importance sampling
I ... need ... to ... write this code ....
