Proposed RFC Feature =GTAO (Ground-Truth based Ambient Occlusion)= about sig-graphics-audio HOT 11 CLOSED

Can you make your GTAO implementation into a Gem? Then you can easily submit it and iterate on it, potentially get others to collaborate on some of the missing pieces.

Of course, it couldn't take much effort to migrate the GTAO into an independent Gem. I think it's a good idea.

from sig-graphics-audio.

Looks really nice, definitely +1. This seems superior to the current SSAO in every way - are there any reasons long term to keep the old version around long term? Does GTAO require any features that may not exist on all of o3de's supported hardware? Are there any cases where the current SSAO performs better than GTAO?

from sig-graphics-audio.

Also curious how a low quality GTAO compares to current SSAO in performance and quality - for example, does a low quality GTAO still look better than SSAO and is also cheaper?

from sig-graphics-audio.

Looks really nice, definitely +1. This seems superior to the current SSAO in every way - are there any reasons long term to keep the old version around long term? Does GTAO require any features that may not exist on all of o3de's supported hardware? Are there any cases where the current SSAO performs better than GTAO?

Also curious how a low quality GTAO compares to current SSAO in performance and quality - for example, does a low quality GTAO still look better than SSAO and is also cheaper?

Thank you for your comments. There is no special request for GTAO, in fact, it is also a screen space algorithm like SSAO. We have 5 qualities to adjust for GTAO. We let users themselves make a trade-off between performance and quality. At a low-quality level, I think GTAO won't look much better than SSAO in the current version. As far as I know, there exist some obvious noises at a low-quality level. Of course, we hope the community could help us improve it.

As for performance, GATO actually performs slightly more costly than SSAO even at a low-quality level. I show you a simple performance comparison with SSAO and GTAO on my PC, FYI.

Platform:

• CPU: Intel i9 11900K @ 3.5GHz
• GPU: Nvidia Geforce RTX3090 (24GB)
• Mem: 64GB
• OS: Window 10
• Resolution: $1920\times1080$
• Test Scene: Sponza

SSAO:

GTAO (Low):

Though the current version is not as good as our expectations/goals. We sincerely hope the community could help us to improve it.

from sig-graphics-audio.

Thanks for the detail write up and all the hard work that went into implementing this!
However, the base assumption that GTAO is better than O3DE's SSAO is incorrect. It might be true for old implementations of SSAO, but O3DE uses a custom implementation that is both faster and higher quality than GTAO.

1. GTAO is based on HBAO, which is an older technique that assumes each pixel has an infinite wall behind it and tries to calculate the visibility angle. This is a poor assumption in practice, and leads to small geometry casting strong AO like the chains holding the light. It also creates a dark halo around objects because they case AO much futher behind them than they should, while simultaneously not casting enough AO in front of the object. For example, a pillar touching the ground should cast AO equally all around the pillar, but HBAO casts much more AO behind the pillar and not enough in front. O3DE's SSAO has none of these drawbacks.
2. GTAO adds cosine weighting to HBAO for more accurate results. O3DE's SSAO has cosine weighting as well (dot product in the sample accumulation), so both are equal in this regard.
3. O3DE's SSAO has a better weighting strategy that preserves detail better for more distant objects.
4. O3DE's SSAO does reveal low-res geometry because it calculates normals from the depth buffer (this is faster than writing out normals and then reading them in). This is the biggest drawback of the current implementation, but this can be mitigated by writing out interpolated vertex normals in the pre-depth pass (better quality but less performant) or using the normals from the G-Buffer (means SSAO would be forced to stay after the forward pass, which would limit flexibility. Having SSAO before forward is more flexible because per-material control can be added to reduce SSAO on softer objects like snow).
5. Based on the measurements you provide, the low end version of GTAO is almost double the cost of O3DE SSAO (0.108 vs 0.06ms)

Here is comparison using the images you provided:
GTAO

O3DE SSAO

from sig-graphics-audio.

Thanks for the writeup @antonmic. This makes it a lot clearer that there are pros and cons to each approach, and there are areas where the current SSAO is definitely superior - especially with regards to GTAO applying too much occlusion behind objects. It would be nice to see comparisons against a ray-traced ground truth so we could objectively compare the techniques.

from sig-graphics-audio.

Thanks for the detail write up and all the hard work that went into implementing this! However, the base assumption that GTAO is better than O3DE's SSAO is incorrect. It might be true for old implementations of SSAO, but O3DE uses a custom implementation that is both faster and higher quality than GTAO.

