Timethy Hyman

Real Time FFT Ocean Rendering in DirectX 12

Sun, 08 Mar 2026 13:23:23 +0000

Introduction

Oceans can be one of the most relaxing phenomena that nature provides us. Hearing the crashing waves, seeing small water ripples and light refraction through the water surface can take hours of my day when sitting at a beach. This is one of the reasons why this project came to life.

As a graphics programmer, I often ask myself how real life scenarios would translate to a digital implementation. Usually I have a rough idea, but oceans seemed so complex, non-uniform and variable dependent that I decided to ask google instead. This led to a rabbit hole of papers regarding Fourier Transforms, Euler’s formula and scary math which I will be elaborating on in this blogpost.

So if you’ve ever looked at an ocean and wondered how films such as Titanic, AAA games such as Horizon Forbidden West and Sea of Thieves recreated it, then this blogpost is for you.

Wave Simulation: JONSWAP & the FFT Pipeline
Rendering & Shading
Foam
Wave Cascades: Multi Scale Detail
Skybox & Environment
Major Struggles & Lessons Learned
Results & Next Steps

Before we start let me show you what we will be building.

Calm open ocean

Ocean with large swells and prominent wind direction

Understanding the basics

How does a sine wave work?

The ocean wave implementation is heavily based on using multiple sine waves to get interesting displacements. Sine waves are oscillators, which means they generate a repetitive wave signal that stays within its amplitude. Three important terms regarding a wave is its amplitude, its wavelength and its frequency. Amplitude is the peak of the wave, the highest value that the signal can reach. Wavelength is the distance between two of these peaks, you can imagine this like a spring. A spring that is compressed would represent a short wavelength while a spring that is stretched out would represent a long wavelength. Frequency is how often a signal repeats within a second. A short wavelength correlates to a high frequency, a long wavelength correlates to a low frequency. This ties together with ocean rendering because we can use this wavelength to shape the waves of our ocean, how we do this will be discussed in this article.

What are complex numbers?

A complex number is simply two numbers packed into one. It has a real part and an imaginary part. Its form is $c = a + bi$ You can think of it like a 2D coordinate. Instead of writing $p = (3,4)$, you'd write $p = 3 + 4i$. The $i$ is the imaginary part of the number, which lives on the axis perpendicular to the real number line. When any number is multiplied by the imaginary $i$, it is essentially "rotated" by 90° counter clockwise. This rotation property is what lets Euler's formula describe circular motion. Interesting note, multiplying a number by $i$ twice, brings it to -1, which leads to a whole other discussion on why $i = \sqrt{-1}$. But that is out of scope for this blogpost.

What is Euler's formula?

Euler's formula states that any point on a unit circle can be written as: \[e^{i\theta} = \cos\theta + i\sin\theta\] This tells us that if you take e to the power of an imaginary number, you would get a point on a circle. Here the $cos\theta$ is the x coordinate, and the $sin\theta$ is the y coordinate. This is very useful for our ocean simulation since as theta increases over time, the point spins around the circle. This spinning around the circle causes the x and y values to oscillate up and down which drive the displacement of the ocean over time. Euler's formula is a compact way to represent the oscillation of the sin and cosine components packed into one expression.

How does a compute shader work?

A compute shader is a shader that runs directly on the GPU, outside of the normal rendering pipeline. Unlike vertex and pixel shaders, it has no fixed role. Instead, it runs a large grid of threads in parallel, allowing the GPU to do many calculations at the same time. A CPU has a small number of powerful cores built for sequential logic. A GPU has thousands of smaller cores built to do the same operation on many pieces of data at once. This makes the GPU much better suited for tasks like the FFT, where the same calculation needs to happen on every point of a texture every frame. The developer defines the size of the thread grid themselves. Each thread knows its own position in the grid via SV_DispatchThreadID, so it knows exactly which point on the ocean it is responsible for. This way every point on the ocean plane gets calculated in parallel.


[numthreads(8, 8, 1)]
void CSMain(uint3 id : SV_DispatchThreadID)
{
    // id.xy is this thread's position in the grid
    // each thread computes the wave displacement for one point
    OutputTexture[id.xy] = ComputeWaveDisplacement(id.xy);
}

Chapter 1 Wave Simulation: JONSWAP & the FFT Pipeline

The ocean surface is made up of thousands of waves, all travelling in different directions with different sizes and speeds. To simulate this, we model the ocean as a sum of sine waves, each with their own frequency, direction and amplitude. The question then becomes: how do we decide how big each of those waves should be?

This is where oceanographers come in. Over decades, researchers measured real ocean surfaces using buoys, photographs and radar measurements to figure out exactly how wave energy is distributed across different frequencies in a fully developed ocean. A fully developed ocean simply means the ocean has had enough time and distance to reach an equilibrium with the wind blowing over it. The result of this research is a spectrum function, which tells us how much energy each wave frequency should have given a set of wind conditions.

Now, evaluating thousands of sine waves individually for every point on the ocean every frame would be far too slow even for a modern GPU. This is where the FFT comes in. Before we dive into how FFT works, we need to understand the two relevant domains. The Spatial Domain and the Frequency Domain.

The spatial domain is our usual graph that has a value Y on the vertical axis, and a constantly increasing value X usually representing time or position, on the horizontal axis. The frequency domain exposes frequency on the horizontal axis and amplitude on the vertical axis. This produces a graph that visualizes the link between frequencies and their amplitudes.

Source: Why Measuring in the Time Domain and Frequency Domain Is the Same, but Not

FFT works in the frequency domain, where each point represents a wave frequency rather than a world position. The FFT algorithm then converts the entire frequency domain into real world displacements (which live in the spatial domain) in one efficient pass. The beautiful thing about this, is that it’s a lossless operation. We can convert our data between domains without losing any information. This is neat since we can remove certain frequencies from the equation, convert the data back to the spatial domain and have the exact same wave minus the removed frequency. You can imagine this like having a musical chord, say C Major 7. This chord contains the notes C, E, G and B. Using the FFT, you would be able to see every note that this chord signal contains, remove the B for example and convert it back to the spatial domain. The result would be a simple C Major chord which has the notes C, E and G.
With this understanding of the FFT, we can now look at how Tessendorf uses it to build the ocean spectrum.

In his paper, Jerry Tessendorf describes the Phillips Spectrum as the model for defining wave energy. After implementing it I found it too limiting since its only parameters were wind speed and direction. So I switched to the JONSWAP spectrum, a more widely adopted model that gives much more creative freedom. With JONSWAP you can control things like how many waves follow the wind direction, the choppiness of the waves, the distance over which the wind affects the surface, and the sharpness of the spectrum peak. This lets you model anything from a calm open ocean to a stormy sea with large aggressive swells.

1.1 The Setup

The ocean simulation is driven by a statistical wave spectrum. Rather than simulating individual water particles, the sea surface is represented as a collection of many sinusoidal waves.

To simulate the ocean, the general idea is that we want to start by generating the initial representation of the heightfield in 2D space. We do this by using the wave spectrum in combination with a gaussian pseudo random number generator. The gaussian random number is used to ensure that each wave component starts at a different point in its cycle. This way two oceans with the same parameters will still look different from each other. This random number becomes the $\xi_r + i\xi_i$ term in the H₀ formula, which we will see in section 1.2.

Tessendorf expresses the ocean height field as a sum of complex wave contributions across all frequencies. We represent the ocean surface using the formula:

\[h(\mathbf{x}, t) = \sum_{\mathbf{k}} \tilde{h}(\mathbf{k}, t) \exp(i\mathbf{k} \cdot \mathbf{x})\]

Where:
$t$ - time
$\mathbf{x}$ - horizontal position on the ocean surface
$\mathbf{k}$ - a 2D wave vector with components $\mathbf{k} = (k_x, k_z)$
$k_x = \frac{2\pi n}{L_x}$
$k_z = \frac{2\pi m}{L_z}$
$n, m$ - integers in the range [$-N/2 \leq n < N/2$] and [$-M/2 \leq m < M/2$].
$\tilde{h}(\mathbf{k}, t)$ - complex amplitude encoding the amplitude and **phase* of the wave at frequency $\mathbf{k}$ and time $t$
$N, M$ - the resolution of the FFT grid

What is the phase of a wave?

The phase is the position of a wave within its cycle at any point in time. It is measured in radians, a phase value of 0 means the wave is at its peak, while a phase value of $\frac{\pi}{2}$, means that the wave is halfway between the peak and zero.

This heightfield is the result of the FFT converting the initial spectrum from the frequency domain to the spatial domain. This will be discussed in section 1.5. The complex amplitude $\tilde{h}(\mathbf{k}, t)$ is the heart of this formula. It is what we need to construct for every wave vector $\mathbf{k}$ on our grid. To do this we need two things: the JONSWAP spectrum, which tells us how much energy each wave frequency should carry, and the dispersion relation, which tells us how fast each wave travels. Section 1.3.

The dispersion relation allows us to propagate this heightfield forward in time, animating the waves. This will need to be recalculated every frame to update the heightfield accordingly. The dispersion relation defines the relationship between angular frequency $\omega$ and the wave number $k$.
In deep water, its formula is defined like this:

\[\omega = \sqrt{gk}\]

$\omega$ - Angular frequency. How fast the wave oscillates in time (radians/sec)
$g$ - Gravitational acceleration (9.81 m/s²)
$k$ - The Wavenumber. Waves per meter: $k = \frac{2\pi}{\lambda} $

What is angular frequency?

Regular frequency describes how many full cycles happen in a second. For example: A wave that completes 3 cycles in a second has $f = 3$Hz. Angular frequency comes from thinking about this cycle rotating around a unit circle rather than oscillating up and down. A full rotation around a unit circle is $2\pi$. Angular frequency is simply the regular frequency multiplied by $2\pi$. $$\omega = 2\pi f$$

For our implementation, we will be using the form that encodes a finite depth:

\[\omega = \sqrt{gk\tanh(kD)}\]

$D$ - Ocean Depth. Large values for D simplifies back to the base form while smaller values for D reduce the wave speed.

The dispersion relation formula is an approximation. There are many different relationships you can choose to fit your ocean.

With the general idea understood, we can now look at how the wave spectrum is constructed.

1.2 The Wave Spectrum

The wave spectrum is essentially a function that describes how the wave energy is distributed across combinations of angular frequencies $\omega$ and wind directions $\theta$.

The JONSWAP spectrum formula looks like this:

\[S_{\text{JONSWAP}}(\omega) = \text{scale} \cdot \phi_{TMA}(\omega) \cdot \frac{\alpha g^2}{\omega^5} \exp\left(-\frac{5}{4}\left(\frac{\omega_p}{\omega}\right)^4\right) \gamma^{\exp\left(-\frac{(\omega - \omega_p)^2}{2\sigma^2\omega_p^2}\right)}\]

Where:
$\alpha$ - Energy scale, controls the overall wave height
$g$ - Gravitational acceleration (9.81 m/s²)
$\omega$ - Angular frequency of the wave being evaluated
$\omega_p$ - Peak frequency, the frequency with the most energy
$\gamma$ - Peak enhancement factor, controls the sharpness of the spectrum peak
$\sigma$ - Width parameter, 0.07 when $\omega \leq \omega_p$ and 0.09 when $\omega > \omega_p$
$\phi_{TMA}$ - TMA shallow water correction factor. Reduces the wave speed at shallow depths.

