I’ll follow up with more on denoising approaches shortly; but here’s a quick interesting tip that may help someone in the future come a lucky google search. It’s about a black-sheep rendering API feature called transform feedback" in OpenGL lingo, or “stream output” in DirectX lingo. This feature causes the geometry shader to write primitive data to an arbitrary memory buffer instead of passing it onto the rasterizer.
Vulkan requires 2 things to use transform feedback / stream output:
Lately a lot realtime graphics research has been focused around signal noise – and more specifically, adding noise (by skipping samples) in specific ways so it can be removed again later passes. Though it isn’t really new, it seems to have become particularly important lately.
There’s a couple of good examples in open source
AMD’s denoiser and screenspace reflections from GPUOpen: https://github.com/GPUOpen-Effects/FidelityFX-Denoiser Ray traced far-field AO from the DirectX samples: https://github.
Final pieces of the straight skeleton puzzle In the last couple of parts, I covered the definition of the straight skeleton, plus some details about how to calculate it with finite precision math. Here I’ll go over some of the final elements of the implementation.
Polygons with holes We can also calculate a straight skeleton for polygons with holes. In this case, we will start with multiple “wavefronts” – one that represents the outer edges of the polygon moving inwards, and others than represent the edges of the holes, moving outwards.
Dealing with floating point precision Last time I described the straight skeleton algorithm, and write about how precision error can impact calculation. Here, I’ll break down the methods and heuristics I’m using to try to calculate the skeleton for complex shapes.
Calculation windows Instead of process edge event completely independently, let’s find a “window” of near simultaneous events to calculate each step. I found that without this, we could often get “missed motorcycles” – essentially a motorcycle crash should have happened, but never did, and the vertex proceeds along past it’s crash point.
Hello! The “straight skeleton” is an interesting computation geometry concept that’s not super commonly known, but has some interesting properties. I’ve just added a implementation to XLE; I’m not 100% sure if there are other solid implementations in open source (there may be, but last time I searched, I found implementations in commercial math packages, just not any in the open source domain).
Definition Imagine you have an arbitrary polygon (convex, concave, or even with internal holes).
Yikes; it’s been so long since I updated this that even the site generator I was using seems to have disappeared! I hit a busy phase with work, and wasn’t able to fully finish the spherical harmonics stuff. I probably got through most of the math stuff; but I never quite finished some of the applications and tricks you can do with the technique. It’s a pity, perhaps, because that would have been the fun stuff :)
This is a continuation of the tutorial on spherical harmonic applications for games. On the last page, we figured out the core math for integrating a basic diffuse BRDF with a spherical environment of incident light.
Efficient implementation So far, we’ve been dealing with spherical harmonics fairly abstractly. But now we can get down to a concrete use and some concrete code. Given our input texture (which effectively describes a sphere of incident light on a point) we want to calculate, for a given normal direction, what is the appropriate diffuse response.