1. GTAO is based on HBAO, which is an older technique that assumes each pixel has an infinite wall behind it and tries to calculate the visibility angle. This is a poor assumption in practice, and leads to small geometry casting strong AO like the chains holding the light. It also creates a dark halo around objects because they case AO much futher behind them than they should, while simultaneously not casting enough AO in front of the object. For example, a pillar touching the ground should cast AO equally all around the pillar, but HBAO casts much more AO behind the pillar and not enough in front. O3DE's SSAO has none of these drawbacks.
2. GTAO adds cosine weighting to HBAO for more accurate results. O3DE's SSAO has cosine weighting as well (dot product in the sample accumulation), so both are equal in this regard.
3. O3DE's SSAO has a better weighting strategy that preserves detail better for more distant objects.
4. O3DE's SSAO does reveal low-res geometry because it calculates normals from the depth buffer (this is faster than writing out normals and then reading them in). This is the biggest drawback of the current implementation, but this can be mitigated by writing out interpolated vertex normals in the pre-depth pass (better quality but less performant) or using the normals from the G-Buffer (means SSAO would be forced to stay after the forward pass, which would limit flexibility. Having SSAO before forward is more flexible because per-material control can be added to reduce SSAO on softer objects like snow).
5. Based on the measurements you provide, the low end version of GTAO is almost double the cost of O3DE SSAO (0.108 vs 0.06ms)

Here is comparison using the images you provided: GTAO

O3DE SSAO

@antonmic Thanks for your detailed comments. Definitely, O3DE‘s SSAO has its own advantages in some cases. I agree with @invertednormal that there is no approach is perfect, especially in real-time rendering. Each approach has its own advantages and disadvantages because an algorithm is always based on some assumptions. If an assumption doesn't meet a scene, then the artifact occurs. In our opinion, we suggest keeping both approaches to let users make a choice. As far as I know, many modern engines have more than one kind of AO solution, for example, Unreal supports both SSAO and RTAO.

As for some drawbacks of the GTAO you mentioned, they are true of course. But I think there exist some techniques to relieve them, though we may didn't make it better yet, as a first version. For example:

• Strong AO for small geometrics
  This can be improved by thickness heuristics in horizon searching.
• Black hole or dark area
  This can be solved by considering multi-bounce. In our current version, we have fit a multi-bounce curve, but it may not be good enough. We could improve it by collecting more data in the future.
• Performance argument
  Indeed, the current version does have space to improve. Additional temporal denoising could help that.

Thanks for the writeup @antonmic. This makes it a lot clearer that there are pros and cons to each approach, and there are areas where the current SSAO is definitely superior - especially with regards to GTAO applying too much occlusion behind objects. It would be nice to see comparisons against a ray-traced ground truth so we could objectively compare the techniques.

@invertednormal I agree with that. I could provide more comparisons of GTAO and SSAO (including the O3DE's version and the UE's version). And I would further show the RTAO effects of both engines (we also developed RTAO for O3DE) as a reference, FYI.

• Scene1: Spaonza
  O3DE SSAO:
  
  O3DE GTAO:
  
  O3DE RTAO:
  
  UE SSAO:
  
  UE RTAO:
  

• Scene2: Simple Blocks
  O3DE SSAO:
  
  O3DE GTAO:
  
  O3DE RTAO:
  
  UE SSAO:
  
  UE RTAO:
  

BTW, I am not trying and do not intend to show how good the feature we provide is. Actually, there exist some problems in the current version as I mentioned before. All I can do is provide details as possible as I can. So that the community could have a better knowledge of the feature and make an adequate consideration that whether it is potential/proper for the community. If so, I think we could make it better together in the future.

from sig-graphics-audio.

Can you make your GTAO implementation into a Gem? Then you can easily submit it and iterate on it, potentially get others to collaborate on some of the missing pieces.

Also worth noting, some of the improvements you mentioned for GTAO can also be applied to O3DE's SSAO, like a multibounce curve and temporal super-sampling/accumulation. Depending on what you're aiming for this might give you the best results.

from sig-graphics-audio.

Approved as long as this feature comes from its own Gem, so the users of O3DE can pick from SSAO component or GTAO component.

from sig-graphics-audio.

Since this RFC is accepted please open a PR and move this RFC to this folder - https://github.com/o3de/sig-graphics-audio/tree/main/rfcs where we will track all the new RFCs for book keeping purposes. Thanks.

from sig-graphics-audio.

Since this RFC is accepted please open a PR and move this RFC to this folder - https://github.com/o3de/sig-graphics-audio/tree/main/rfcs where we will track all the new RFCs for book keeping purposes. Thanks.

Roger that! I'm on my way.

from sig-graphics-audio.