Before diving into each component of the JONSWAP, lets define a struct that will hold all the parameters that we will be populating.

	struct JonswapParameters
	{
		float scale = 0.0f; // Used to scale the Spectrum [1.0f, 5.0f] 
		float spreadBlend = 0.0f; // Used to blend between agitated water motion, and windDirection [0.0f, 1.0f]
		float swell = 0.0f; // Influences wave choppiness, the bigger the swell, the longer the wave length [0.0f, 1.0f]
		float gamma = 0.0f; // Defines the Spectrum Peak [0.0f, 7.0f]
		float shortWavesFade = 0.0f; // [0.0f, 1.0f]

		float windDirection = 0.0f; // [0.0f, 360.0f]
		float fetch = 0.0f; // Distance over which Wind impacts Wave Formation [0.0f, 10000.0f]
		float windSpeed = 0.0f; // [0.0f, 100.0f]

        // These values get calculated using the metrics above.
		float angle = 0.0f;
		float alpha = 0.0f;
		float peakOmega = 0.0f;
	}m_jonswapParams;

In code, calculating the JONSWAP spectrum looks like this:

float Ocean::JONSWAP(float omega)
{
    float sigma = (omega <= m_jonswapParams.peakOmega) ? 0.07f : 0.09f; // width parameter
    float r = exp(-(omega - m_jonswapParams.peakOmega) * (omega - m_jonswapParams.peakOmega) / 2.0f / sigma / sigma / m_jonswapParams.peakOmega / m_jonswapParams.peakOmega); // peak enhancement
    float g = 9.81f; // gravity

    float oneOverOmega = 1.0f / (omega + 1e-6f);
    float peakOmegaOverOmega = m_jonswapParams.peakOmega / omega;

    return m_jonswapParams.scale * TMACorrection(omega) * m_jonswapParams.alpha * g * g * oneOverOmega * oneOverOmega * oneOverOmega * oneOverOmega * oneOverOmega 
			* exp(-1.25f * peakOmegaOverOmega * peakOmegaOverOmega * peakOmegaOverOmega * peakOmegaOverOmega) * pow(abs(m_jonswapParams.gamma), r);
}

The TMA (Texel Marsen Arsloe) correction is used for the non directional component of the wave spectrum. This means that it does not care about the direction the waves are moving, instead the TMA functions on the depth of the ocean. In shallow waters, the seabed starts to intervene with the waves. The waves slow down, their shape changes and their energy distribution across waves get shifted. TMA accounts for this and adjusts the JONSWAP spectrum by multiplying the spectrum with a depth dependent factor.

float TMACorrection(float w)
{
    float omegaH = omega * sqrt(OCEAN_DEPTH / 9.81f);
    if (omegaH <= 1.0f)
        return 0.5f * omegaH * omegaH;
    if (omegaH < 2.0f)
        return 1.0f - 0.5f * (2.0f - omegaH) * (2.0f - omegaH);

    return 1.0f;
}

Before we continue, lets populate our JonswapParameters. I recommend you play with the values to meet your desired artistic vision.
We do need to calculate 3 of the variables: The angle, the alpha and the peakOmega.

m_jonswapParams.angle = m_jonswapParams.windDirection / 180.0f * PI;
m_jonswapParams.alpha = JonswapAlpha(m_jonswapParams.fetch, m_jonswapParams.windSpeed);
m_jonswapParams.peakOmega = JonswapPeakFequency(m_jonswapParams.fetch, m_jonswapParams.windSpeed);

float Ocean::JonswapAlpha(float fetch, float windSpeed)
{
    return 0.076f * pow(9.81f * fetch / windSpeed / windSpeed, - 0.22f);
}

float Ocean::JonswapPeakFequency(float fetch, float windSpeed)
{
    return 22.0f * pow(windSpeed * fetch / 9.81f / 9.81f, -0.33f);
}

Now that we have the wave spectrum, we can look at generating the initial heightfield.

1.3 Initial Spectrum Generation: H₀

We compute the initial spectrum once, my implementation does this on the CPU but its best done on the GPU since it can make great use of parallel computing.

The formula Tessendorf proposes in his paper is:

\[\tilde{h}_0(\mathbf{k}) = \frac{1}{\sqrt{2}}(\xi_r + i\xi_i)\sqrt{P_h(\mathbf{k})}\]

Where:
$\tilde{h}_0(\mathbf{k})$ - The initial complex amplitude for wave vector $\mathbf{k}$. Encodes the amplitude and phase of one wave component.
$\mathbf{k}$ - A 2D wave vector representing the frequency and direction of a wave component.
$\xi_r$ - A Gaussian random number for the real part.
$\xi_i$ - A Gaussian random number for the imaginary part.
$P_h(\mathbf{k})$ - The wave spectrum energy at wave vector $\mathbf{k}$. In our implementation this is the JONSWAP spectrum.
$\frac{1}{\sqrt{2}}$ - A normalisation factor that ensures the correct distribution of wave amplitudes.

This data lives in the frequency domain.
We generate a complex number that encodes the amplitude and phase for every wave vector k. We store the resulting data in a R16G16B16A16_FLOAT texture.

Lets look at some code.

void Ocean::GenerateH0(std::shared_ptr<CommandList> commandList, const UINT cascade) {

    float deltaK = 2.0f * PI / patchSize;
    float highestK = (OCEAN_SUBRES / 2.0f) * deltaK; // nyquist limit

    // stored in heap to avoid stack overflow
    std::vector<std::complex<float>> H0(OCEAN_SUBRES * OCEAN_SUBRES, { 0,0 });
    std::vector<std::complex<float>> H0Conj(OCEAN_SUBRES * OCEAN_SUBRES, { 0,0 });

    const float lowCutoff = cascade == 0 ? 0.001f : (OCEAN_SUBRES * PI / m_oceanPatchSizes[cascade - 1]); // nyquist limit of previous cascade;
    const float highCutoff = highestK;
    
    
    for (int m = 0; m < OCEAN_SUBRES; m++) {
        for (int n = 0; n < OCEAN_SUBRES; n++) {
            // Get wave vector for this frequency
            float kx = (n - OCEAN_SUBRES / 2.0f) * deltaK;
            float ky = (m - OCEAN_SUBRES / 2.0f) * deltaK;
            float k(sqrtf(kx * kx + ky * ky));

            if (k >= lowCutoff && k <= highCutoff)
            {
	            
            float kAngle = atan2(ky, kx);
            float omega = DispersionRelation(k);
            float dOmegadk = DispersionDerivative(k);

            float spectrum = JONSWAP(omega) * DirectionSpectrum(kAngle, omega) * ShortWavesFade(k);
            
            // Generate two independent gaussian random numbers
            float xiR = GaussianRandom();
            float xiI = GaussianRandom();

            float amplitude = sqrtf(2.0f * spectrum * fabsf(dOmegadk) / k * deltaK * deltaK);
            H0[m * OCEAN_SUBRES + n] = std::complex<float>(xiR * amplitude, xiI * amplitude);
            }
        }
    }

    // Needs its own loop since the conjugate needs all data of H0 to be valid
    for (int m = 0; m < OCEAN_SUBRES; m++) {
        for (int n = 0; n < OCEAN_SUBRES; n++) {
            int m_minus = (OCEAN_SUBRES - m) % OCEAN_SUBRES;
            int n_minus = (OCEAN_SUBRES - n) % OCEAN_SUBRES;
            H0Conj[m * OCEAN_SUBRES + n] = std::conj(H0[m_minus * OCEAN_SUBRES + n_minus]);
        }
    }

    std::vector<uint16_t> combinedData(OCEAN_SUBRES * OCEAN_SUBRES * 4);

    for (int m = 0; m < OCEAN_SUBRES; m++) {
        for (int n = 0; n < OCEAN_SUBRES; n++) {
            int index = (m * OCEAN_SUBRES + n) * 4;
            combinedData[index + 0] = FloatToHalf(H0[m * OCEAN_SUBRES + n].real());       // R: H0 real
            combinedData[index + 1] = FloatToHalf(H0[m * OCEAN_SUBRES + n].imag());       // G: H0 imaginary
            combinedData[index + 2] = FloatToHalf(H0Conj[m * OCEAN_SUBRES + n].real());   // B: H0_conj real
            combinedData[index + 3] = FloatToHalf(H0Conj[m * OCEAN_SUBRES + n].imag());   // A: H0_conj imaginary
        }
    }

    D3D12_SUBRESOURCE_DATA subData = {};
    subData.pData = combinedData.data();
    subData.RowPitch = OCEAN_SUBRES * 4 * sizeof(uint16_t); // 4 channels * 2 bytes
    subData.SlicePitch = subData.RowPitch * OCEAN_SUBRES;

    commandList->CopyTextureSubresource(m_oceanCascades[cascade].H0Texture, 0, 1, &subData);
}

Lets dissect this.
deltaK is the spacing between frequency samples. Since our patch covers patchSize metres in the real world, dividing $2\pi$ by it gives us the step size in frequency space.
highestK is the Nyquist limit, the highest frequency our grid can represent before aliasing occurs.
lowCutoff and highCutoff can be ignored for now, these will be explained in Chapter 4.

The double for loop
For each grid position $(n, m)$ we compute the wave vector components kx and ky. Subtracting OCEAN_SUBRES / 2.0f centers the grid around zero so we cover both positive and negative frequencies, representing waves travelling in all directions.
k is the magnitude of the wave vector, the wavenumber.

Computing the spectrum value
For each wave vector we compute three things.
kAngle is the direction the wave is travelling.
omega is the angular frequency from the dispersion relation.
The full spectrum value is then the product of three functions. JONSWAP gives the total energy at this frequency.
DirectionSpectrum distributes that energy across directions based on kAngle.
ShortWavesFade damps out very high frequencies to prevent aliasing artifacts.

How does directional spreading work?

The JONSWAP spectrum $S(\omega)$ only tells us how much energy a wave of a certain frequency should have. It says nothing about which direction that energy travels. The directional spreading function $D(\omega, \theta)$ solves this by distributing the energy across directions. Multiplying them together gives us the full directional spectrum: $$S(\omega, \theta) = S(\omega) \cdot D(\omega, \theta)$$ The spreading function we use is based on the Longuet-Higgins form, which most empirical models share: $$D(\omega, \theta) = Q(s) \cdot |\cos(\theta/2)|^{2s}$$ The parameter $s$ controls how concentrated the energy is around the wind direction. A large $s$ means waves are tightly focused along the wind. A small $s$ means energy spreads out in all directions. $Q(s)$ is a normalisation factor that ensures the total energy across all directions sums to 1. In code, Cosine2s is this function and NormalizationFactor is $Q(s)$, computed using a polynomial approximation rather than the exact Euler gamma function for performance reasons.

Computing $s$: the Hasselmann model
We use the Hasselmann empirical model to compute $s$ based on how far the current frequency is from the peak frequency $\omega_p$:


float SpreadPower(float omega, float peakOmega)
{
    if (omega > peakOmega)
        return 9.77f * pow(abs(omega / peakOmega), -2.5f);
    else
        return 6.97f * pow(abs(omega / peakOmega), 5.0f);
}

The constants 9.77 and 6.97 come directly from Horvath's paper. Frequencies near the peak get a high $s$ value, meaning they are focused along the wind. Frequencies far above the peak get a low $s$, spreading more freely in all directions.

The swell parameter
On top of the Hasselmann base value, we add a swell contribution: $$s_\xi = 16 \tanh\left(\frac{\omega_p}{\omega}\right)\xi^2$$ Where $\xi$ is the swell parameter. Increasing swell adds to $s$, making waves more elongated and parallel, simulating waves that have travelled from a distant storm rather than being generated by local wind.

