Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement ASSAO #245

Closed
marcofugaro opened this issue Dec 23, 2020 · 5 comments
Closed

Implement ASSAO #245

marcofugaro opened this issue Dec 23, 2020 · 5 comments
Labels
feature request New feature request

Comments

@marcofugaro
Copy link
Member

marcofugaro commented Dec 23, 2020

Godot just implemented a better screen space AO technique, would be awesome having it also in three.js, if the performance is acceptable.

godotengine/godot#44182

BTW thanks for keeping this repo maintained! It is much better than the default EffectComposer in three!

@marcofugaro marcofugaro added the feature request New feature request label Dec 23, 2020
@vanruesc
Copy link
Member

vanruesc commented Jan 3, 2021

Three doesn't support MRT yet, so we can't simultaneously render the AO, edges and weights out. We can also not render the actual scene normals, including those from normalmaps, in our geometry pass due to the lack of MRT and limited extensibility of built-in materials. We need NodeMaterial or a similar, more flexible material system for that. This is due to the fact that the override material system doesn't allow individual objects to use their various object-specific maps. This can be solved entirely by MRT.

The current SSAO implementation in this library is efficient, scalable and depth-aware. It still lacks bilateral blurring but that's on my todo list. I'm not sure if ASSAO would actually be a substantial improvement over what we have right now. The adaptive sampling kernel of ASSAO looks interesting, though.

@gkjohnson Do you happen to know if ASSAO is better than GTAO? I'd assume that you can't improve on ground truth.

@marcofugaro
Copy link
Member Author

This can be solved entirely by MRT.

Yeah, there is a PR for it though: mrdoob/three.js#16390

@gkjohnson
Copy link

@vanruesc

Three doesn't support MRT yet, so we can't simultaneously render the AO, edges and weights out.

I'm not sure if that shader is using MRT? It looks like it's just writing out to the X and Y fields of the target buffer and the AO could probably just be composited with the final frame right there if needed. But it does look like it needs normals and depth which would be nice to render with MRT generally.

We need NodeMaterial or a similar, more flexible material system for that. This is due to the fact that the override material system doesn't allow individual objects to use their various object-specific maps. This can be solved entirely by MRT.

I agree the current material system is really limiting for effects like this. I'm really hoping that Node materials will make creating override materials based on other materials shaders and uniforms much easier.

Yeah, there is a PR for it though: mrdoob/three.js#16390

I was really hoping to see that PR land at some point but after almost two years it's not really clear what the plan is :/ It's one of the biggest features I was looking forward to with WebGL2

@gkjohnson Do you happen to know if ASSAO is better than GTAO? I'd assume that you can't improve on ground truth.

I don't know much about ASSAO but from looking around it looks like they're both based on HBAO (siggraph slides, white paper). I'd assume these would all be slower than what's being done now but of course you'd probably see a quality improvement of some kind. I believe HBAO generally needs more samples to look good in order to find the horizon angles in multiple directions but I haven't done a lot of work in this area outside of that GTAO implementation myself. Perhaps there are some things that can be taken from the implementation that could improve quality? Still won't get texture normals, though which might be one of the biggest improvements.

@vanruesc
Copy link
Member

vanruesc commented Jan 4, 2021

It looks like it's just writing out to the X and Y fields of the target buffer

Oh, you're right! I should've looked closer.

Perhaps there are some things that can be taken from the implementation that could improve quality?

Thanks for checking. I also think it would be best to improve the SSAOEffect step by step, if possible. The planned blur feature comes first. Then I'll look into alternative sampling kernels.

@vanruesc vanruesc mentioned this issue Feb 13, 2024
3 tasks
@vanruesc
Copy link
Member

Closing in favor of #573.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature request
Projects
None yet
Development

No branches or pull requests

3 participants