Jump to content
  • Advertisement
Sign in to follow this  
jameszhao00

DX11 Demo/Idea: Cache pixel triangles and adaptively supersample it later

This topic is 2299 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was doing some stuff for my game architecture final project, and came up with the following AA idea.
It works with subpixel information, and in the current implementation is pretty expensive.
I didn't do a lot of research into this area, so think of it as a implementation demo if it's already been proposed biggrin.png

The idea is to cache, per pixel, the triangle being shaded. Later, we selectively supersample occlusion.

Demo
Requires a DX11 card. Black spots are artifacts from small triangles (around the head and zooming out too much).
The 'AA Viz' option visualizes the triangles in the (AA Viz X, AA Viz Y) pixel.
Use the DX option to simulate subpixel movement
Shader source in shaders/aa.hlsl

aa-comparison.png

http://dl.dropbox.co...097/aa_demo.zip

Outline

  • Render the scene and store the pixel's triangle verticies.

    • a. Store 3 float2s in NDC space to 32 bit SNORM textures

      • NDC space because it's easy to get in the PS, and later on we can do 2D triangle-point containment instead of 3D triangle-ray intersection tests
      • Currently I store 3 float3s to R32G32B32A32_FLOAT textures (for debugging/laziness reasons)
      • Currently I render with no MSAA.
      • Render a supersampling mask.

        • Currently I just render an AA wireframe
        • In the AA pass, for each pixel that we wish to super sample...

          • Collect every triangle from the neighboring pixels... for up to a total of 9 triangles

            • When the triangles aren't tiny these 9 triangles will cover the entire pixel
            • Collect every depth, color from the neighboring pixels.
            • For every sample point (16 in the demo)

              • Perform a 2d triangle-point containment test for every triangle
              • Find the closest triangle (using the neighboring depth values)

                • Pretty crude approximation
                • Store the color for that triangle (using the neighboring color values)
                • Normalize by # of samples hit

                  • There's a background triangle that covers the entire NDC cube, so mesh-background edges work
                  • However, in the interior we can get gaps at places where small triangles, which aren't necessarily stored, exist




                    Pros

                    1. Fixed storage cost for arbitrary sampling density.
                    2. Stores partial subpixel information
                    3. Works well for long edges


                    Cons

                    1. Heavy initial memory cost (storing 3 float2s (right now float3s) per pixel)
                    2. Extremely ALU intensive with point - tri containment tests

                      1. Currently I use some generic algorithm... hopefully better ones exist
                    3. Artifacts with small (subpixel to few pixel) triangles
                    4. Incorrect (though minor) blending

                    Improvements

                    1. Alternative triangle representation...

                      1. We just need local triangle information relative to the pixel
                    2. Way cheaper 2d triangle - point containment tests

                      1. Currently the major 'demo bottleneck'.
                    3. Actually adaptively supersample

                      1. Right now its binary.


                    Any suggestions/this is interesting/this is stupid? biggrin.png

Share this post


Link to post
Share on other sites
Advertisement
Without analyzing what you've done much I'd look into FXAA which seems to have taken over as a post-processing AA effect.
http://developer.dow..._WhitePaper.pdf

You mentioned "Works well for long edges" which I remember reading was a problem with FXAA. Might be useful to do a comparison against FXAA to see if your method is higher quality.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!