Blending with spreadBlend
The final spreading function blends between two models based on the spreadBlend parameter:


return lerp(
    2.0f / PI * cos(theta) * cos(theta),  // simple cosine squared, no directionality
    Cosine2s(theta - angle, s),            // full Hasselmann + swell spreading
    spreadBlend
);

A spreadBlend of 0 gives a simple spreading where all wavelengths spread equally regardless of frequency. A spreadBlend of 1 gives the full empirical Hasselmann model with swell. Values in between blend the two, giving you creative control over how directional the ocean looks.

Computing the amplitude and storing H₀ Two independent Gaussian random numbers give each wave component a unique random phase. The amplitude formula converts the continuous spectrum density into a discrete amplitude value for this specific grid cell, accounting for the cell size deltaK * deltaK. Multiplying the random numbers by the amplitude gives us $\tilde{h}_0(\mathbf{k})$, stored as a unique complex number.

The Conjugate
The conjugate is simply the sign mirror of a complex number. For example the conjugate of $z = a + bi$ is $z = a - bi$. This conjugate is needed since the FFT takes complex numbers as input and produces a complex number as an output too. Our heightfield needs to use real numbers, so using the conjugate we can cancel out the imaginary part of the FFT output, leaving us with only real values. for example:

\[(a + bi) + (a - bi) = 2a\]

Texture Packing
Both H0 and its conjugate are packed into a single RGBA texture. The real and imaginary parts of H0 go into the R and G channels, the conjugate goes into B and A. The values are converted to 16 bit half precision floats to save memory. This texture is then uploaded to the GPU where the compute shader will read it every frame to propagate the waves forward in time.

This function provides us with the initial spectrum texture. You can visualize this texture in your preferred graphics debugger, I’m using RenderDoc. You will need to change the color range to a very small value to see the colors clearly.

Your version might look slightly less colorful, mine is using multiple frequency bands which will be covered in Chapter 4.

Next we will look at how the FFT transforms this frequency domain data into real world wave displacements

1.4 Time Evolution: Animating the Waves

The next step now that we have the initial spectrum, is to bring our static data to life by animating it over time. Tessendorf provides us with the following formula:

\[\tilde{h}(\mathbf{k}, t) = \tilde{h}_0(\mathbf{k})\,e^{i\omega(k)t} + \tilde{h}_0^*(-\mathbf{k})\,e^{-i\omega(k)t}\]

Every frame, we take our initial spectrum $\tilde{h}_0(\mathbf{k})$ and multiply it by $e^{i\omega t}$. From Euler’s formula we know that this advances the phase of each wave component forward in time at its own speed, determined by the dispersion relation. The second term $\tilde{h}_0^*(-\mathbf{k})\,e^{-i\omega(k)t}$ is the conjugate we discussed earlier, ensuring the output remains a real value.

One important detail is that we use a rounded version of $\omega$ when computing the time evolution. This ensures that every wave component completes full cycles within a fixed time period, so the ocean animation loops seamlessly without any visible discontinuity.

So we have the initial spectrum and its conjugate, the last missing term is the dispersion relation and the $e^{i\omega t}$ which we will calculate now.
Since we want to loop the animation, we need to introduce a new variable: REPEAT_TIME. Using this variable we can control the amount of time it takes for the simulation to loop back to its original state. I’m using a value of 500 but feel free to play around with this.

First we load our initial spectrum and conjugate data.


float4 H0Data = H0Texture.Load(int3(dispatchThreadID.xy, 0));
float2 h0 = H0Data.rg;
float2 h0conj = H0Data.ba;

float kx = 2.0f * PI * (dispatchThreadID.x - OCEAN_RESOLUTION / 2.0f) / patchSize;
float ky = 2.0f * PI * (dispatchThreadID.y - OCEAN_RESOLUTION / 2.0f) / patchSize;
float k = length(float2(kx,ky));
float kRcp = rcp(k);

// Prevent NaN values
if (k < 0.0001f)
{
    kRcp = 1.0f;
}

We calculate the base frequency step.


float w = 2.0f * PI / REPEAT_TIME;

We can use this value as the stepsize around the unit circle and use time as the scalar that advances the dispersion.


float dispersion = floor(sqrt(GRAVITY * k) / w) * w * time;

We now plug this dispersion into Euler’s formula which gives us $e^{i\omega t}$. Add these helper functions:



float2 EulerFormula(float x)
{
    return float2(cos(x), sin(x));
}

float2 complex_multiply(float2 W, float2 B)
{
    return float2(W.x * B.x - W.y * B.y,
                  W.x * B.y + W.y * B.x);
}

float2 exponent = EulerFormula(dispersion);

Now we have all the components to calculate $\tilde{h}(\mathbf{k}, t)$


float2 htilde = complex_multiply(h0, exponent) + complex_multiply(h0conj, float2(exponent.x, -exponent.y));

We now successfully computed the heightfield in the frequency domain. Next to this, we also want to have the horizontal displacement and the surface slope. The horizontal displacement will make the waves look choppy and the slopes are used to calculate the surface normals which we will be using in Chapter 2 for lighting calculations.

From the animated spectrum $\tilde{h}(\mathbf{k}, t)$ we can derive everything we need in one pass. Rather than running separate FFTs for height, horizontal displacement and surface slopes, we compute all of them in the frequency domain before the FFT using a property of Fourier transforms: taking a spatial derivative in the real world is equivalent to multiplying by $ik$ in the frequency domain.

First we precompute $i\tilde{h}$, which is just the complex number rotated 90 degrees:


float2 ih = float2(-htilde.y, htilde.x);

Then we derive each output signal:


// the raw height field, becomes vertical displacement after the FFT
float2 displacementY = htilde;
// horizontal displacement in x and z, pointing in the wave travel direction
float2 displacementX = ih * kx * kRcp;
float2 displacementZ = ih * ky * kRcp;
// the surface slopes in x and z, used to compute normals for lighting
float2 displacementY_dx = ih * kx;
float2 displacementY_dz = ih * ky;
// second order derivatives used to compute the Jacobian determinant for foam detection. Covered in Chapter 3. 
float2 displacementZ_dx = -htilde * kx * ky * kRcp;
float2 displacementZ_dz = -htilde * ky * ky * kRcp;
float2 displacementX_dx = -htilde * kx * kx * kRcp;

The negative sign on the second order derivatives comes from applying the $ik$ multiplication twice: $i^2 = -1$, so $ik \cdot ik = -k^2$.

All eight signals are then packed into two float4 textures and converted to the spatial domain by the FFT in the next pass.


float2 htildeDisplacementX = float2(displacementX.x - displacementZ.y, displacementX.y + displacementZ.x);
float2 htildeDisplacementZ = float2(displacementY.x - displacementZ_dx.y, displacementY.y + displacementZ_dx.x);
    
float2 htildeSlopeX = float2(displacementY_dx.x - displacementY_dz.y, displacementY_dx.y + displacementY_dz.x);
float2 htildeSlopeZ = float2(displacementX_dx.x - displacementZ_dz.y, displacementX_dx.y + displacementZ_dz.x);


displacementTexture[dispatchThreadID.xy] = float4(htildeDisplacementX, htildeDisplacementZ);
slopeTexture[dispatchThreadID.xy] = float4(htildeSlopeX, htildeSlopeZ);

With this, we now have the heightfield, horizontal displacement and slopes, all calculated in the frequency domain. The last step is to transform this data to the spatial domain.

1.5 The Butterfly FFT

Understanding the FFT

The ocean simulation depends on converting a frequency domain wave spectrum into real displacement values every frame. That conversion is an Inverse Fast Fourier Transform. In this section I will explain the idea behind this transformation and how it works. To not make this article too long/complex, I will not go too much into detail since understanding it fully is not required to make it work. If you are brave enough you can dive deeper and read the paper by Flugge and Matusiak.

The DFT: correct but slow

The Discrete Fourier Transform is defined as: $$F[k] = \sum_{n=0}^{N-1} f[n] \cdot e^{-i \frac{2\pi}{N} kn}$$ For each output frequency $k$, you multiply every input sample $f[n]$ by a complex rotation factor and sum the results. If you have $N$ samples and $N$ output frequencies, that is $N$ multiplications per output and $N$ outputs. A total of $N^2$ operations. For $N = 512$ that is 262,144 complex multiplications per row, per column, per frame. That is not viable in real time. The FFT computes the exact same result in $O(N \log N)$ time. For $N = 512$ that is roughly 4,608 operations. The result is identical. ***The key insight: reuse*** Consider $N = 4$. Since $e^{-i\pi/2} = -i$, the twiddle factor simplifies to $(-i)^{kn}$, and the four outputs expand to: $$F[0] = f[0] + f[1] + f[2] + f[3]$$ $$F[1] = f[0] - if[1] - f[2] + if[3]$$ $$F[2] = f[0] - f[1] + f[2] - f[3]$$ $$F[3] = f[0] + if[1] - f[2] - if[3]$$ Look at $F[0]$ and $F[2]$. Both contain $f[0] + f[2]$ and $f[1] + f[3]$, just combined differently. Look at $F[1]$ and $F[3]$. Both contain $f[0] - f[2]$ and $f[1] - f[3]$. The naive DFT computes each output independently, so it recomputes these components four separate times. The FFT computes them once and reuses them across all outputs. This is the entire idea.

The butterfly

The reusable building block is called a butterfly. Given two complex numbers $a$ and $b$ and a twiddle factor $W$, one butterfly produces: $$A = a + W \cdot b$$ $$B = a - W \cdot b$$ One addition and one subtraction, both reading from the same two inputs. For general $N$ the twiddle factor is: $$W_N^k = e^{-i \frac{2\pi}{N} k}$$ This is a point on the unit circle in the complex plane, a rotation by $k$ steps of $\frac{2\pi}{N}$ radians. In the shader this is computed as:


float angle = -2.0f * PI * float(w) / float(TOTALPOINTS);
float2 twiddle = float2(cos(angle), -sin(angle));

That is $W_N^w$ written in real and imaginary components.

The Stages

For $N = 4$ the FFT runs in two stages: **Stage 1** runs two butterflies, one on $f[0], f[2]$ and one on $f[1], f[3]$. This produces four intermediate values. **Stage 2** feeds those intermediate values into two more butterflies to produce the final outputs $F[0], F[1], F[2], F[3]$. For general $N$ there are $\log_2 N$ stages, and each stage runs $N/2$ butterflies. Total work is therefore: $$\frac{N}{2} \times \log_2 N$$ which is $O(N \log N)$. In the shader this is the outer loop:


for (uint stage = 0; stage < log2(TOTALPOINTS); ++stage)

Each iteration is one full stage, $N/2$ butterflies, all executing in parallel across the thread group.

Ping pong buffers

Each stage reads from the previous stage's output and writes its results somewhere else, you cannot read and write the same memory simultaneously on the GPU. The shader handles this with a double buffer and a flag that alternates each stage:


groupshared float2 bufferRG[2][TOTALPOINTS];
groupshared float2 bufferBA[2][TOTALPOINTS];

uint flag = 0;
for (uint stage = 0; stage < log2(TOTALPOINTS); ++stage)
{
    bufferRG[1 - flag][groupIndex] = bufferRG[flag][i] + complex_multiply(twiddle, bufferRG[flag][i + b]);
    flag = 1 - flag;
    GroupMemoryBarrierWithGroupSync();
}

