Distance-based Gaussian weighting for Ambient Occlusion

[jjhembd]

Description

Ambient Occlusion (AO) for geospatial data needs to produce good results at a wide range of scales, without requiring the user to adjust parameters for each zoom level. This PR redefines the weight function for AO as a normalized Gaussian window, with a variance that scales with the distance from the camera.

Before this PR, the AO effect disappears when zoomed out:

After this PR, the AO effect blurs wider, remaining visible (though lower intensity) when far from the camera:

When viewing a scene from larger distances, some flickering and noise may be visible, partly due to #11067. These can be reduced by setting Viewer.camera.frustum.near to 1.0 or more, to improve precision in the depth buffer.

Issue number and link

Fixes #10106.

Testing plan

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

#TODO

• Rework uniforms to expose loop counts and Gaussian window size
• Add fallback to support variable loop counts in WebGL1
• Add fallback with deprecation message to support old uniforms
• Test performance, pre-compute window weights if needed
• Choose good defaults
• Resolve artifact at frustum boundary
• Remove blur method, possibly replace with bilateral filtering

[github-actions]

Thank you for the pull request, @jjhembd!

✅ We can confirm we have a CLA on file for you.

[ggetz]

Thanks @jjhembd! Excited to get this in!

Is the code ready for review yet, or should we wait for the uniform changes to go in first?

[jjhembd]

The code is now ready for performance testing with different sample counts. There are 2 parameters:

• directionCount: The number of directions in which to raytrace away from a given pixel
• stepCount: The number of steps to take in the ray tracing along a given pixel

See this local Sandcastle for a demonstration of the parameters.

Is the code ready for review yet, or should we wait for the uniform changes to go in first?

I think it would make sense to wait until the uniform changes are done. I still have one change to implement: the step size should be automatically computed from the window size (lengthCap) and stepCount. This will take a little more thought since the step size is in pixels, while the Gaussian window is currently defined in meters.

[ggetz]

Suggested change

//vec2 radialStep = stepLength * sampleDirection;

[ggetz]

Does czm_metersPerPixel help at all here?

[ggetz]

@jjhembd I'm consistently seeing a band along the top of the screen, any idea what may be causing that? Is it the transition between multiple frustums maybe?

[ggetz]

I'm also seeing some flickering due to occlusion when I look up at the sky. Is that just me?

[ggetz]

@jjhembd What's the plan for blur? I noticed your sandcastle disables it entirely.

I agree the look of the blur is not great. Would it make sense to remove it completely? Maybe we could use MSAA to remove "noise" from few samples?

[ggetz]

I'm seeing good results and a stable 60 FPS with

  stepCount: 32,
  directionCount: 8,

I think stepCount could potentially go even lower to 16, if we're looking fewer samples overall, and still look good.

That looks to be working well at other scales as well, such as buildings:

No AO, for comparison:

[jjhembd]

@ggetz thanks for the initial feedback!

I reworked the uniforms to compute the step length from the window size and step count. This value also works as the scalar to account for discrete sampling of the Gaussian, so we don't have to compute normalization factors in the inner loop.

I'm consistently seeing a band along the top of the screen

This does look like a frustum boundary. The occlusion should be neglecting this, since it appears in the depth buffer as a huge jump--much bigger than the window length. It's possible we're not correctly handling zero values in the depth buffer. I'm looking at this now.

What's the plan for blur?

We discussed using a bilateral filtering at one point, which would better preserve edges. I will take a look today to see how much work that would be.

We still need to add some kind of deprecation for the old uniform names. I updated the TODO list in the description.

[jjspace]

@jjhembd I'm seeing some flickering across the entire terrain as I zoom out in the sandcastle. I'm also seeing some banding on the smokestack things but I'm not sure if those are related. The flicker is quick and goes away when the camera settles but is that expected?

simplescreenrecorder-2024-11-27_16.01.57.mp4

[jjspace]

This is definitely a nice change to be able to see the AO from further away. I think the code looks good with my somewhat limited shader knowledge. I just had one small comment about the JS code. Also the bug(?) that I pointed out in my comment above

[jjspace]

This method of setting default values is not equivalent to the previous defaultValue calls when the value is null. I just want to make sure that's intended

[jjhembd]

@jjspace agreed. I think we are already doing this in other parts of the code, with the assumption that null is only an issue when we might be passing the result of a document.getElement?? call or similar.
(and for others reading this, we have more discussion in #12196).

[jjhembd]

@jjspace thanks for the review!

I'm seeing some flickering across the entire terrain as I zoom out in the sandcastle.

I think this is related to #11067 (comment). We will still need to investigate the depth stability further, but I think we can leave that as a separate issue--let me know if that approach makes sense to you.

I'm also seeing some banding on the smokestack things

When using the log depth buffer with a very small value for the near plane (as is default), there is some inaccuracy in the far-away depth values. I just pushed an adjustment to the Sandcastle to push the near plane out to 1m. Does this reduce the artifacts on your end?

[jjspace]

We will still need to investigate the depth stability further, but I think we can leave that as a separate issue--let me know if that approach makes sense to you.

I think I'm ok with that. I think I agree that benefit of ao at more distances outweighs the slight flickering at certain heights. Hopefully we can swing back around to that depth plane sooner than later though.

I just pushed an adjustment to the Sandcastle to push the near plane out to 1m. Does this reduce the artifacts on your end?

It does, the smokestacks look good. It also seems to reduce the other flickering issue pretty significantly. Would it make sense to change the overall default?

[jjhembd]

@jjspace adjusting the default near plane distance might have negative impacts on some other uses, where we need to render things close to the camera.
I updated both this PR description and CHANGES.md to recommend a larger near plane distance when AO at large distances is desired.

I also pushed a minor edit to ConvolveSpecularMapFS (from #12129) to fix an error showing up in WebGL1 contexts.

Thanks again for your feedback! I think this should be ready to go now.

[jjspace]

Thanks @jjhembd! As discussed offline I think I agree that this is fine to go with the depth buffer issues which will need to be addressed as part of a larger effort for all post processing. I'm ok to merge this now