I added some lights to the splat renderer. The lighting is ray traced on the CPU and the colors are uploaded as new vertex colors for rendering.
The program is currently single threaded (I'm planning on moving it into a thread pool later), and the ray tracing loop is time constrained to ensure that the frame is always presented on time. If I were to raise the splat count further, the convergence time on the lighting and shadows would become more noticeable.
It is worth noting that this is a C# program (and I think I forgot to switch it off of being a debug build), so that also adds some runtime overhead that limits the splat count. Rewriting this in C++ would allow the splat count to run much higher without amplifying the convergence artifacts.
@thomastc the benchmark is meant to illustrate a known problem, which is that tessellation and geometry shaders produce variable sized workloads that can't be known ahead of time, and some IHVs rely on being able to schedule and allocate workloads upfront for perf reasons.
This is still quite relevant. Mesh shaders were introduced as a better alternative to both, and the industry has largely standardized on them.
@VegaHarmonia the model is a SDF, and I cast 20k random rays at it and placed a splat on each rayhit. The splats are paraboloids more or less aligned like billboard sprites in view space.