Stage 0 reads from buffer 0, writes to buffer 1. Stage 1 reads from buffer 1, writes to buffer 0. This alternates for all $\log_2 N$ stages. The final result sits in whichever buffer `flag` points to after the loop. The two buffer pairs, `bufferRG` and `bufferBA` exist because the shader processes two complex signals simultaneously, packed into the four channels of a `float4` texture. This halves the number of texture reads and compute passes needed.

Bit Reversal

For the butterfly stages to chain correctly, the input samples need to be fed in a specific order before stage 0. That order is bit reversal of the index, where the binary representation of each index is reversed and samples are shuffled accordingly. Index 1 (`001`) swaps with index 4 (`100`), for example. This reordering is a known property of the Cooley-Tukey Radix-2 algorithm, and the paper handles it as a separate permutation pass before the FFT runs. Garrett Gunnell takes a slightly different approach and skips the separate permutation pass entirely. Instead, the bit reversal is folded into the butterfly index arithmetic directly. At each stage, each thread computes the correct source indices on the fly:


uint b = TOTALPOINTS >> (stage + 1);
uint w = b * (groupIndex / b);
uint i = (w + groupIndex) % TOTALPOINTS;

`i` and `i + b` are the two input positions for this thread's butterfly. Rather than pre shuffling the data once upfront, the shader just reaches into the buffer at the correct positions at every stage. The end result is exactly the same, the reordering still happens, it is just computed inline rather than as a separate dispatch.

2 Passes: Rows then columns

A 2D FFT on an $N \times N$ texture is separable. You run the 1D FFT on every row, then run the 1D FFT on every column of the result. The shader handles both passes with a single `columnPass` constant:


if (columnPass)
    data = outputTexture.Load(int3(groupID.x, groupIndex, 0));
else
    data = outputTexture.Load(int3(groupIndex, groupID.x, 0));

When `columnPass` is 0, each thread group processes one row. When `columnPass` is 1, it processes one column. The dispatch is called twice from the CPU with the constant toggled between passes.

The complete FFT shader


groupshared float2 bufferRG[2][TOTALPOINTS];
groupshared float2 bufferBA[2][TOTALPOINTS];

[numthreads(TOTALPOINTS, 1, 1)]
void main(uint3 dispatchThreadID : SV_DispatchThreadID, uint3 groupID : SV_GroupID, uint groupIndex : SV_GroupIndex)
{
    float4 data;
    if (columnPass)
        data = outputTexture.Load(int3(groupID.x, groupIndex, 0)); // column: x fixed, y varies
    else
        data = outputTexture.Load(int3(groupIndex, groupID.x, 0)); // row: x varies, y fixed

    bufferRG[0][groupIndex] = data.rg;
    bufferBA[0][groupIndex] = data.ba;

    GroupMemoryBarrierWithGroupSync();
    
    uint flag = 0;
    for (uint stage = 0; stage < log2(TOTALPOINTS); ++stage)
    {
        uint b = TOTALPOINTS >> (stage + 1);
        uint w = b * (groupIndex / b);
        uint i = (w + groupIndex) % TOTALPOINTS;

        float angle = -2.0f * PI * float(w) / float(TOTALPOINTS);
        float2 twiddle = float2(cos(angle), -sin(angle));

        bufferRG[1 - flag][groupIndex] = bufferRG[flag][i] + complex_multiply(twiddle, bufferRG[flag][i + b]);
        bufferBA[1 - flag][groupIndex] = bufferBA[flag][i] + complex_multiply(twiddle, bufferBA[flag][i + b]);

        flag = 1 - flag;
        GroupMemoryBarrierWithGroupSync();
    }

    float2 resultRG = bufferRG[flag][groupIndex];
    float2 resultBA = bufferBA[flag][groupIndex];

    if (columnPass)
        outputTexture[int2(groupID.x, groupIndex)] = float4(resultRG, resultBA);
    else
        outputTexture[int2(groupIndex, groupID.x)] = float4(resultRG, resultBA);
}

Putting all this together, after both passes complete we have converted our wave spectrum from the frequency domain into real spatial data. Before we can use this data to displace our vertices, we need to apply one last step to correctly arrange it.

Permuting the FFT Output

Before we can use the FFT results, we need to apply two final steps: centering the output and unpacking our signals.

Centering the spectrum

The raw FFT output places the zero frequency component in the corner of the texture. For our ocean patch this means the waves are arranged awkwardly, with the lowest frequencies split across opposite corners. We fix this by the following permute function:


float4 Permute(float4 data, float3 id)
{
    return data * (1.0f - 2.0f * ((id.x + id.y) % 2));
}

This flips the sign of every other texel in a checkerboard pattern, which has the effect of shifting the zero frequency component from the corner to the center. After this step the wave frequencies are arranged symmetrically, which is what we need for a correct tileable patch.

Unpacking the signals

Back in the wave animation pass we packed multiple signals into two float4 textures to save GPU passes. Now we unpack them:


float2 dxdz   = htildeDisplacement.rg;  // horizontal displacement in X and Z
float2 dydxz  = htildeDisplacement.ba;  // vertical displacement Y, and the Dxz cross derivative
float2 dyxdyz = htildeSlope.rg;         // surface slopes in X and Z, used for normals
float2 dxxdzz = htildeSlope.ba;         // second derivatives Dxx and Dzz, used for the Jacobian (Expanded upon in Chapter 3)

Applying choppiness

The horizontal displacements are scaled by a factor called Lambda before being applied to the mesh. Lambda controls how choppy the waves look. A value of 0 gives smooth rolling swells, higher values push the wave crests forward to create the sharp peaked shapes you see on a real ocean surface.


float3 displacement = float3(Lambda.x * dxdz.x, dydxz.x, Lambda.y * dxdz.y);

The slopes used for normal calculation get a Lambda correction too. In areas of strong horizontal displacement the surface is being stretched and compressed, which would cause the normal map to produce incorrect results without accounting for it:


float2 slopes = dyxdyz.xy / (1 + abs(dxxdzz * Lambda));

Finally we store this data in their corresponding textures:


slopeTexture[dispatchThreadID.xy] = float4(slopes, 0.0f, 1.0f);
displacementTexture[dispatchThreadID.xy] = float4(displacement, 0.0f);

With this, the hard part is behind us. Take a look at the contents of the texture, it should look something like this:

You’ve succesfully created the slope and displacement textures! In the next chapter I will show you how to use these textures to render the Ocean.

Chapter 2 Rendering & Shading

2.1 Vertex Displacement

At this point we have two textures coming out of the permute pass: a displacement texture and a slope texture. The displacement texture holds the XYZ offset to apply to each vertex. The slope texture holds the surface derivatives we need to reconstruct the surface normal in the pixel shader.

The ocean mesh is just a flat grid of vertices. In the vertex shader, each vertex samples the displacement texture and adds the result to its position. The UV coordinates are derived from world-space position divided by the patch size.


float2 uv = data.Position.xz / patchSize;

float3 displacement = DisplacementTexture.SampleLevel(linearWrapSampler, uv, 0).rgb;

displacedPosition += displacement;

Make sure you use a WRAP sampler here, not CLAMP. With CLAMP, every vertex outside the [0,1] UV range samples the border value and you end up with a completely flat ocean.

2.2 Normal Reconstruction & Shading

In the pixel shader, sample the slope texture using the same world-space UV. Reconstructing the surface normal from the slopes is a single line:


float2 uv = IN.PositionWS.xz / patchSize;
float4 slope = SlopeTexture.Sample(anisotropicSampler, uv);
float3 normal = normalize(float3(-slope.x, 1.0f, -slope.y));

This gives you a smooth normal that captures all the surface detail baked into the slope texture. From here you can use this normal however you like, whether that is a simple diffuse and specular shading model or a full PBR setup. My implementation uses PBR with GGX specular, Image Based Lighting and a subsurface scattering approximation at wave crests, all of which I may cover in a future post.

If everything is wired up correctly you should have a shaded animated ocean.

References

Tessendorf, J. (2001). Simulating Ocean Water. SIGGRAPH Course Notes.
Christopher J. Horvath
GarrettGunnell.
gasgiant.
Fynn-Jorin Flügge.
Bolba, G. Ocean rendering blog post.

Creating a Deferred Renderer

Fri, 17 Jan 2025 09:05:23 +0000

A simple implementation of Deferred Rendering.

Introduction

Hello there! In this blog post I will be explaining what deferred rendering entails and how you can start implementing it yourself. Since my personal project is under NDA, I will not be diving into specifics, but i will give a broad explanation on how to approach the subject in the API of your choice.

Prerequisites

To implement a deferred pipeline, I’m assuming a basic understanding of a modern graphics API such as OpenGL, Vulkan or DirectX 12. I’m also assuming some experience writing shaders using HLSL or GLSL. If this is not the case, don’t worry. The following tutorial will still give you great insight on the idea behind a deferred renderer and is not code heavy.

What is Deferred Rendering?

A deferred pipeline is essentially the separation between rendering geometry and applying light calculations to this geometry. In a normal forward rendering pipeline, geometry is rendered to the scene and every pixel of its vertices gets shaded in the same pass. The difference is that in a deferred pipeline, the first pass, often referred to as the ‘geometry pass’ will render all objects to the screen and store scene data in the G-Buffer (more on this later). After the geometry pass, we go through the ‘light pass’. In this pass we use the data stored in the G-Buffer to shade the final pixel of objects rendered to the screen. Finally we could opt to create more passes such as light passes for different types of lighting and a transparent pass for transparent objects. I will elaborate on the reasoning behind these passes later in the article.

Why would I even bother implementing a deferred pipeline?

The downside of the forward rendered pipeline is that all pixels of the objects get shaded, even the pixels that get overlapped with other geometry. This results in a lot of wasted calculations. The deferred approach is beneficial since by using a deferred pipeline, we render all geometry of the scene to the screen, and only apply lighting calculations on the final rendered pixels. By doing this, we drastically decrease the amount of calculations needed to light the scene since the amount of pixels calculated is now fixed. In a forward pipeline, we could render 2-3 lights while maintaining 60fps, with a deferred pipeline we can render thousands of lights without dropping below 60fps. (** will add profiling information)

Benefits and detriments.

The deferred pipeline also has some downsides. Setting up a deferred rendering pipeline is harder to setup compared to the standard forward rendered brother. Deferred rendering is also only beneficial in certain cases where the the separation of the geometry pass and the light pass outweigh the overhead created by the G-Buffer. Deferred rendering shines because of its scalability with the amount of lights, but it’s not ideal when:

Rendering transparent objects

since only the final visible pixel is rendered to the screen, all other pixels are discarded.
Memory and bandwidth

The deferred pipeline uses a G-Buffer which uses a large chunk of memory and bandwidth since it holds n amount of screen size textures which need to get written to and read from constantly.
Single light or low light count

If the scene does not use a lot of lights, the overhead from creating, reading and writing to the G-Buffer will not be worth it.
Anti Aliasing

MSAA is difficult because of the G-Buffer. With MSAA, each pixel would require multiple samples from the G-Buffer attributes, drastically increasing memory usage. From aortiz: “Another major flaw is that there is no easy way to make use of hardware based anti-aliasing(AA) techniques like Multi-Sampled Anti-Aliasing (MSAA).“
Lighting Algorithms constrains

Forces you to use the same lighting algorithm for most of your scene’s lighting.
Opting for a deferred pipeline is beneficial when:
Rendering a lot of lights.
Rendering high geometrically complex objects.
Post processing flexibility.

By processing geometry only once during the geometry pass, deferred rendering avoids redundant calculations for geometry that would otherwise not be visible. The light pass operates only on visible pixels, independent of scene complexity. Use cases could be when rendering open world scenes with overlapping geometry, for example a dense forest.

