Implement anisotropic fluid rendering

[yogwoggf]

Because FleX has neighbor, anisotropy and generic particle data for us, it's better to implement an anisotropy-based solution. Paper: https://www.sciencedirect.com/science/article/pii/S0097849322002308 This paper is state-of-the-art, and was published February of 2023.

Scope

gelly-renderer gelly-engine (for feeding anisotropy data)

Acceptance Criteria

• [ ] Every required G-buffer filled out with the particle data
• [ ] Decent performance

Proposed solution

I think the best way to tackle this is to copy the modern method which is just raytracing a sphere in parameter space, and transforming the results out of parameter space using the anisotropy matrix.

[yogwoggf]

So, progress:

• [x] Particle splatting
• [x] Depth rendering
• [x] Fluid surface by smoothing (but broken)
• [x] Normal rendering

Almost done, but the smoothing filter is definitely broken.

[yogwoggf]

Good read: https://www.slideshare.net/DevCentralAMD/vertex-shader-tricks-bill-bilodeau

[yogwoggf]

Another great read: https://graphics.cs.kuleuven.be/publications/PSIRPBSD/PSIRPBSD_paper.pdf That one actually explains how to extract a 3D normal from 2D texcoords. They also fucken generalized attribute blending which is a major part of Gelly!!!

[yogwoggf]

Think I have an idea for ultra-fast rendering.

1. Setup an index buffer with nothing.
2. DrawIndexed with an index count of 6 * particleCount
3. Use VertexID and dynamically generate the quad.
4. Take in particle positions as an SRV instead of a VB. (check this)
5. Return a VS output structure with the quad data and a texcoord.

[yogwoggf]

This is by Bill Bilodeau, and his experiments show it's roughly ~1.8-2.4x faster than a geometry shader. In one of Gelly's worst cases, that's about 64 fps compared to 32 fps. I think it's worth it, but after realizing that it isn't obscenely faster, I think this can safely be put on the backburner.