Closed simongeilfus closed 9 years ago
I made you a branch: https://github.com/bantherewind/Cinder/tree/sao
There is a separate, full-screen SAO buffer with its own textures. There is a SAO pass with a mostly empty shader (I left some utilities in there for you). All you have to do is fill in sao.vert/sao.frag. The SAO pass is followed by a blur pass, just like SSAO. If you don't need a blur pass to follow, just delete those passes and I'll reduce the buffer to a single attachment. Otherwise, blur is on for you. :)
If you just want to send me the shaders and uniform values, that will do. No need to PR or gist.
Should we merge #803 first?
Yes. The sao branch stems from #803. After the new SAO is implemented, there will be one more PR on this where things are more batch-driven and drawn with instancing. Shouldn't really add complexity, but will be a nice performance boost.
Hey Steve! Sorry busy week here, I'll give it another try this weekend.
@simongeilfus Hey, I've fired this branch back up. https://github.com/bantherewind/Cinder/tree/sao
I'm working it so you can switch between HBAO and SAO. Might leave them both in there. Might just pick one. Probably SAO.
I know you're busy, but would you mind just taking a peek in there just to confirm I'm on the right path?
This is mostly implemented, but am hitting some blocks. Going to think out loud here, but also record this issue in the hope it's seen. ;)
I set up a new buffer (mFboCsz) which fills in mipmap levels for a texture (mTextureFboCsz). I calculate clip space Z from depth and write it to level 0 (mBatchSaoCszRect). Then I use McGuire's minify shader (adapted for GLSL 330) to fill in mipmap levels 1 - 4 (mBatchSaoMinRect). Then that is used to render the SAO shader into the AO buffer (the one I was using for HBAO) (mBatchSaoAoRect).
I think pretty much everything is right now except my CSZ pass. I even have the guard band and offsets in there. If I just pass through the depth image in the CSZ pass (no clip-space reconstruction), I see it making through the SAO chain onto the screen (including custom mipmap filtering). Using the math from the paper, my CSZ buffer some comes out white. The entire AO pipeline is just one channel. GL_R32F for the mipmapped texture and some other one channel float (depending on selected render quality) for the final buffer where the AO is rendered.
I feel like I may be missing something in either the data type for the CSZ buffer or in the clip and projection info I'm passing in to the CSZ and/or SAO shaders. I'm working from McGuire's sample and things look right. Hmmm...
Side note. I think it's best to be able to toggle between no AO, HBAO, and SAO. I think the purpose of this sample is to both educate what you can do on top of a deferred shading pipeline, but also borrow from it (ie, rendering technique grab bag). HBAO isn't as pretty or efficient as SAO, but it's dead simple to implement. It's the best looking version of the AO methods which only require one buffer and one shader, IMO. SAO is probably the best method, period, but between the mipmap setup and compensating for the guard band, it's not easily reusable for beginners.
I'll stop short of turning this into a tiled deferred renderer. ;)
I'll stop short of turning this into a tiled deferred renderer. ;)
Why? ;)
Hey Stephen, sorry for not be able to commit more time on this, I had a quick look at your mipmap issue and can't see anything wrong,... I'll double check this weekend and let you know if I find anything!
In the meantime here's the quick SAO I did the other day, it should work as it in the current glNext branch without touching too much at the c++ (if at all)... it's not the full sao with all the passes that you are trying to implement but it does work: https://gist.github.com/simongeilfus/54ac187bada4b420efd5 And here the unfinished bilateral blur (not working yet) : https://gist.github.com/simongeilfus/c42fe5eb1c9586492d64
Haha! Cross-posting!
Ha! I meant to say I'll stop short of turning this sample into a tiled deferred shading engine. I absolutely plan to make this tiled for my personal engine. :)
Thanks!
Hey Stephen, could you send me your email (mine is my firstnamelastname@gmail.com) ... I should really really show you what I'm working on atm...
Oh, awesome on the SAO blur. I'll make sure it uses that when the AO method is SAO.
Ah, I see... Check out the "presentation" link here: http://graphics.cs.williams.edu/papers/SAOHPG12/
SAO definitely looks better, but it can also perform way better than other methods with a little prep work. The paper (same link) goes into detail about an optimization which speeds up the process by a factor of seven. I think my failure is happening in the first pass which stores clip-space Z.
I'm glad I thought out loud here. I totally have it working! The CSZ pass needed some scaling in the clip info. Needs some cleanup and some scaling math, but it works. And it's super fast! At 2560x1440 with a GTX 680M, I get 52 fps with SAO vs 48 with HBAO. 58fps with no AO. That includes blurring.
Exiting! Can't wait to check this out....
In the meantime, as you seem to be crunching white papers at a really scary speed you might want to check this out next. IMO Temporal supersampling is probably the most exiting thing in recent papers. In the case of your SAO implementation, it would allow to do the AO at a much lower res and have it basically for free. (Same idea behind Epic crazy antialiasing),... definitely out of this sample scope but highly recommended to read about this technique.
(Btw the code I posted above is adapted from McGuire sources)
We can close this. HBAO and SAO are implemented.
Hey all, Glad those two samples got merged! Really nice work Steve.
If you don't mind me being a bit more picky, I was wondering if we could do better for the ambient occlusion pass! I had a quick look today and it seems a bit weird to me. Well actually it's a bit hard to see anything with the current geometry as there's really little places for the ao to get obvious. But if you add more overlapping meshes it get pretty clear that the ao pass doesn't add much. From what I can see the SSAO method you are using only creates some black outlines and darker (left) faces, it's probably also related to the parameters of the shader but I would propose to switch to a newer one.
Here's a few comparison between your algorithm and the one I'm using. It's called Scalable Ambient Obscurance and is IMO a huge improvement on most other SSAO methods; it scales pretty well and allow to have a much wider sample radius without performance penalties.
I added a few spheres and cubes to your scene, so we can see a bit more what's going on :
current SSAO: SAO:
current SSAO: SAO:
current SSAO: SAO:
current SSAO: SAO:
I'd be happy to send a PR for this but wanted to discuss a few things before. The sample would have to be a bit modified to be able to implement this properly. The above screenshots might look nice, but things are not that easy. The main issue is that this pass is happening at half the resolution. Which totally makes sense. The thing is because your SSAO is working at a really high frequency (small AO radius), blurring the small fbo is enough to blend properly with the rest of the shading, you probably won't see the low-res behind. You basically don't need any upscaling technique. On the other hand as soon as you raise the AO radius, compositing it with the rest will look totally wrong if not upscaled properly. Which means that if we switch to any AO method that is actually visible, we'll probably have to add one more full-res render target and another filtering/upscaling shader.
So in my opinion, we should probably or get rid of the AO pass and make the sample even simpler, or add a GlslProg and a Fbo and make it work nicely.
Let me know what you think.
Simon.