Post processing becomes easier because screen space data needed is already stored in the G-Buffer. This simplifies implementation of effects like SSAO ( Screen Space Ambient Occlusion ), Motion Blur and Depth of Field.

The G-Buffer.

We create a G-Buffer which holds Render Targets. These Render Targets, can be written to in a pixel shader. In this shader we store attribute data in a big buffer. We need this data to do the light calculations in the light pass later on. The data stored in a G-Buffer varies from implementation to implementation, but generally it will hold the following:

Position Data
Albedo Data
Normal Data
Depth Information

** When using Blinn-Pong as the shading model, the specular intensity is also stored here. (source LearnOpenGL)

These buffers should be linked to textures so we can use them in other shaders.

Implementation.

The General Idea

To implement a deferred pipeline we need to do a few things. First of all we need to create 3 Render Targets, one for each attribute mentioned above. We need to enable writing to these Render Targets, and we need to create a separate Render Target Mask for the G-Buffer. This mask needs to get initialized with the previously created Render Targets. Finally when switching between passes, you want to set the correct Render Target to output to. More on this later.

The next step is to separate the pipeline into multiple passes. A geometry pass where we load all geometry vertices into the vertex shader and render the geometry to the scene. In the pixel shader of this pass we also fill the G-Buffer attributes. Positions get filled with the world space positions of the mesh, normals with the normals provided by the mesh ( or calculated using normal mapping ), and finally the albedo texture gets sampled and its data stored in the corresponding buffer.

The light pass.

After the geometry pass, we want to create a light pass with its own set of shaders. In this example i will on two variations of the implementation. A simple way to implement this, would be to render a quad to the screen using the vertex shader and sampling the G-Buffer in the pixel shader to do the lighting calculations. This works, and is already an improvement in regards of a forward rendered pipeline, but in this case we do no light culling. We can optimize this further. Light culling is important because of distance attenuation, where for example, the light of a lighter should not affect an object 50km away. Even if you add an attenuating function, there will always be some light contribution, even if its very minimal. Now you might ask yourself.. “What if i just add an if statement for when the light is past a certain threshold?” This would indeed solve that issue, but having an if statement in the pixel shader is expensive considering it would have to be done for every light on every pixel. Thing brings us to the topic of light culling.

Light culling is extremely important in a deferred rendering pipeline considering we intend to render a lot of lights. After some research i came to the conclusion that there are 2 good ways to do this, clustered shading and bounding volume culling. I will be covering the volume culling. To do this we want to render spheres into the scene. By sending sphere vertex positions to the vertex shader, the pixel shader will only consider the pixels within these spheres for the lighting calculation. The benefit of this is that now, the pixel shader will not iterate over every pixel, but only the pixels we are interested in.

In the image below, i rendered many spheres to encompass the desired geometry. Only the geometry within the grey sphere volumes get shaded. The geometry located at my mouse position does not get shaded.

Another important note is that these spheres scale with their radius. In my example the radius is 1 so i need more lights, a smoother approach would be to make the radius bigger.

To find the UV coordinates of the affected pixels, we apply the following math formula:

    // This is a perspective divide.
	// The hardware does this divide automatically when calculating the fragment location on the screen
	float2 screenUV = input.screenPos.xy/input.screenPos.w;

	// Changes coordinate frame from [-1;1] to [0; 1]
	screenUV = (screenUV + float2(1.0)) / 2.0f;
	
	// Flips the vertical coordinate
	screenUV.y *= -1;

This provides us with the screen coordinates affected by the spheres. Don’t worry too much about the math behind it if you don’t understand it. If you are interested in reading more about it, i would recommend the following source.

Now we can use these UV’s to sample the G-Buffer data.

// retrieve data from G-buffer
    float3 FragPos = texture(gPosition, TexCoords).xyz;
    float3 Albedo = texture(gAlbedoSpec, TexCoords).xyz;
    float3 Normal = texture(gNormal, TexCoords).xyz;

Final Pass

In the final pass we want to render a quad to the screen and sample the data previously written to G-Buffer. This is the easiest part since it only requires us to sample the texture with all previous light calculations and output it to the screen.

float4 main(V2P input)
{
	float4 result;

	result = texture(gFinal, TexCoords);

	return result;
}

Switching between passes

First of all its important to make sure we sync the GPU before rendering anything to the screen with each pass.

Geometry pass setup: Have all G-Buffer render targets available for writing. If you don’t, the buffers left out will not be filled, resulting in undefined behavior. Also make sure that the selected Render Target Mask is the G-Buffer mask created earlier. This pass uses a simple Depth Stencil Control.

Light pass setup: When switching to the light pass its important you set the Render Target Mask to the mask created for the initial (not G-Buffer) Render Target. Additionally you want to set a designated Final G-Buffer as the Render Target to output to since the result of the pixel shader will be stored in this G-Buffer slot. Finally we need to setup the correct Depth Stencil Control. In this pass we do not want to write with depth, but it depth testing itself should be enabled.

Final pass setup: For the final pass we want to select the initial Render Target and Render Target Mask again. Here we do not use the G-Buffer. Finally for Depth Stencil Control, we want all depth testing and depth writing to be disabled. In this pass we render to a 2D quad.

Alternative passes

In my implementation i only went over the point light pass. Ideally we create a separate shader as well to handle direct lighting. We do this to avoid something called an ‘uber-shader’ which is a big shader which handles all calculations. Aortiz Alguero phrases it as follows: “And therein lies the biggest perk of deferred shading, it reduces the number of responsibilities of a shader through specialization. By dividing the work between multiple shader programs we can avoid massively branching “uber-shaders” and reduce register pressure — in other words, reduce the amount of variables a shader program needs to keep track of at a given time.”

If we want to render transparent objects we need to add another pass which handles this. As the deferred pipeline does not support this, which means these objects need to be forward rendered.

Further Optimizations

The deferred pipeline allows us to perform certain optimizations.

We can utilize light culling techniques such as clustered shading, to further optimize our renderer. I have not implemented this myself yet, but the general idea behind this optimization is that we divide the view frustrum into 3D grids and we quickly calculate a list of lights intersecting each volume of this grid. A beautiful article elaborating this optimization is found In this article.

We can reconstruct the world position of the object using the depth buffer. The main benefit here is that the G-Buffer becomes smaller. Storing the position of each pixel directly in the G-buffer requires storing three 32-bit components (X, Y, Z). Reconstructing the positions will in turn save a lot of memory. This in turn also reduces the bandwidth required to read and write from the G-Buffer. This would look something like this:

 float3 CalculatePosFromDepth(float screenX, float screenY, float screenZ)
{
	screenY *= -1;
    
    // NDC are the normalized device coordinates from -1 to 1
	float ndcX = (2.0f * screenX) - 1.0f;
	float ndcY = (2.0f * screenY) - 1.0f;
	float ndcZ = screenZ;

	float4 clipCoords = float4(ndcX, ndcY, ndcZ, 1.0f);

	// Inverse projection
	float4 viewCoords = mul(Camera->invertedProj, clipCoords);

	// Inverse view transformation
	float4 worldCoords = mul(Camera->invertedView, viewCoords);

	// Extract the world position (x, y, z)
	return worldCoords.xyz / worldCoords.w;
}

An article explaining this in more detail In this article.

Finally we can look into occupancy

Occupancy is essentially how well the GPU can hide memory latency. The GPU will break down tasks into wavefronts and assign these wavefronts to SIMD to operate on. Multiple wavefronts can be assigned to a single SIMD, but only 1 wavefront can be executed at time. Afterwards the GPU can switch between wavefronts when one of the wavefronts is waiting for data to be loaded from memory.

Source of the image.

Ideally the SIMD is never idle. For this to happen, the SIMD should have as many wavefronts attached to it as possible. If a SIMD can hold for example 16 wavefronts, it is in a better position to hide latency when it has 16 wavefronts assigned to it (occupancy is 16/16 = 100%), than if it has only 1 wavefront assigned (occupancy of 1/16). If this 1 wavefront is waiting for data to be fetched from memory, the GPU can not switch wavefronts and do other computations while waiting.

Adittionally, occupancy is only beneficial in cases where data needs to be loaded. This means that if there are workloads where the wavefronts only do calculations without needing to look up data from memory, the workload would not benefit from increased occupancy. Higher occupancy is ideal when a workload needs to load data from memory, do computations on this data and then store it.

Finally occupancy can be limited because of a few factors. The Vector General Purpose Registers (VGPR), the Local Data Share (LDS) and the Thread Group Size. Your GPU profiler will tell you what is limiting your occupancy.

Now that we understand what occupancy is, how do we influence it to optimize our program? In my case for example my occupancy was limited by the VGPR’s. I was using 36 VGPR’s which causes a Tail Effect. The tail effect occurs when the total number of threads is not divisible by 32. If we have 40 threads, we would need 2 wavefronts to assign these threads. the last wavefront would only be using 8 threads. This leads to slower program execution. To reduce the amount of VGPR’s, you want to reuse variables in the shader instead of creating new ones for intermediate calculations. You should also avoid using vectors where possible and use scalars instead. For example:

// Inefficient: Unnecessary vector size
vec4 color = vec4(1.0, 0.0, 0.0, 1.0);
vec4 PixelColor = color;

// Better: Use individual scalars
float r = 1.0; 
float g = 0.0; 
float b = 0.0; 
float a = 1.0;
PixelColor = vec4(r, g, b, a);

This is the article where i learned about Occupancy if you want to read more in depth about it.

Conclusion.

To conclude, a deferred renderer is an amazing optimization when it comes to complex geometry or a scene with a lot of lights. It scales well with lights and does not waste cycles computing pixels that will never make it on the screen. It has it’s flaws such as constantly reading and writing to the G-Buffer, but this overhead quickly becomes worth it with the right geometrical and lighting conditions mentioned above. The deferred pipeline also makes post processing effects easier since the G-Buffer already contains most data needed, and also allows for further optimizations in for example light clustering.

That concludes the basic implementation of a deferred pipeline. I hope it was useful to you whether you are an experienced graphics programmer, someone looking for a new challenge or just a curious reader. If you happen to have any questions or corrections, feel free to leave a comment.

Future work

In the future i intend to optimize the project more and add light clustering. Once that is implemented i will update this article with my findings on the subject as well.

Tutorial

Posts by Category : {{ page.title }}

{% for post in site.categories.sample_category %}

{% endfor %}

Security Policy

# Security Policy ## Supported Versions Use this section to tell people about which versions of your project are currently being supported with security updates. | Version | Supported | | ------- | ------------------ | | 5.1.x | :white_check_mark: | | 5.0.x | :x: | | 4.0.x | :white_check_mark: | | < 4.0 | :x: | ## Reporting a Vulnerability Use this section to tell people how to report a vulnerability. Tell them where to go, how often they can expect to get an update on a reported vulnerability, what to expect if the vulnerability is accepted or declined, etc.

Change Log

