[Feature Request] Line-Sweep SSAO

[kkimdev]

Feature Request

• Feature description: Line-Sweep SSAO
• Additional links that could help implementing the feature: http://wili.cc/research/lsao/

Line-Sweep Ambient Obscurance is relatively recent(2013) SSAO algorithm. Instead of sampling for each pixel, it sweeps lines in multiple directions and combines later so it's very GPU-pipeline friendly, leading to multiple factor performance boost. Here is the benchmark table from their slide:

I think it will be great to have it in BabylonJS.

Disclaimer: I haven't tried myself and I'm not aware of potential pitfalls of this technique. Though the paper won the best student paper award at EGSR-2013 and they have a reference implementation at the webpage so seems credible though.

[sebavan]

It looks pretty neat but might require not be as simple to integrate. I ll check with @deltakosh after his vacations how we could try to plan it.

[sebavan]

I am moving the evaluation to the roadpMap and closing the issue as long as it is not fully validated for the integration: https://github.com/BabylonJS/Babylon.js/projects/8

[kkimdev]

Thanks!

[kkimdev]

@ville FYI (the author)

[sebavan]

Thanks, really good to know.

[wilicc]

Hi all!
This is indeed a legit SSAO and when implemented properly it beats--to the best of my knowledge--other SSAO solutions out there. It scales very nicely to higher resolutions and the AO effect can span the entire width of the screen without any extra cost. Out of all game engines today, I think Remedy's Northlight is the only one using it (implemented by me, see http://wili.cc/research/quantum_break/). Note that the implementation given in the paper will not be much better than your standard highly optimized SSAO, but if you take tips from the SIGGRAPH presentation linked above and optimize it further, it starts to work.
Now the caveat: This is much much more difficult to implement than your standard SSAO algorithm. Many have tried and not many succeeded. Especially, there are several performance pitfalls as you're executing one thread per line, and not per pixel. Allocating the convex hull efficiently in groupshared memory requires careful profiling and some heuristics to keep the number of hull points in control. Organizing the work into cache-coherent batches requires a CPU pre-pass (executed once per resolution change), which also adds to the effort. You need to couple it with a one-step near field search at the gather phase, and "separable approximation of ambient occlusion" (SAAO) technique is also needed in the mix. (The latter 2 points are mentioned in the SIGGRAPH paper).
I don't want to discourage you from implementing this (as I have seen its benefits), but you have to allocate more resources into implementing this than you probably would initially guess :-)
(Also, note that the sample code that came with the paper is for Linux and implemented in CUDA/OpenCL, so you have to rewrite it.)

BR,
author of LSAO

[sebavan]

@wilicc w000t it looks like we would need to rely on tesselation and hull shader (from your reply, I did not find time to go through the pdf so far) which are not available on Webgl.

Could you confirm that it is the case ? as if it is we would probably stop there due to the lack of support of those in both Webgl and Webgl2. We might still find other tricks to do it but I am not sure it would then be worth the investigation.

[wilicc]

@sebavan No no, the "convex hull" is a different concept in LSAO :-) Nothing to do with the tessellation/hull pipeline stages. You need compute shader support though, that is mandatory.

[sebavan]

Thanks for your rapid answer :-)

Compute Shader are still not existing in Webgl, the best we can do would be to render to texture and then sample from it or rely on transform feedback.

@wilicc do you think this could be efficient enough with your use case ? (I am totally not sure without having a deeper look in the pdf)

[wilicc]

Unfortunately that will kill the performance. My honest suggestion is to put this algorithm on the back-burner and come back to it once you have compute shaders :-)

[sebavan]

Ok, thanks a lot !!! this will save us a lot of time ;-) and we ll definitely come back to it as soon as we ll have compute shaders.