# Change Log All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/) and this project adheres to [Semantic Versioning](http://semver.org/). **Note that references to the Font-Awesome-Pro repository refer to a GitHub repository that is by invitation only. You will get a 404 - Not Found if you do not have access** --- ## [5.1.0](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.1.0) - 2018-06-20 **Minor version upgrade notice: there are some backward-incompatible changes to this release. See the [UPGRADING.md guide](https://github.com/FortAwesome/Font-Awesome/blob/master/UPGRADING.md) for more information.** ### Added * New Emoji, Design, and Travel category pack * Another group of requested and commissioned icons * Version 4 shim for Web Fonts with CSS * New simplified download and NPM packages * @fortawesome/fontawesome-free and @fortawesome/fontawesome-pro NPM packages that match what's available in the CDN and .ZIP files * Brand icons rev, nimblr, megaport, mailchimp, hornbill, wix, weebly, themeco, squarespace, aws, shopware * API method toHtml() for converting abstract objects to HTML * API method counter() to generate Layers Counters * API method watch() to configure MutationObserver and watch DOM for icon changes and additions ### Changed * Relocating sponsor data to a separate sponsors.yml * Updated teamspeak brand icon * No more default exports in the CommonJS/ES packages (anything installed from NPM) * Greatly improved performance and rendering of CSS pseudo-elements with SVG and JavaScript * Configuration of SVG with JavaScript can now be done with attributes on the script tag * SVG with JavaScript pseudo-elements now match syntax (font-family, font-weight) of Web Fonts with CSS ### Fixed * Tree shaking of all NPM packages by default * Alignment of the book-open and dice-six icon * Correcting creative-commons * Incorrect license on the fontawesome-common-types package * Improve ligatures that share a base name with another ligature * Correcting solid style of the digital-tachograph icon * Prevent duplicating classes in some scenarios with SVG with JavaScript * Duplicate insertion of CSS when insertCss() method was called * Missing TypeScript definitions for the free-brands-svg-icons package --- ## [5.0.13](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.13) - 2018-05-10 ### Added * 68 icons to Free and 165 to Pro of the most requested icons in Font Awesome --- ## [5.0.12](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.12) - 2018-05-03 ### Added * A long time ago in a galaxy far, far away some icons were added ### Fixed * Renamed the r brand to r-project to prevent ligature collision with the "r" glyph --- ## [5.0.11](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.11) - 2018-05-01 ### Added * 16 new user icons * Full set of Creative Commons symbols * Regular style comment-dots used for v4 comment-alt in shim * Top 6 brand icons: r, ebay, mastodon, researchgate, keybase, teamspeak ### Changed * Revised slider icons FortAwesome/Font-Awesome#11872 * Make desktop typeface easier to find in apps that support ligature previews ### Fixed * Remove errant XML entity from the lastfm-square icon FortAwesome/Font-Awesome#12847 * Correcting paths in cloud icons FortAwesome/Font-Awesome-Pro#920 --- ## [5.0.10](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.10) - 2018-04-10 ### Added * New java brand icon FortAwesome/Font-Awesome#386 ### Changed * Updating depth of dna icon * Updating pied-piper, adding pied-piper-hat ### Fixed * Correcting path errors on readme icon FortAwesome/Font-Awesome#12754 * Light style of lamp icon FortAwesome/Font-Awesome#12725 --- ## [5.0.9](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.9) - 2018-03-27 ### Added * New Chat icon pack and category * New Charity icon pack and category * New Moving icon pack and category * New icons hands and hand-holding ### Changed * Updated flipboard, readme, and houzz brand icon * Making all solid icons in the medical icon pack free * Updated hand-holding-box and hand-receiving in the Light style ### Fixed * Missing box-sizing CSS property for fa-layers-counter --- ## [5.0.8](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.8) - 2018-03-01 ### Fixed * OTF font files missing ligatures for Pro styles FortAwesome/Font-Awesome#12486 FortAwesome/Font-Awesome-Pro#1034 --- ## [5.0.7](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.7) - 2018-02-26 ### Added * New Logistics category * New Medical category * Individual SVG files available from the Font Awesome CDN * Additional search terms ### Changed * Apple brand icon update FortAwesome/Font-Awesome#12337 * Disable mutation observers with fontawesome.noAuto() is called * License information now references https URL scheme ### Fixed * Missing TypeScript names FortAwesome/react-fontawesome#83 * Adding categories metadata FortAwesome/Font-Awesome#12034 * TypeScript improvement for fontawesome.layer() * Correcting a melting, wobbling, weird-looking whistle --- ## [5.0.6](https://github.com/FortAwesome/Font-Awesome/releases/tag/5.0.6) - 2018-01-25 ### Fixed * @fortawesome/fontawesome-pro-light missing submodules --- ## [5.0.5](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.5) - 2018-01-25 ### Added * New Sports category * New Chess category * Added brand icons for flipboard, php, quinscape, and hips ### Fixed * Sass and Less mixin fa-icon() now uses ems instead of percentage * Corrected misspelling of "Alternate" in category labels * Improved TypeScript definitions for @fortawesome/fontawesome * Server-side rendering was failing due to DOM-specific object access * SVG attributes "data-fa-processed" renamed to "data-fa-i2svg", only applies if rendered with i2svg() method --- ## [5.0.4](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.4) - 2018-01-10 ### Changed * Updating all NPM package READMEs ### Fixed * Improving TypeScript exports and fixing some incorrect definitions * TypeScript error when importing entire style Fort-Awesome/Font-Awesome#12072 * Pseudo-elements erasing text contents in parent container Fort-Awesome/Font-Awesome-Pro#11995 * fa-layers-text misalignment when using Bootstrap Fort-Awesome/Font-Awesome#11871 --- ## [5.0.3](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.3) - 2018-01-08 ### Added * Adding elementor, youtube-square brand icons * Adding window-minimize to the Free subset * TypeScript support for all NPM packages ### Fixed * Corrected uneven spacing in university, address-book, address-card, id-badge, id-card, mouse-pointer, phone-volume, portrait, user-alt, user-circle, user-md, user-plus, user-times, user , users * Corrected uneven spacing in brand icons behance-square, dashcube, discourse, ember, erlang, fort-awesome, js-square, laravel, mix, patreon, palfed, phoenix-framework, node-js, skyatlas, stack-exchange, stripe, viber, weixin, yahoo , yoast --- ## [5.0.2](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.2) - 2017-12-19 ### Added * Adding amazon-pay, cc-amazon-pay, korvue, ethereum brand icons * Adding stopwatch to Free version ### Changed * Ligatures now support capital case, all caps, and title case ### Fixed * NPM packages now behave the same way as CDN and browser-specific packages FortAwesome/Font-Awesome-Pro#727 FortAwesome/Font-Awesome-Pro#896 FortAwesome/Font-Awesome-Pro#891 * Icon doesn't change when pseudo-element content changes FortAwesome/Font-Awesome-Pro#839 * Invalid XML in sprites FortAwesome/Font-Awesome-Pro#927 * Incorrect version in Sass and Less variable files --- ## [5.0.1](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.1) - 2017-12-08 ### Added * Adding font-awesome-flag, lock-open, redo-alt, sync-alt, undo-alt to the Free version * New NPM packages `fontawesome-free-webfonts` and `fontawesome-pro-webfonts` * Adding old icon names to search terms for renamed icons * Extensive metadata added to the `advanced-options` directory * Adding stripe-s brand icon * Adding typo3 brand icon ### Changed * Updated dropbox brand icon to match new branding guidelines * Updated firefox brand icon * Updated strava brand icon * OTF font file now include a space character ### Fixed * OTF font file now supports different styles in Windows * OTF font file "j" character now has correct space on the right * Modifying the `class` attribute on an existing `` will now precede other link and style definitions * BREAKING `fontawesome.text` and `fontawesome.icon` now use `styles` param instead of `style` * Updated sizing for twitter, discord, youtube * Class fa-li now respects line-height and has new recommended markup (see included docs) ### Fixed * Duplicate `style` tags being added in the head FortAwesome/Font-Awesome-Pro#858 * Error with icon composition/masking that caused a confusing error message * An error when using pseudo elements and the element is empty (Array.reduce error) * Icons not being replaced with SVG if the text content is not empty --- ## [5.0.0-rc4](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-rc4) - 2017-10-27 ### Added * Ligature support in the OTF font * Vue.js brand icon * Sass and Less brand icons * Autoprefixer brand icon * Individual icon imports in icon packages FortAwesome/Font-Awesome-Pro#808 ### Changed * Better poo eyes * Renamed HTML status classes to `fontawesome-i2svg-active`, `fontawesome-i2svg-pending`, `fontawesome-i2svg-complete` * HTML status class for active is added only after the first batch of icon replacements occur * Added mention of newer versions of iOS in documentation FortAwesome/Font-Awesome-Pro#810 ### Fixed * Performance and missing features with mutation observer (should fix FortAwesome/Font-Awesome-Pro#813) * Incorrect handling of icon class and style attributes when using autoReplace = 'nest' FortAwesome/Font-Awesome-Pro#809 * Pseudo elements not added or removed when class mutations occur FortAwesome/Font-Awesome-Pro#821 --- ## [5.0.0-rc3](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-rc3) - 2017-10-13 ### Added * Node.js brand icon FortAwesome/Font-Awesome-Pro#779 * React brand icon FortAwesome/Font-Awesome-Pro#780 * OSI brand icon FortAwesome/Font-Awesome-Pro#748 * Add a class to the html element when icon replacement is complete FortAwesome/Font-Awesome-Pro#778 * Add support for symbols in API including ability to name the symbol * Use CSS pseudo elements (:before and :after) to make trigger SVG replacements ### Changed * Switched the locations of fork and knife in utensils-alt FortAwesome/Font-Awesome-Pro#466 * Updated the AWS brand icon FortAwesome/Font-Awesome-Pro#735 * Updated Apple App Store icon FortAwesome/Font-Awesome-Pro#728 ### Fixed * Do not throw an error if icon is missing when calling icon() method in API * Ensure that unicode values do not change between releases * Version field is missing in fontawesome-pro-brands/package.json FortAwesome/Font-Awesome-Pro#781 * Repeated commenting out of fa-layers when i2svg is called FortAwesome/Font-Awesome-Pro#788 * Title not showing up correctly for SVG FortAwesome/Font-Awesome-Pro#786 --- ## [5.0.0-rc2](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-rc2) - 2017-09-22 ### Added * Brand icons: accusoft, ns8, uniregistry ### Fixed * Link to the npm package in the docs FortAwesome/Font-Awesome-Pro#729 * Incorrect reference to fontawesome-pro.js in docs --- ## [5.0.0-rc1](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-rc1) - 2017-09-15 ### Changed * New Bitbucket logo FortAwesome/Font-Awesome-Pro#720 * Modifed the star icons to match use case better FortAwesome/Font-Awesome-Pro#710 * Switched names of css3 and css3-alt to reflect correct branding ### Fixed * Correct whitespace with the Visa logo FortAwesome/Font-Awesome-Pro#719 * Improve OTF support by passing through FontForge FortAwesome/Font-Awesome-Pro#565 * Fonts with "undefined" name FortAwesome/Font-Awesome-Pro#711 * Shims will only function if using old prefix of "fa" FortAwesome/Font-Awesome-Pro#692 * Added missing "youtube" icon to categories --- ## [5.0.0-beta7](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta7) - 2017-09-11 ### Added * Ability to nest the `` FortAwesome/Font-Awesome-Pro#624 * Define icons as symbols and leverage SVG sprites FortAwesome/Font-Awesome-Pro#629 * Added alternative CSS3 logo FortAwesome/Font-Awesome-Pro#682 ### Changed * Power Transforms now execute inside the SVG instead of on the root element * Filenames have changed to reflect a better division between Font Awesome Free and Pro ### Fixed * More improvements to the version 4 shim FortAwesome/Font-Awesome-Pro#673 FortAwesome/Font-Awesome-Pro#678 FortAwesome/Font-Awesome-Pro#686 FortAwesome/Font-Awesome-Pro#687 FortAwesome/Font-Awesome-Pro#692 * Animation support for inline SVG now works as expected FortAwesome/Font-Awesome-Pro#662 --- ## [5.0.0-beta6](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta6) - 2017-09-01 ### Added * Ability to flip horizontal and vertical with CSS classes fa-flip-horizontal and fa-flip-vertical * New film-alt icon that allows for layering other icons * Microsoft brand ### Changed * New YouTube branding FortAwesome/Font-Awesome-Pro#646 ### Fixed * Fixed a bunch of shim-related issues * Cogs off center FortAwesome/Font-Awesome-Pro#663 * Corrected icons/categories.yml with canonical names --- ## [5.0.0-beta5](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta5) - 2017-08-25 ### Added * Full parity with Font Awesome 4! 616 total core icons in each style * 297 total brand and logo icons * Separate CSS file to accompany the SVG Framework FortAwesome/Font-Awesome-Pro#627 * Alternative to the dots icon FortAwesome/Font-Awesome-Pro#608 * Made window icons consistent FortAwesome/Font-Awesome-Pro#611 ### Fixed * Production builds not correctly being detected FortAwesome/Font-Awesome-Pro#631 --- ## [5.0.0-beta4](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta4) - 2017-08-18 ### Added * 590 total core icons in each style * 291 total brand and logo icons ### Fixed * Reduced the size of JS file from 66 to 22 kb * Regression caused by with web font alignment FortAwesome/Font-Awesome-Pro#460 --- ## [5.0.0-beta3](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta3) - 2017-08-15 ### Added * 583 total core icons in each style ### Fixed * Documentation improvements and fixes FortAwesome/Font-Awesome-Pro#586 * Vertical alignment of TTF and OTF fonts FortAwesome/Font-Awesome-Pro#460 * The "fa_500px" icon should be named "fa500px" FortAwesome/Font-Awesome-Pro#578 --- ## [5.0.0-beta2](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta2) - 2017-08-11 ### Added * 570 total core icons in each style * 291 total brand and logo icons * NPM (ES6, CommonJS, AMD) packages for use with other JavaScript libraries and tools FortAwesome/Font-Awesome-Pro#574 * Added a guide to choosing which implementation is best for you FortAwesome/Font-Awesome-Pro#532 ### Changed * Showing a missing icon is now configurable FortAwesome/Font-Awesome-Pro#569 ### Fixed * Composition framework now works in browsers that do not support transform-origin FortAwesome/Font-Awesome-Pro#564 --- ## [5.0.0-beta1](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-beta1) - 2017-08-04 ### Added * 524 total core icons in each style * 289 total brand and logo icons * New composition framework FortAwesome/Font-Awesome-Pro#537 * Animated indicator if you use an icon that does not exist ### Changed * Basic linting for Sass and Less files * Add JavaScript guard block to prevent leaking errors * Add support for automatic accessibility to SVG Framework Layers ### Fixed * Regression where stacks and pulled and bordered were not working in SVG Framework * SVG sprite example had confusing inline styles FortAwesome/Font-Awesome-Pro#549 * Make getting started page more consistent between examples FortAwesome/Font-Awesome-Pro#544 * Added missing sizes fa-[6-10], xs, sm FortAwesome/Font-Awesome-Pro#546 * Title tag missing in SVG sprites FortAwesome/Font-Awesome-Pro#536 --- ## [5.0.0-alpha7](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha7) - 2017-07-28 ### Added * 451 total core icons in each style * 281 total brand and logo icons * Less support is back! * OpenType (.otf) file formats for web fonts ### Changed * Changes the fa-spin animation to go from 0deg to 360deg to eliminate hitch FortAwesome/Font-Awesome-Pro#522 * Improved mutation handling FortAwesome/Font-Awesome-Pro#517 ### Fixed * fa-fw now works correctly with the SVG framework FortAwesome/Font-Awesome-Pro#530 * Removed execute bit on some icon files FortAwesome/Font-Awesome-Pro#520 --- ## [5.0.0-alpha6](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha6) - 2017-07-21 ### Added * 410 total core icons in each style * 270 total brand and logo icons * All new Font Awesome 4 shim file * Beginnings of a public JS API FortAwesome/Font-Awesome-Pro#512 ### Changed * Added Firefox ESR and Chrome for Businesses to browser compatibility FortAwesome/Font-Awesome-Pro#506 ### Fixed * Ensure that SVG title attributes are unique * Fixed incorrect viewBox sizes FortAwesome/Font-Awesome-Pro#492 * Fix chart-area alignment in the solid style FortAwesome/Font-Awesome-Pro#508 * Add missing xmlns attributes in some SVGs FortAwesome/Font-Awesome-Pro#509 --- ## [5.0.0-alpha5](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha5) - 2017-07-14 ### Added * 228 total brand and logo icons * New transform framework for sizing, moving, rotating, and flipping icons * New icon counters * New layers framework * New text overlays * Auto-comments with the original source icons alongside SVG replacements ### Changed * Autoprefixer to correctly add browser prefixes for supported browsers * Removed browser-specific CSS properties in Sass source files (now relies on autoprefixer) ### Fixed * The rotation on checkmark icons * Other icon feedback from previous weeks * Correct fixed width settings to 1.25em (based on the new 16px grid) * Icons displaying as block instead of inline-block in IE and older Safari --- ## [5.0.0-alpha4](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha4) - 2017-07-07 ### Added * 93 brand icons --- ## [5.0.0-alpha3](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha3) - 2017-06-30 ### Added * 95 additional icons; including file types, directional, and some existing and new brand icons ### Fixed * Wrong content type in generated CSS FortAwesome/Font-Awesome-Pro#458 * Removal of query string from static resources FortAwesome/Font-Awesome-Pro#458 * SVG font ID's are incorrect in webfont implementation FortAwesome/Font-Awesome-Pro#474 --- ## [5.0.0-alpha2](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha2) - 2017-06-27 ### Added * How/When to upgrade from FA4 to FA5 FortAwesome/Font-Awesome-Pro#454 ### Fixed * Links to SVG files broken in the example files FortAwesome/Font-Awesome-Pro#456 * Misnamed icon names in examples FortAwesome/Font-Awesome-Pro#445 * Mangled HTML in the Getting Started example FortAwesome/Font-Awesome-Pro#442 * Bad grammar and typos FortAwesome/Font-Awesome-Pro#443 * fas-arrow-to-top is identical to fas-arrow-to-right FortAwesome/Font-Awesome-Pro#423 * Vertical alignment issues with webfont implementation FortAwesome/Font-Awesome-Pro#444 * Add browser compatibility tables to demo FortAwesome/Font-Awesome-Pro#435 * Remove MAC OS feces from builds FortAwesome/Font-Awesome-Pro#437 * TTF naming issues that prevent correct usage/installation FortAwesome/Font-Awesome-Pro#450 * Correct CSS for SVG framework stacking, was reversed from normal FortAwesome/Font-Awesome-Pro#452 --- ## [5.0.0-alpha1](https://github.com/FortAwesome/Font-Awesome-Pro/releases/tag/5.0.0-alpha1) - 2017-06-23 ### Added * 300+ more icons * Brands pack * New JavaScript based SVG Framework * New SVG Sprites based framework * Source SVGs * Documentation with a convenient build-in web server ### Changed * New directory structure

Upgrading Guide
# Upgrading Guide See the [CHANGELOG.md](/assets/bower_components/font-awesome/CHANGELOG/) for detailed information about what has changed between versions. This guide is useful to figure out what you need to do between breaking changes. As always, [submit issues](https://github.com/FortAwesome/Font-Awesome/issues/new) that you run into with this guide or with these upgrades to us. ## 5.0.x to 5.1.0 ### New packages available for browser-only integration **If you were previously using @fortawesome/fontawesome you need to switch to one of the new packages.** Our Free and Pro CDN provide access to JS, CSS, sprites, and separate SVG files. We've now made these files conveniently available through NPM. * [@fortawesome/fontawesome-free](https://www.npmjs.com/package/@fortawesome/fontawesome-free) * @fortawesome/fontawesome-pro (private package, requires Pro subscription) If you are familiar with the paths and options available with the CDN these packages should be familiar. Information about [Font Awesome Pro subscriptions](https://fontawesome.com/pro) can be found in your [Font Awesome awesome account](https://fontawesome.com/account/services). ### Renamed packages The following packages have been renamed as part of 5.1.0 of Font Awesome. _All packages are in the [@fortawesome NPM scope](https://www.npmjs.com/search?q=scope:fortawesome&page=1&ranking=optimal)_ | Old package(1) | New package | |---------------------------|------------------------| | fontawesome-free-webfonts | fontawesome-free | | fontawesome-pro-webfonts | fontawesome-pro | | fontawesome-free-solid | free-solid-svg-icons | | fontawesome-free-regular | free-regular-svg-icons | | fontawesome-free-brands | free-brands-svg-icons | | fontawesome-pro-solid | pro-solid-svg-icons | | fontawesome-pro-regular | pro-regular-svg-icons | | fontawesome-pro-light | pro-light-svg-icons | (1) Old packages have now been deprecated. They are still available but will only receive high priority patch release fixes. **You'll need to update your package.json file with the renamed packages and new versions.** ### No more default imports Recently we spent a good deal of time supporting TypeScript to enable us to create the Angular Font Awesome component. During that adventure we [were](https://basarat.gitbooks.io/typescript/docs/tips/defaultIsBad.html) [convinced](https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad) that we were going to remove default exports from all of our components, libraries, and packages. This is complete with the umbrella release of `5.1.0` of Font Awesome. What does that mean? ~~Old way:~~ ```javascript import fontawesome from '@fortawesome/fontawesome' import solid from '@fortawesome/fontawesome-free-solid' import faTwitter from '@fortawesome/fontawesome-free-brands/faTwitter' import FontAwesomeIcon from '@fortawesome/vue-fontawesome' library.add(solid, faTwitter) ``` New way: ```javascript import { library, dom } from '@fortawesome/fontawesome-svg-core' import { fas } from '@fortawesome/free-solid-svg-icons' import { faTwitter } from '@fortawesome/free-brands-svg-icons' import { FontAwesomeIcon } from '@fortawesome/vue-fontawesome' library.add(fas, faTwitter) // Kicks off the process of finding tags and replacing with

Mouse Wheel ChangeLog
# Mouse Wheel ChangeLog ## 3.1.13 * Update copyright notice and license to remove years * Create the correct compressed version * Remove the obsolete jQuery Plugin Registry file ## 3.1.12 * Fix possible 0 value for line height when in delta mode 1 ## 3.1.11 * Fix version number for package managers... ## 3.1.10 * Fix issue with calculating line height when using older versions of jQuery * Add offsetX/Y normalization with setting to turn it off * Cleans up data on teardown ## 3.1.9 * Fix bower.json file * Updated how the deltas are adjusted for older mousewheel based events that have deltas that are factors of 120. * Add $.event.special.mousewheel.settings.adjustOldDeltas (defaults to true) to turn off adjusting of old deltas that are factors of 120. You'd turn this off if you want to be as close to native scrolling as possible. ## 3.1.8 * Even better handling of older browsers that use a wheelDelta based on 120 * And fix version reported by `$.event.special.mousewheel` ## 3.1.7 * Better handle the `deltaMode` values 1 (lines) and 2 (pages) * Attempt to better handle older browsers that use a wheelDelta based on 120 ## 3.1.6 * Deprecating `delta`, `deltaX`, and `deltaY` event handler arguments * Update actual event object with normalized `deltaX `and `deltaY` values (`event.deltaX`, `event.deltaY`) * Add `deltaFactor` to the event object (`event.deltaFactor`) * Handle `> 0` but `< 1` deltas better * Do not fire the event if `deltaX` and `deltaY` are `0` * Better handle different devices that give different `lowestDelta` values * Add `$.event.special.mousewheel.version` * Some clean up ## 3.1.5 * Bad release because I did not update the new `$.event.special.mousewheel.version` ## 3.1.4 * Always set the `deltaY` * Add back in the `deltaX` and `deltaY` support for older Firefox versions ## 3.1.3 * Include `MozMousePixelScroll` in the to fix list to avoid inconsistent behavior in older Firefox ## 3.1.2 * Include grunt utilities for development purposes (jshint and uglify) * Include support for browserify * Some basic cleaning up ## 3.1.1 * Fix rounding issue with deltas less than zero ## 3.1.0 * Fix Firefox 17+ issues by using new wheel event * Normalize delta values * Adds horizontal support for IE 9+ by using new wheel event * Support AMD loaders ## 3.0.6 * Fix issue with delta being 0 in Firefox ## 3.0.5 * jQuery 1.7 compatibility ## 3.0.4 * Fix IE issue ## 3.0.3 * Added `deltaX` and `deltaY` for horizontal scrolling support (Thanks to Seamus Leahy) ## 3.0.2 * Fixed delta being opposite value in latest Opera * No longer fix `pageX`, `pageY` for older Mozilla browsers * Removed browser detection * Cleaned up the code ## 3.0.1 * Bad release... creating a new release due to plugins.jquery.com issue :( ## 3.0 * Uses new special events API in jQuery 1.2.2+ * You can now treat `mousewheel` as a normal event and use `.bind`, `.unbind` and `.trigger` * Using jQuery.data API for expandos ## 2.2 * Fixed `pageX`, `pageY`, `clientX` and `clientY` event properties for Mozilla based browsers ## 2.1.1 * Updated to work with jQuery 1.1.3 * Used one instead of bind to do unload event for clean up ## 2.1 * Fixed an issue with the unload handler ## 2.0 * Major reduction in code size and complexity (internals have change a whole lot) ## 1.0 * Fixed Opera issue * Fixed an issue with children elements that also have a mousewheel handler * Added ability to handle multiple handlers

TODO: 1. Wasteland walkers needs its own media 2. Make Itch link standout with logo. 3. make voxel page more professional.

Fizzy UI utils
# Fizzy UI utils UI utility & helper functions Used in [Flickity](http://flickity.metafizzy.co), [Isotope](http://isotope.metafizzy.co), [Masonry](http://masonry.desandro.com), [Draggabilly](http://draggabilly.desandro.com) ## Install Bower: `bower install fizzy-ui-utils --save` npm: `npm install fizzy-ui-utils --save` ## API ``` js // fizzyUIUtils is the browser global var utils = fizzyUIUtils; // ---- ---- // utils.extend( a, b ) // extend object utils.modulo( num, div ) // num [modulo] div utils.makeArray( obj ) // make array from object utils.removeFrom( ary, obj ) // remove object from array utils.getParent( elem, selector ) // get parent element of an element, given a selector string utils.getQueryElement( elem ) // if elem is a string, use it as a selector and return element Class.prototype.handleEvent = utils.handleEvent; // enable Class.onclick when element.addEventListener( 'click', this, false ) utils.filterFindElements( elems, selector ) // iterate through elems, filter and find all elements that match selector utils.debounceMethod( Class, methodName, threhold ) // debounce a class method utils.docReady( callback ) // trigger callback on document ready utils.toDashed( str ) // 'camelCaseString' -> 'camel-case-string' utils.htmlInit( Class, namespace ) // on document ready, initialize Class on every element // that matches js-namespace // pass in JSON options from element's data-options-namespace attribute ``` --- [MIT license](http://desandro.mit-license.org/). Have at it. By [Metafizzy](http://metafizzy.co)

@fortawesome/free-regular-svg-icons - SVG with JavaScript version
# @fortawesome/free-regular-svg-icons - SVG with JavaScript version > "I came here to chew bubblegum and install Font Awesome 5 - and I'm all out of bubblegum" [![npm](https://img.shields.io/npm/v/@fortawesome/free-regular-svg-icons.svg?style=flat-square)](https://www.npmjs.com/package/@fortawesome/free-regular-svg-icons) ## Installation ``` $ npm i --save @fortawesome/free-regular-svg-icons ``` Or ``` $ yarn add @fortawesome/free-regular-svg-icons ``` ## Documentation Get started [here](https://fontawesome.com/get-started/svg-with-js). Continue your journey [here](https://fontawesome.com/how-to-use/svg-with-js). Or go straight to the [API documentation](https://fontawesome.com/how-to-use/font-awesome-api). ## Issues and support Start with [GitHub issues](https://github.com/FortAwesome/Font-Awesome/issues) and ping us on [Twitter](https://twitter.com/fontawesome) if you need to.

jQuery Easing Plugin
# jQuery Easing Plugin What is it? A jQuery plugin from GSGD to give advanced easing options. More info [here](http://gsgd.co.uk/sandbox/jquery/easing) For CDN please use CloudFlare [`https://cdnjs.cloudflare.com/ajax/libs/jquery-easing/1.4.1/jquery.easing.min.js`](https://cdnjs.cloudflare.com/ajax/libs/jquery-easing/1.4.1/jquery.easing.min.js) to help my host. Thank you. # AMD or CommonJS usage ```js // CommonJS var jQuery = require('jquery'); require('jquery.easing')(jQuery); // AMD define(['jquery', 'jquery.easing'], function (jQuery, easing) { easing(jQuery) }) ``` # Building and testing * Clone the repo * `npm install` * Make changes * Test against files in `/examples` * Build minified version with `npm run build`

jQuery
# jQuery > jQuery is a fast, small, and feature-rich JavaScript library. For information on how to get started and how to use jQuery, please see [jQuery's documentation](http://api.jquery.com/). For source files and issues, please visit the [jQuery repo](https://github.com/jquery/jquery). If upgrading, please see the [blog post for 3.3.1](https://blog.jquery.com/2017/03/20/jquery-3.3.1-now-available/). This includes notable differences from the previous version and a more readable changelog. ## Including jQuery Below are some of the most common ways to include jQuery. ### Browser #### Script tag ```html ``` #### Babel [Babel](http://babeljs.io/) is a next generation JavaScript compiler. One of the features is the ability to use ES6/ES2015 modules now, even though browsers do not yet support this feature natively. ```js import $ from "jquery"; ``` #### Browserify/Webpack There are several ways to use [Browserify](http://browserify.org/) and [Webpack](https://webpack.github.io/). For more information on using these tools, please refer to the corresponding project's documention. In the script, including jQuery will usually look like this... ```js var $ = require("jquery"); ``` #### AMD (Asynchronous Module Definition) AMD is a module format built for the browser. For more information, we recommend [require.js' documentation](http://requirejs.org/docs/whyamd.html). ```js define(["jquery"], function($) { }); ``` ### Node To include jQuery in [Node](nodejs.org), first install with npm. ```sh npm install jquery ``` For jQuery to work in Node, a window with a document is required. Since no such window exists natively in Node, one can be mocked by tools such as [jsdom](https://github.com/tmpvar/jsdom). This can be useful for testing purposes. ```js require("jsdom").env("", function(err, window) { if (err) { console.error(err); return; } var $ = require("jquery")(window); }); ```

Outlayer
# Outlayer _Brains and guts of a layout library_ Outlayer is a base layout class for layout libraries like [Isotope](http://isotope.metafizzy.co), [Packery](http://packery.metafizzy.co), and [Masonry](http://masonry.desandro.com) Outlayer layouts work with a container element and children item elements. ``` html

...
``` ## Install Install with [Bower](http://bower.io): `bower install outlayer` [Install with npm](http://npmjs.org/package/outlayer): `npm install outlayer` ## Outlayer.create() Create a layout class with `Outlayer.create()` ``` js var Layout = Outlayer.create( namespace ); // for example var Masonry = Outlayer.create('masonry'); ``` + `namespace` _{String}_ should be camelCased + returns `LayoutClass` _{Function}_ Create a new layout class. `namespace` is used for jQuery plugin, and for declarative initialization. The `Layout` inherits from [`Outlayer.prototype`](docs/outlayer.md). ``` var elem = document.querySelector('.selector'); var msnry = new Masonry( elem, { // set options... columnWidth: 200 }); ``` ## Item Layouts work with Items, accessible as `Layout.Item`. See [Item API](docs/item.md). ## Declarative An Outlayer layout class can be initialized via HTML, by setting an attribute of `data-namespace` on the element. Options are set in JSON. For example: ``` html
...
``` The declarative attributes and class will be dashed. i.e. `Outlayer.create('myNiceLayout')` will use `data-my-nice-layout` as the attribute. ## .data() Get a layout instance from an element. ``` var myMasonry = Masonry.data( document.querySelector('.grid') ); ``` ## jQuery plugin The layout class also works as jQuery plugin. ``` js // create Masonry layout class, namespace will be the jQuery method var Masonry = Outlayer.create('masonry'); // rock some jQuery $( function() { // .masonry() to initialize var $grid = $('.grid').masonry({ // options... }); // methods are available by passing a string as first parameter $grid.masonry( 'reveal', elems ); }); ``` ## RequireJS To use Outlayer with [RequireJS](http://requirejs.org/), you'll need to set some config. Set [baseUrl](http://requirejs.org/docs/api.html#config-baseUrl) to bower_components and set a [path config](http://requirejs.org/docs/api.html#config-paths) for all your application code. ``` js requirejs.config({ baseUrl: 'bower_components', paths: { app: '../' } }); requirejs( [ 'outlayer/outlayer', 'app/my-component.js' ], function( Outlayer, myComp ) { new Outlayer( /*...*/ ) }); ``` Or set a path config for all Outlayer dependencies. ``` js requirejs.config({ paths: { 'ev-emitter': 'bower_components/ev-emitter', 'get-size': 'bower_components/get-size', 'matches-selector': 'bower_components/matches-selector' } }); ``` ## MIT license Outlayer is released under the [MIT license](http://desandro.mit-license.org).

Timethy Hyman

Real Time FFT Ocean Rendering in DirectX 12

Introduction

Table of Contents

Understanding the basics

Chapter 1 Wave Simulation: JONSWAP & the FFT Pipeline

1.1 The Setup

1.2 The Wave Spectrum

1.3 Initial Spectrum Generation: H₀

1.4 Time Evolution: Animating the Waves

1.5 The Butterfly FFT

Understanding the FFT

Permuting the FFT Output

Centering the spectrum

Unpacking the signals

Applying choppiness

Chapter 2 Rendering & Shading

2.1 Vertex Displacement

2.2 Normal Reconstruction & Shading

References

Creating a Deferred Renderer

A simple implementation of Deferred Rendering.

Introduction

Prerequisites

What is Deferred Rendering?

Why would I even bother implementing a deferred pipeline?

Benefits and detriments.

The G-Buffer.

Implementation.

The General Idea

The light pass.

Final Pass

Switching between passes

Alternative passes

Further Optimizations

Finally we can look into occupancy

Conclusion.

Future work

Further Reading:

Tutorial

Posts by Category : {{ page.title }}

Security Policy

Change Log

Upgrading Guide

Mouse Wheel ChangeLog

Fizzy UI utils

@fortawesome/free-regular-svg-icons - SVG with JavaScript version

jQuery Easing Plugin

jQuery

Outlayer