I’ve also started building FragCoord.xyz, my take on shader editing, debugging, and analysis in your browser. None of the existing tools fit my needs; some are stagnant, others are niche. I wanted to make something capable for professionals and hobbyists. Today, I’d like to show you where it’s at currently and the cool things you can do with it now.

Introduction

When you first visit FragCoord.xyz, you are greeted with a template shader screen and a quick overview of the current features (subject to changes in the near future):

The Editor is where you start and where you edit shader code with a shader display on the right. The editor is designed to be flexible with resizing and layout options (additional options on the settings page).

The Explore page shows you the top shaders and feed if you follow shader creators.

Here you can find other shader examples, like, comment, and follow.

The Docs are documentation for FragCoord, editor tools, uniforms, rendering, import/export, and other technical details for FC.

Let’s take a closer look at the editor and the inspector tools.

Inspector Modes

Under the shader preview, you’ll see 5 inspector modes (Tuner, Inspect, Errors, Frames, and Heatmap). Each of these gives you a different lens to examine the shader.

Tuner - Adjust inputs

When nothing is selected, the tuner shows all the built-in uniforms supported in FragCoord, such as u_resolution for the shader resolution and u_time for the time elapsed in seconds. The uniforms used in the code are highlighted (the rest are grayed out). The live values of those uniforms are shown on the right side:

You can add your own uniforms, such as RGB colors, textures, or anything else, with the Add uniform button. This lets you pick the data type, and then you can adjust it with the sliders needed. The tuner can also be used to adjust any selected value in the code. This makes it easy to tune magic numbers and see what each number does.

Inspect - Visualize expressions

The Inspector lets you look at each stage of the shader. You can select a variable or expression in the main function see what the output looks like in the shader port. Hover with the mouse to see the values at the cursor.

In the Inspect panel, you’ll see the histogram of the selected expression, the minimum and maximum values (the display is normalized to the 0.0 to 1.0 range). If your shader is producing unexpected results, it can help to look through step by step.

Errors - Find NaN and Inf

Sometimes a shader produces an unexpected black screen or black pixels. This is often caused by Not-a-Number errors (for example, division by 0). You can toggle individual checks for NaNs, Infs, and Out of Range tests for colors outside of the 0 to 1 range.

You can also select individual lines to see the errors for that line. Errors are shown with checkerboards (NaNs are Red/Cyan, Infinities are Green/Magenta, Ranges are Blue/Yellow).

Frames - GPU time graph

A standard frame graph view that gives you CPU and GPU time, milliseconds, and frames per second modes, and stutter points. You can pause the timeline by clicking in the box or change the range in the bottom-right. Frames is for helping you find lag spikes and monitor the overall performance of your shader.

Heatmap - Per-pixel cost

The heatmap shows you the instruction cost for each pixel (or chunk). Most shaders have a uniform instruction count, but you can get divergence with conditional for-loops or if statements.

The heatmap can highlight the most problematic areas and give you a sense of what to optimize. Ideally speaking, you want to minimize instruction costs and recognize that the pixels are chunked together, so if you have a low-cost pixel next to a high-cost one, you may be paying the higher cost for both. Less variance is generally better. I plan on adding more tools here to help with this.

Import, Export, and Formatting

To help make FragCoord a universal tool, it automatically converts ShaderToy or twigl code to FragCoord’s format, uniforms, and structure. Ideally, you can copy and paste shaders over, and they’ll just work.

Next to the save button, there’s an export button that lets you convert to other common languages and formats (WebGL, ShaderToy, HLSL, Metal, and WGSL):

So much time can be spent manually converting code languages when it’s relatively easy to automate. I’ve also added an automatic formatting tool to organize your code. This reformats the shader to fit your chosen convention and can be helpful when using code from multiple different sources.

When there are errors, you can see them by hovering over the error line or the error count at the bottom of the code:

You also have the auto-compile check box and manual compile button. A character counter for the minimized shader and an approximate instruction count (hover to see line-by-line estimates). This is meant to help with optimization and performance awareness. The instructions count is roughly equated to performance cost.

Code Library

Finally, the code library is the place where you can save and reuse your most useful functions, such as noise functions, rotations, color transformations, and many more.

FragCoord has you start with the most common ones, but you can remove or add your own as you like:

The community tab is where you can find other code snippets from other users and share your own. I want this to be the main grounds for distributing functions. The code library is meant to be the place to showcase the best shader snippets and allow for continued development of techniques, not just tech demos. Users can update their code snippets, and it will automatically update for all future references, so if you find improvements to your snippets, you can always tweak them later.

Community

There’s a growing community of 500 members and 650 public shaders in just a couple of weeks! I want FragCoord to become the best place for graphics professionals and hobbyists, to make it easy to learn, build, and share with tools that help bring the best tech forward.

When saving your shaders, you publish them publicly, release them unlisted (not on explore, search, or profiles), leave them personally for yourself, or invite only specific members. For collaborations, you can tag other users in your shaders, and there’s a tagged section on your profiles. Follow users to see them in your personal feed and turn on notifications for specific users if you like.

Please come join FragCoord.xyz and help shape its future. I’m still constantly tweaking, fixing, and improving. Let’s make this the best place for the graphics community. If you want to suggest features or report bugs, click the changelog.

Thanks,
-Xor

Previously, I wrote about 2D rotations and how rotations can be stacked for 3D Euler Angles (yaw, pitch, and roll):

In 3D, there are several other ways to rotate. First, we’ll start with Euler Angles.

Euler Angles

One simple way to solve 3D rotation is with a series of 2D rotations on each axis XYZ.

As previously covered, 2D rotation looks like this:

mat2 rotate2D(float angle)
{
    return mat2(cos(angle), -sin(angle), sin(angle), cos(angle));
}

When you want to rotate a vector around an axis line, say the z-axis, for example, it’s as simple as doing a 2D rotation on the x and y axes, leaving the z-axis unchanged. Then you can rotate again on another axis to add another degree of rotation.

You could rotate the plane by applying roll, then pitch, then yaw. For example, depending on the axes, it might look something like this:

//Roll (for x-axis)
vector.yz = rotate2D(ROLL) * vector.yz;

//Pitch (for y-axis)
vector.xz = rotate2D(PITCH) * vector.xz;

//Yaw (for z-axis)
vector.xy = rotate2D(YAW) * vector.xy;

Note: The order of the rotation is very important, and the following rotation can be reversed by reversing the order and swapping mat * vec with vec * mat.

This type of rotation is easy to understand and implement, but it has a few drawbacks in some contexts:

• Uses more operations and steps than necessary. It can be simplified further.

• Rotating about an arbitrary axis is not always obvious.

• Doesn’t blend orientations well.

• 90-degree turns can cause gimbal lock.

If you don’t care about those concerns, then you may stop here. For the rest of us, let’s go a step further.

Axis Angle

When you need to rotate around an arbitrary axis, you need this formula (learned from Fabrice Neyret’s code golfing):

//Rotate vector "vec" with angle "ang" around the "axis"
vec = mix(dot(vec, axis) * axis, vec, cos(ang)) + sin(ang) * cross(vec, axis);

That is a little overwhelming at first, so let’s break this down into byte-sized pieces. For this formula to work correctly, we need the axis vector to be a unit vector (with a length of 1.0 units), and “vec” can be whatever coordinates we want to rotate. “ang” is the rotation angle in radians.

Let’s focus on this part:

dot(vec, axis) * axis,

The Dot Product here is finding how far our vector is along the axis and translating that many units in the axis direction. For example, let’s say we have

vec = vec3(1, 2, 3) and axis = vec3(0, 0, 1)

This formula finds how far vec3(1, 2, 3) is in the z axis, which is 3 units, then we move 3 units in the z axis to get vec3(0, 0, 3). You can think of this as the center point that we are rotating around. We want the x and y to change, but not the z. This is just like our Euler Angle example, except that it generalizes to any axis direction!

Now, with that context, let’s look at the whole mix formula:

mix(dot(vec, axis) * axis, vec, cos(ang))

Here we are mixing between the axis center point and the vector. It oscillates between the original vector and the inverted vector across from the axis center point.
This is like the x-axis of our 2D rotation, but for an arbitrary axis.
Finally, we add the sine with a cross product:

 + sin(ang) * cross(vec, axis)

I haven’t covered the cross product in detail yet, but for our purpose now, we can think of it as finding the perpendicular vector. For

cross(vec3(1,0,0), vec3(0,1,0)) we get vec3(0,0,1)

It’s the perpendicular vector of the two vectors (multiplied by their magnitudes and the sine of the angle between them).

So for cross(vec, axis), we get the perpendicular vector to the axis. We multiply this by sine, just like we would with the y-axis of a 2D rotation. Same idea, but for the arbitrary axis!

It’s difficult to illustrate, but you can imagine the rotation axis as defining the place that the vector rotates on. When you rotate around, you rotate from the original point to its perpendicular and opposite points along that plane.

This solves most of the drawbacks, is more efficient, blends better, and avoids gimbal lock, but sometimes you need to interpolate between two orientations (especially in video games). The next step will be quaternions, which deserve a separate tutorial on their own. I’ve tried to find good examples that clearly explain how they work, but I was unsuccessful, so I’ll have to write one myself.

Conclusion

At the end of the day, rotation happens at one plane at a time. In 2D, it’s easy, as there are only two axes to work with. In 3D (and higher dimensions), it becomes a little more complex as there any many different ways to rotate.

Euler Angles are simple to understand and work with because they’re just a series of XYZ axis rotations. It works well in video game contexts because you might only need yaw or pitch and yaw rotation. When you want to rotate in an arbitrary direction, you can use Axis Angles. They are relatively simple, clean, and easy. Beyond this, we have quaternions, which have their uses in animations (blending together better), but I’ll leave that for another day.

Extras

Max Slater’s Exponentially Better Rotations - an overview of different rotation techniques, how they interpolate, and going beyond quaternions

That’s all for tonight. Have a great weekend!

Thanks!
-Xor

In computer graphics, we often need ways of creating noise for clouds, water, terrain, procedural texturing, etc. I previously wrote about “Efficient Chaos” for cheaply scattering elements randomly and I wrote about Turbulence for cheaply approximating fluids and gases. Today we are looking at new cost saving technique that I sometimes use in place of 3D Value Noise, Perlin Noise and Simplex Noise algorithms. Those noise algorithms are designed to be fairly efficient, but if you’re sampling them many times per pixel (i.e. volumetric rendering), you probably can’t afford the expensive, multi-sample functions. Here’s how it works:

Gyroids

The idea started from playing with gyroids:

Gyroids are these cool wavy infinite shapes defined with a simple trig formula:

//Gyroid waves
float gyroid = dot(cos(p), sin(p.yzx));

//Gyroid waves expanded out
//float gyroid = cos(p.x)*sin(p.y) + cos(p.y)*sin(p.z) + cos(p.z)*sin(p.x);

It’s neat that such a simple combination of sine, cosine and swizzling can create this interesting pattern. The problem is it’s too perfect and repeats every Tau (with a period of 6.2831) units.

Aperiodic Gyroids

Then I wondered if pick an irrational frequency for one of the sine waves, they should never line up. Playing with the frequencies made some interesting results:

What about the golden ratio, Phi, the most irrational number? Then the sine waves should never line up perfectly. Here’s what that looks like:

That already looks pretty random and in simple cases, that may be enough, but if I zoom out, you can see that aperiodic doesn’t mean pattern-less:

There are repeating shapes that are just slightly off, but still looking clearly patterned to our brains. We can take this further with more math and the golden angle

3D Rotation

Part of the reason this looks so patterned, is because both waves are using the same axis lines. If you remember from Turbulence and Efficient Chaos, rotation can make an enormous difference in masking these patterns. What angle should we use and about what axis? Well how about the golden angle with phi and phi^2 for the axis:

//Rotating the golden angle on the vec3(1, phi, phi*phi) axis
const mat3 GOLD = mat3(
    -0.571464913, +0.814921382, +0.096597072,
    -0.278044873, -0.303026659, +0.911518454,
    +0.772087367, +0.494042493, +0.399753815);

This orientation should be the most irrational orientation, although I can’t confirm that, it works pretty well. Here’s my blobby test:

The full function looks like this:

float dot_noise(vec3 p)
{
    //The golden ratio:
    //https://mini.gmshaders.com/p/phi
    const float PHI = 1.618033988;

    //Rotating the golden angle on the vec3(1, phi, phi*phi) axis
    const mat3 GOLD = mat3(
    -0.571464913, +0.814921382, +0.096597072,
    -0.278044873, -0.303026659, +0.911518454,
    +0.772087367, +0.494042493, +0.399753815);
    
    //Gyroid with irrational orientations and scales
    return dot(cos(GOLD * p), sin(PHI * p * GOLD));
    //Ranges from [-3 to +3]
}

Uses

The ideal usecase is low-scale noise applied on natural shapes. It can work well for clouds and fluids. Here’s the twist demo I made.

For larger scenes, it can be layered as fractal noise at a fraction of the cost:

The best part is that this type of noise has fewer artifacts without a rand/hash function or interpolation.

Drawbacks

At the end of the day, it is still composed of just two layers of periodic waves. The rotation helps and the combination is not periodic, but the underlying patterns are still visible in some conditions, especially in flat, large scale scenes:

That being said, even Simplex Noise would look quite homogenous at this scale. Everything in computer graphics is about balancing trade offs and I think the simplicity and speed of this formula is worth it in many cases. If you use a lot of 3D noise, give this a shot!

Conclusion

Over the years, I keep finding and developing new tricks for recreating complexity with simple formulas. This simple modification of gyroids is about as cheap as it gets while still producing aperiodic pseudo-noise! We can skip the hash function and easing functions and blending steps, going straight for unfiltered, smooth waves.

It’s not a perfect solution for every noise problem, but it is effective for the performance cost. When layered in fractal noise, it’s a powerhouse.

Extras

Interleaved Gradient “Noise” by Alan Wolfe: a 2D alternative to white noise that is cheap to compute and easy to filter.

That’s a wrap. Thanks for reading. If you found this helpful, consider subscribing!

-Xor

Math Context

The formula behind mix(x, y, a) is just: x + (y - x) * a

A longer formula may be easier to understand: x * (1.0 - a) + y * a

This function “linearly interpolates” from “x” to “y” based on the amount “a”. An amount of 0.0 returns x, 1.0 returns y, 0.5 returns halfway x and y, and so on.

These variables can be floats or vectors, and the math works the same. For a color blending example:

At the end of the day, it’s just addition, subtraction, and multiplication. The math works the same with amounts outside of the 0.0 to 1.0 range. This allows you to use mix, not just to interpolate, but also to extrapolate. More on that later.

Note: You're generally still better off using built-in hardware functions, as they are very well optimized.

Color Tricks

So we already know how to blend two colors, but you can do a lot more with mix.

Saturation

If you want to control saturation, just interpolate between grayscale and full color:

//Compute weighted luma
//https://en.wikipedia.org/wiki/Luma_(video)
float gray = dot(col.rgb, vec3(0.2126, 0.7152, 0.0722));

//Interpolate from grayscale to color
col = mix(vec3(gray), col, SATURATION);

The best part is that this works with extrapolation, too. You can boost saturation by using an amount greater than 1.0 (negative values invert hue).

Brightness and Contrast

A simple formula for adjusting contrast and brightness with mix:

col = mix(vec3(BRIGHTNESS), col, CONTRAST)

The neat part about this formula is that you can adjust brightness and contrast as a vector, allowing for independent control of each RGB color channel.

Coordinates

You can use mix for animations, transitions, and motion. It can be used for interpolating between two positions to move something:

vec2 pos = mix(POS1, POS2, time_factor);

With an easing function, you can also control the acceleration and deceleration.

Radial Blur

I have also used mix for radial blurs, chromatic aberration, and crepuscular rays by mixing the UV coordinates with a focus point:

//Iterate 20 times from 0 to 1
for(float i = 0.; i<1.; i+=.05)
{
    //Add a texture sample approaching the center (0.5, 0.5)
    //This center could moved to change how the direction of aberation
    //The mix amount determines the intensity of the radial blur
    vec2 tuv = mix(uv, vec2(0.5), i * 0.2);
    col += texture(iChannel0, tuv) * 0.05;
}

Mixing helps with readability and makes it easy to control the center point.

Texture Page Coordinates

When working with texture pages, you often need to convert from a normalized coordinate range to that of a specific texture on the texture page:

//Blend between the top-left and bottom-right uvs
vec2 uv = mix(uvs.xy, uvs.zw, norm_uv);

Remapping Function

One formula that I use all the time is a bit like mix 2.0. mix(a, b, x) takes “x” from the [0.0, 1.0] to the [a, b] range. Remap takes the “x” from [a, b] to the [c, d] range:

remap(a, b, c, d, x)
{
    return (x-a) / (b-a) * (d-c) + c;
}

It’s very useful, especially with texture coordinates

Extras

I previously wrote about the OkLab colorspace, which is optimized for human color perception. The standard RGB colorspace is not perceptually linear, meaning that blending between two RGB colors can produce unnatural results. If you need to blend colors (hues, luminances, saturations, etc) visually, you want to use OkLab mix:

Here’s a nice video on linear interpolation and other blending functions by SimonDev:

That’s all for tonight. Thanks for reading!

Density Fields

First, for some background, we’ll start with Signed Distance Field raymarching, which I covered here:

With regular sphere-assisted raymarching, you check the distance from the camera to the nearest surface and step that distance in the ray direction. Next you check the distance field at that sample point and step forward again, repeating this 50 to 100 times. In the end, you should have a good approximation of the first intersection point with the ray and the surface.

For volumetric rendering, I use a similar approach, but instead of distance field, I use a “density field”. With volumetrics, we don’t have to care as much about the final intersection point, but we do want to focus on taking more samples in high density areas. For example, here is a basic tunnel, but with smaller steps:

//Density field (Tunnel + irregular gyroid)
//https://www.shadertoy.com/view/XcBBRz
float volume(vec3 p)
{
    return 3.5 - 0.25*length(p.xy) + 0.5*dot(sin(p), cos(p*0.618).yzx);
}

The 3.5 sets the radius of the tunnel and the length(p.xy) makes a ton along the z-axis. The 0.25 scales the steps down so that raymarcher takes smaller steps along the ray and the dot product sine wave technique adds some distortion cheaply.

When rendered, it looks like this:

Sample Accumulation

Typically, with raymarching, you sample the color once, outside the raymarch loop, at the intersection point, but with volumetric rendering, you sample the color at every point along the ray and accumulate the samples. It is easier to accumulate light then to try to deal with scattering and opacity.

We’ll look at a simplified glowing example first:

//Fog density
#define DENSITY 1.6
//Surface pass rate
#define PASSTHROUGH 0.1

//Octahedral density field
float volume(vec3 p)
{
    //Mirror the axes and average them up
    float sum = dot(abs(p), vec3(1.0/3.0));
    //Find distance to the edge with a passthrough
    return abs(sum - 2.0) / DENSITY + PASSTHROUGH;
}

We won’t worry about the SDF math right now. The important parts are with the density, which makes the raymarch steps smaller and the passthrough which allows the raymarcher to pass through the surface. By using the absolute value of the sum, it makes the distance field hollow, so when we add a little passthrough, the step size never reaches zero and the ray continues marching. Here’s what our octahedron looks like up close (yes, that is an octahedron with a lot of perspective and translucency)

My raymarch loop looks like this:

//Output brightness
#define BRIGHTNESS 0.002

//Accumulative color
vec3 col = vec3(0.0);

//Glow raymarch loop
for(float i = 0.0; i<STEPS; i++)
{
    //Glow density
    float vol = volume(pos);
    //Step forward
    pos += dir * vol;

    //Add the sample color
    col += vec3(3, 2, 1) / vol;
}
//Tanh tonemapping
//https://mini.gmshaders.com/p/tonemaps
col = tanh(BRIGHTNESS*col);

Each sample we add a color divided by the distance/density, which creates the nice light attenuation effect. Normally, you want to avoid dividing by the distance because it could be negative or zero (breaking the color accumulation). In this case, we know the volume will always be greater than one, so this works fine!

Other falloff functions can be used here. For extra fun, try changing the color and brightness based on the sample position.
I’ve put together a more advanced demo on ShaderToy here.

This showcases how this technique can be used with light rays shooting out.
Glowing effects are pretty easy and fun!

Clouds, fog and smoke can be done with a alpha blending your samples.

Blending

Instead of just accumulating color, you can do regular alpha blending like so:

color = mix(color, vec4(sample_rgb,1), (1.0 - color.a) * sample_alpha);

This gives you a new color for the next sample, to be blended like so.
It’s a good idea to stop raymarching when the color is opaque, because no more blending is going to happen:

//Stop when opaque (close enough to 1.0)
if (color.a > 0.998) break;

It never will quite reach 1.0 if you’re doing things correctly, so a threshold above 254 / 255 is good enough. Here’s the source to my Clouds ShaderToy example.

The rest of the tutorial is dedicated to my paid supporters, who help make these tutorials possible. Please consider joining!

Read more

Live demo
This fragment shader code is just 258 characters:

for(float i,z,d;i++<8e1;o+=(cos(d/.1+vec4(0,2,4,0))+1.)/d*z){vec3 p=z*normalize(FC.rgb*2.-r.xyy),a=normalize(cos(vec3(4,2,0)+t-d*8.));p.z+=5.,a=a*dot(a,p)-cross(a,p);for(d=1.;d++<9.;)a+=sin(a*d+t).yzx/d;z+=d=.05*abs(length(p)-3.)+.04*abs(a.y);}o=tanh(o/1e4);

That tiny little code handles the raycasting algorithm, glowing attenuation, 3D scene rotation, camera displacement, turbulent fluid dynamics, and particle distribution along a 3D ring! It’s a lot to unpack.

Before we can look at the specifics of this shader, we need to understand the shader format and variables.

Twigl Format

These tiny shaders are written for “twigl.app”, which is a minimal online shader editor like ShaderToy, designed specifically for writing shaders to share on Twitter/X in 280 chars or less. Twigl is handy because in the compact “geekest 300” mode, it compresses the variable names like gl_FragColor to “o”, gl_FragCoord to “FC”, resolution to “r” and time to “t”. It also automatic inserts your pasted code into the main function so there is no generic code required and you can focus on the parts that matter.

It also adds some handy functions, a backbuffer and which I wrote about in more detail here, but for our purposes now, this is enough!

Adding Breathing Room

When I am sharing code on X, every character counts, including spaces and line breaks. Usually, I don’t have enough room to spare for pretty code formatting.

With some spaces, line break,s and comments, we have this expression:

//Initialize Iterator, Z-depth and step Distance variables
//Raymarch 80 steps
for(float i,z,d; i++<8e1;
  //Pick a color and light attentuation
  o += (cos(d/.1+vec4(0,2,4,0))+1.)/d*z)
{
  //Raymarch step sample point
  vec3 p = z*normalize(FC.rgb*2.-r.xyy),
  //Twisting rotation axis vector
  a = normalize(cos(vec3(4,2,0)+t-d*8.));
  
  //Move camera back 5 units
  p.z += 5.,
  //Rotate sample using the axis
  a = a*dot(a,p)-cross(a,p);
  
  //Apply turbulence waves at 9 frequencies
  for(d=1.;d++<9.;)
  a += sin(a*d+t).yzx/d;
  
  //Approximate distance to ring and step forward
  z += d = .05*abs(length(p)-3.)+.04*abs(a.y);
}
//Tonemap with tanh
o = tanh(o/1e4);

Already, this should be much more digestible, but there are several unique techniques being used here, so let’s do a closer, line-by-line analysis.

Raymarching

The very first line is the raymarch loop:

for(float i,z,d; i++<8e1; …

Raymarching is a type of raycasting algorithm that marches in steps along the ray direction until it intersects with a surface or gets close enough. Each step along the way, it checks the (approximate) distance to the nearest surface and steps that far in the ray direction. If the distance is done exactly, you’re guaranteed not to pass through any surfaces.

This raymarch loop initializes the iterator “i”, the raymarched “z” depth, and the step distance “d”, which will be useful later. When undefined, these variables are all initialized at 0.0, and so the loop executes 80 steps.

The next line actually executes last. In GLSL, for loops are in the format:

for(INIT; COND; LAST)

The “INIT” part can be left blank, but it’s a free semi-colon, so I always use it! “COND” is the continue conditional boolean; if it’s true, it repeats the loop, otherwise the loop stops. The last step is usually the increment “i++” part, but not for a code-golfer. For me, it’s the last line, saving another semi-colon.

So the final step is this part, which handles the coloring. More on this later…

o += (cos(d/.1+vec4(0,2,4,0))+1.)/d*z)

Next, I calculate where the sample is along the ray:

vec3 p = z*normalize(FC.rgb*2.-r.xyy),

“z” is the raymarched depth along the ray (more on that later). The normalized bit is for calculating the ray direction for each fragment/pixel. FC is not just a 2D vector with fragment coordinates on the screen. It is a 4D vector with z component being 0.5 and w being 1.0. (I use .rgb instead of .xyz to avoid the code being translated to a URL). Another way to understand the vector inside normalize:

//Center the xy coordinates and z is minus screen height
vec3(FC.xy*2.0 - r, 1.0 - r.y)

//Since we're normalizing this vector, the length doesn't matter
//We could divide all components by the screen height
//That gives us a more familiar ray direction formula
vec3((FC.xy*2.0 - r) / r.y, - 1.0)
//The xy coordinates are normalized and ratio-correct.
//The z axis is approximately negative -1.0 when the height is high

We end up with a compact way of writing the standard camera ray direction, just with the camera facing the negative-z direction instead of positive z!

Rotation and Trailing

This next part deserves a full tutorial on its own (it’s on the list):

a = normalize(cos(vec3(4,2,0)+t-d*8.));

For a simplified explanation, this calculates a rotation axis vector with the x, y, and z out of phase from one another. Adding the time “t” means it completes the rotation cycle every Tau (6.283…) seconds. Remember, “d” is the step distance (which gets defined later). When we subtract the distance to the ring from time, it means that the rotation axis lags behind when the sample point is further from the ring. Without this bit, we would have no trailing effect!

Before applying the rotation, we move the camera back 5 units:

p.z += 5.,

This makes it revolve around the sphere. Remember that backwards is positive here.

This simple formula applies the actual rotation to vector “p” on axis “a”

a = a*dot(a,p)-cross(a,p);

This is based on a longer formula for 3D rotations:

mix(a*dot(p,a), p, -cos(t)) + sin(t) * cross(p,a)

Which rotates about “a” with angle “t”. In this shader, I simplified by hard-coding the angle of 270 degrees (cos(t) = 0 and sin(t) = -1). This allowed me to remove the sine, cosine, and mix functions. So instead of rotating around a fixed axis, I rotate a fixed angle around a moving axis. It creates some interesting motion, too!

Turbulence

The next piece is the application of fluid-like dynamics:

for(d=1.;d++<9.;)
  a += sin(a*d+t).yzx/d;

The idea is simple. Just apply some perpendicular sine waves. When repeated at frequencies from 1 to 9. This is a reduced version of my turbulence technique:

Ring

To approximate the distance, we start with the distance to a hollow sphere (without turbulence) plus the distance to the plane (with turbulence):

z += d = .05*abs(length(p)-3.)+.04*abs(a.y);

I multiplied the step distances by very small factors because the turbulence and twisting distorts the distance fields a lot, so it makes it less likely to overstep.

This distance gets fed into the color function:

o += (cos(d/.1+vec4(0,2,4,0))+1.)/d*z)

Every raymarch step, I pick a color using the step distance to pick the hue. The color is picked using a sine wave with RGBA phase shifting (the alpha isn’t important). Adding 1.0 puts the color in the [0.0, 2,0] range (don’t want negative colors). Dividing by the distance gives a nice light attenuation effect. Multiplying by z makes it fade when it gets close to the camera.

Phosphor 2 and Nucleus

Phosphor 2 is the same idea, but with coloring based side of the plane, the different rotation pattern, a sharper sphere falloff, and darker overall:

Phosphor 2 Demo
Nucleus simplifies the coloring, removes the plane, and uses the turbulence sphere coordinates instead:

Nucleus Demo
So that’s how it works. 3 shaders in one! Hopefully, that made sense and was interesting. Thank you for reading, and I’ll talk soon.

Nature is mostly chaotic, while computers are deterministic. Ironically, a lot of time and resources are spent trying to generate (pseudo) randomness. This tutorial will explore some techniques I use in my shaders to add some natural randomness. This technique can be used for scattering stars, rain, leaves, particles, money, or objects.

If you’ve read my guide on fluid Turbulence, you may have some ideas about how this method works:

This concept is similar, but with a few additional options for greater variety. Better yet, this works in 3D without additional costs. Classic Worley Noise, for instance, has a complexity cost of 3^N for N-dimensions (9 samples in 2D, 27 samples in 3D, 81 samples in 4D), making it less than ideal in 3D applications.

Grid Cells

We just start with a basic, tiled grid of points. Then we can add a few layers with offsets. 3 to 5 is pretty generally reasonable. Next, you can increase the spacing with each layer to break the tiling. And when combined with rotation, you eliminate most of the visible tiling:

At a glance, the rotated image looks pretty random to me. The colored layers kind of give away the patterns, but that can be easily solved.

Here’s a grayscale output with just 5 layers:

First, you can split the coordinates into cells using fract() or mod() and find the difference to the cell center.

//Break the coordinates into cells of 2 units
vec2 subcell = mod(coord, 2.0) - 1.0;

For this example, we’ll use the distance to the cell centers for our star point lights:

//Distance to cell center
float len = length(subcell);
//Light attenuation with circle cutoff
float att = max(1.0-len, 0.0) / len;

Note: You can use whatever function you want here. You could have randomly rotated squares, rain particles, snowflakes, or anything else that fits neatly in the cells. For extra variety, randomize the particle orientation, scale, and position within the cell (avoiding edge clipping)

To add layers with shifting, I have:

//Loop through the layers
for(float i = 0.0; i<LAYERS; i++)
{
    //Save the base coordinates
    vec2 p = coord;
    //Apply a layer shift for each layer
    p += LAYER_SHIFT*i;

    //...Use p for our sub-coordinates and sum lights

Next, we can simply scale each layer like so:

//Adjust layer scaling
p /= 1.0 + LAYER_SCALE*i;

And finally, for rotation, I could just rotate the base coordinates:

//Rotate layer
//Read about the Golden Angle here:
//https://mini.gmshaders.com/i/139108917/golden-angle
coord *= mat2(0.22252093, -0.97492791, 0.97492791,  0.22252093);

This works well for simple cases, but since we are rotating the base coordinates, we lose the original orientation. If you want to add some parallax motion or directional lighting, you still need the original orientation.

Another method is to save the orientation matrix separately so we can apply it when needed:

//Starting orientation (no rotation)
mat2 orient = mat2(1.0);


//Inside the for loop:
orient *= gold;
vec2 p = coord * orient;

This is the approach I will be using later for the parallax example.

Putting everything together, we’ll have the following:

//Number of layers
#define LAYERS 5.0
//Overall scale
#define SCALE 0.1
//Overall brightness
#define BRIGHTNESS 0.04

//Toggle layer shift (shifting factor)
#define LAYER_SHIFT 2.618
//Toggle layer spacing (spacing factor)
#define LAYER_SCALE 0.6


//Output color for example
vec3 col = vec3(0.0);

//Starfield Coordinates
vec2 c = fragCoord / iResolution.y / SCALE;

//Loop through layers
for(float i = 0.5 / LAYERS; i<1.0; i+=1.0 / LAYERS)
{
    //Rotate layer
    //Read about the Golden Angle here:
    //https://mini.gmshaders.com/i/139108917/golden-angle
    c *= mat2(0.22252093, -0.97492791, 0.97492791,  0.22252093);

    //Get rotated coordinates
    vec2 p = c;

    //Apply layer shifting
    p += LAYER_SHIFT*i;

    //Adjust layer scaling
    p /= 1.0 + LAYER_SCALE*i;

    //Distance to cell center
    float len = length(mod(p, 2.0) - 1.0);
    //Light attenuation with circle cutoff
    float att = max(1.0-len,0.0) / len;
    col += att;
}

The same concept works in 3D, too, without extra steps! Here’s my full ShaderToy demo with some extra features

Breaking Patterns

Most of the patterns are not too obvious, but if you have an expensive shader and could only afford a couple of layers, you may have visible axis lines:

My quick and easy fix is to add some waves for warping

//Warp the x and y axes with sine waves
p += LAYER_WAVES*sin(p.yx);

Playing with the wave amplitude so you can see what it looks like on 1 and 2 layers:

A wave amplitude of 1.0 is too much, but 0.2 seems to be a good balance between too much distortion and too much tiling. With just 2 layers, you really have to look for the patterns to find them!

There’s one other situational problem. If you zoom out, you’ll notice patterns, even with 5 layers. We could theoretically fix this by not zooming out or by adding more layers, but those are lazy solutions.

My preferred method is to cut random holes in the layers:

Read more

Hi, I’m Xor. As a graphics programmer, my job is essentially to make pixels prettier using math formulas. I work on video effects like lighting, reflections, post-processing, and more for games and animated backgrounds in software.

For fun, I like to unwind by writing compact little shader programs that fit in a “tweet” (280 characters or less). You may have seen some of these posted on X/Twitter. The process of shrinking code while maintaining its functionality is called “code golfing.”

Here’s an animated galaxy I wrote in just 197 characters of GLSL code:

This little piece of code runs in real time for every pixel on the screen and generates a unique output color using some fancy math and logic. I build these demos using a tool called Twigl.app, an online shader editor designed for sharing mini-shaders. It makes exporting videos super easy, and in its “geekiest” mode, it also takes care of the generic header code and shortens built-in variable names.

I even managed to fit a voxel DDA raytracer with edge detection into just 190 characters (update: now 175):

Today, I’d like to explain why I make these, share my creation process, and show you how you can try it yourself if you’re interested. Let’s start with the “why.”

Motivation

Why do I write these? Well, there are several factors. Since I like lists, I’ll go ahead and present them in order of relevance:

• Curiosity and Passion : Sometimes I get struck by a new idea and just want to play around with it. I like Twigl because it helps lower my expectations and lets me start doodling. There’s less room for overplanning, and it’s super easy to jump in.

• Learning and Discovery : Working within constraints forces me to think through problems differently. By optimizing for code size, I often find ways to simplify or approximate. It doesn’t always lead to more performant code (but often it does) and I’ve learned how to squeeze the most out of every byte. Having very little code makes it easier to experiment with formulas and variations without getting overwhelmed.

• Challenge : Writing tiny code is both challenging and stimulating. It keeps my brain sharp, and I’m constantly developing new skills. It’s basically become a game for me. I’ve accidentally learned a ton of math while trying to solve these technical problems.

• Community : I’ve connected with so many interesting people through this process—artists, designers, math folks, game devs, engineers, tech enthusiasts, and more. Sharing my work has led to some exciting encounters. (More on some notable people later!)

So, in short, it’s fun, thought-provoking, and engaging, and it’s a great way to spark interest in graphics programming. Now, what even is a shader?

Shader Introduction

In case you haven’t heard of shaders before, they are programs that run on the GPU (Graphics Processing Unit) instead of the CPU (Central Processing Unit). CPUs excel at complicated or branching operations, which are computed sequentially, one at a time (I’m simplifying here). GPUs are designed to process billions or trillions of predictable operations per second in parallel. This sounds like a lot, but a 4K screen at 60 frames per second outputs nearly 500M pixels per second. Each pixel could have 100s or 1,000s of operations, not to mention anything else the GPU might be used for.

There are several different types of shaders: vertex shaders, fragment shaders, compute shaders, and more, but these tweet shaders are specifically fragment shaders, also known as “pixel shaders,” because they run on every pixel. In essence, fragment shaders take the input fragment coordinates and output a color and opacity (or alpha). Fragment coordinates give you the position of the center of each pixel on screen, so (0.5, 0.5) is the bottom-left (or top-left). One pixel to the right is (1.5, 0.5), and so on to (width – 0.5, height – 0.5). The coordinates variable is called “FC” in Twigl. The output color, “o”, has 4 RGBA components: red, green, blue, and alpha, each ranging from 0.0 to 1.0.

(1.0, 1.0, 1.0, 1.0) is pure white, (0.0, 0.0, 0.0, 1.0) is opaque black, and (1.0, 0.0, 0.0, 1.0) is pure red in the RGBA color format. From here, you can already make simple color gradients:

o = vec4(0.0, FC.y/100.0, 0.0, 1.0) ;

Remember, this is run on every pixel, so each pixel will have a unique Fragment Coordinate. That formula makes a simple gradient that starts black at the bottom of the screen (FC.y = 0.0), and the green output value reaches 1.0 when FC.y reaches 100.0.

So you have an output color “o”, the input fragment coordinates “FC”, and four “uniform” inputs which are shared among all pixels: “r” is the shader screen resolution in pixels, “t” is the time in seconds, and also the less commonly used mouse position “m” and the backbuffer texture “b”. And that’s the core of it! From there, it’s a lot of math and logic to control the output colors and generate cool images.

I’m going to skip ahead a bit, but if you’re interested in learning more, try starting here!

Codrops

This article was written for Codrops. Please read the rest of the article over there, where I describe my process, code golfing, Q&A, and my story.
Thanks for reading!

Mini tutorials are back! These will cover a wide range of topics in bite-sized pieces, and I’ll start with some GLSL functions. This series will explain the math behind the functions and how they can be used.

Today is all about the Hyperbolic Tangent. “tanh”, which you may have seen cropping up in several of my tweet shaders lately. We’ll cover the math background, how to write your own, its uses, alternatives, and performance considerations.

Uses

The domain of tanh(x) is (-∞, +∞) and the range is (-1, +1). This means you can input any value (between negative infinity and positive infinity), and it will map to a value between -1 and +1. Large values of “x” quickly approach an output of 1.0, and negatives approach -1.0, so this function allows you to take values from an unpredictable range and smoothly map them to the normalized (-1, +1) range. Tanh can be thought of as an unbounded smoothstep function (I’ll have to cover that function later). It smoothly starts and stops without definite endpoints.
From here, you can shift (by adding to the input), scale the smoothness of the curve by multiplying the input and the spread of the output, by multiplying the function.

Here are some of the places where it is often used.

• Smooth blending: If you need to blend between colors without a definite starting or ending point, you can use tanh! For example, you might use:
  mix(col_a, col_b, tanh(x * SPREAD) * 0.5 + 0.5)
It could also be used for smoothly blending between two shapes or starting and stopping an animation, for example. Anything that needs to be blended without definite endpoints could use tanh!

• Tonemapping: I often use tanh as a way of normalizing my color values in my tweet shaders. It’s a conveniently short tonemapping function that is easy to plug in without altering the code much. It’s not the best out there, but it’s a pretty decent option and relatively cheap.

• Debugging: I like to use tanh to visualize variables because it works with any domain and brings it to a predictable range. If I seem to be getting values outside of the expected range, I can use tanh to see what these values are and still spot relative differences (higher values still have brighter outputs)

• Neural Network activations: tanh is sometimes used for bounded outputs in Generative Adversarial Networks activation functions, allowing for weights of any domain to be compressed to a usable range.

tanh(x) was not implemented until GLSL 1.30, so in GameMaker and WebGL 1.0, you’ll need to implement this manually. I’ll write how to implement this yourself and about more alternative functions later.

Math Background

Let’s look at 3 different mathematical ways to interpret the hyperbolic tangent to give a wider context for a variety of readers. Don’t worry if you’re unfamiliar with some of the terms here! It’s still quite useful to understand how this relates to other math concepts, and you can let the details fill in naturally over time later.

Sigmoid Curve

A sigmoid is a symmetrical “S” curve. There are several types of sigmoid functions with different ranges. Some range from 0 to 1, while others range from -1 to +1, but they are all symmetrical (rotating 180° around the center point). tanh(x) is a common sigmoid that is supported in many programming languages, optimized and convenient with the [-1, +1] range.

Trigonometry

The hyperbolic tangent can be understood as an x / y ratio similar to the regular tangent function. With tan(Θ), you are finding the x / y ratio (or slope) of a point on a unit circle. x = cos(Θ) and y = sin(Θ), so the tangent, ratio is cos(Θ) / sin(Θ).
The hyperbolic tangent is the same, but mapped to a unit hyperbola instead of a circle:

Intuitively, there are hyperbolic sin and cos functions: sinh, cosh:

You might be asking, What is a hyperbola? The short answer is that it is the intersection slice of a double cone. Here’s an illustration of what I mean:

The mathematical rabbit hole runs deep here, so I’ll leave the rest for you to explore if you feel compelled to do so. Let’s look at one more approach!

Exponentials

We can also interpret it with exponential curves! The difference of positive and negative exponentials divided by the sum of positive and negative exponentials:

When fully reduced, it can be computed and implemented with just one exponential:

//Hyperbolic Tangent
float tanh(float x)
{
    float exp_neg_2x = exp(-2.0 * x);
    return -1.0 + 2.0 / (1.0 + exp_neg_2x);
}

This is how it can be implemented in older versions of GLSL or languages where the tanh function is not implemented. Next, let’s compare this to some other options.

Alternatives

This section and the next (on performance) will be reserved for my paid supporters!

Read more

I previously wrote about “Visual Development”, which covered some concepts for communicating through design in video games. This one will be focusing on stand-alone shader art and suggestions with composition, lighting, coloring, and texturing. As with all art things, take this with a grain of salt. These are not rules, but merely guidelines, and there will be some exceptions to everything I cover. Use this as a tool to think through the major design elements to ensure you aren’t ignoring anything.

1 - Composition

In my opinion, the most important design consideration is the composition. I’m talking about where the viewer's focus is. The placement and size of these focal points. Look at these 3 examples with a fancy sphere:

The first one is just awkward. It’s partially cropped, but also leaves a lot of empty space on the right. It feels out of balance. If there was something to look at on the other side, it might be acceptable, but for a single abstract object, on an empty scene, it’s not pretty.
The second one fills the screen pretty well and is horizontally centered. It’s out of balance vertically, with details below and empty above, but it feels intentional. It could work well as a slow, animated background.

Finally, the third is simple, perfectly balanced, and focused dead center. I think this works best for more complex shapes, fast animations, or with simple backgrounds. It immediately communicates where the focus should be. Our brains want to see the most flashy, vibrant, or fast things because they provide us with the most information, and we don’t like it when we cannot fully see it.

So the key points to consider are the focus points and composition balance. Aim to keep the main focus areas roughly in balance or clearly, intentionally out of balance (like the second example). Subtle, slower, and more immersive shaders can get away with showing less or having a moving focus (more on that later). Complex or animated objects should generally be fully in view. In more organic/fluid scenes, a Rule of Thirds might work better, but in any case, think about what is visible, the negative space, and what is being cropped out. Be intentional with the composition!

2 - Lighting

The next most important consideration, in my opinion, is the lighting, black/white level, and contrast. It’s a good idea to look at your shader under a histogram, if possible. I use GIMP and this gives a sense of the range of the value (“lightness”), in your shader:

You generally want to spread across the entire range of lightness from black to white, since using the full spectrum gives you the richest contrast. Typically, I aim to spread across most of the spectrum, and then if I need the image brighter or darker, I adjust the lightness distribution with Gamma. Squaring the color makes it darker and more vibrant. The sqrt of a color will make it whiter and softer.

If you’re dealing with anything bright, I highly recommend tonemapping, which helps prevent overexposure and washed-out colors. I wrote about that in detail here:

3 - Colors

My third consideration is coloring: saturation, color temperatures, hues, and palettes.

I am a big fan of color, and I tend to prefer vibrant shaders, but not every piece of art should be juicy. Grayscale works well for industrial styles, perhaps with a touch of chromatic aberration. Vibrant colors work well for abstract, psychedelic styles. Saturation is a good way to convey energy and use color temperature intentionally!

For color palettes, I like to use sine waves with separate phases for the RGB color channels. Iq has a nice example of the various palettes you can make with this.

My personal favorites are:

//Fun palletes to try
//Hue is in radians so the range is [0, 6.2831]
vec3 temperature1 = 0.5 + 0.5 * cos(hue + vec3(0.0, 0.5, 1.0));
vec3 temperature2 = 0.5 + 0.5 * cos(hue + vec3(6.0, 1.0, 2.0));
vec3 rainbow1 = 0.5 + 0.5 * cos(hue + vec3(0.0, 2.0, 4.0));
vec3 rainbow2 = 0.5 + 0.5 * cos(hue + vec3(0.0, 1.0, 3.0));

Here’s what these palettes look like:

One more trick: color gradients. You can make shaders significantly more interesting by adding a gradient to the image’s hue or saturation. Here’s an example with a red radial gradient overlayed on an unsaturated scene:

In this case, I am screen blending a red on top of the scene. You could also use a depth gradient for a fog-like effect. Get creative and play around with different positions, shapes, sizes, and colors. I tend to prefer red-blue diagonal gradients, but maybe you’ll find something cooler!

4 - Textures

Pay attention to details at various scales:

Our brains like fractals, perhaps because they tickle our brains at multiple levels. It’s certainly more interesting to look at an image that has both large-scale texturing and fine texturing. This can be achieved with fractal noise, turbulence, or fractal texturing.

In any case, it’s a good idea to take a step back and look up closely. If it’s interesting in those cases, you’re probably on to something! Again, this is highly subjective and won’t be important for all types of art, but it’s worth considering!

5 - Motion

And finally, look at the motion: speed, rotation, shape shifting, color shifting, etc. Here’s my sunset shader at two vastly different speeds:

I put this one last because I think it is probably the most subjective consideration, but still worth discussing. I love slower animations. Sometimes, graphics people animate too quickly (in my opinion) and start to show patterns in the animation. With the cloud example above, I think the extra speed reveals how artificial the motion actually is.

Try your shader 50% faster and 50% slower and see which you prefer. Background shaders should generally be slower, abstract shaders faster, and glitch/strobe shaders may need to be super fast. Just like the fractal texturing concept, you can also layer motion at multiple time scales. For example, colors could shift slowly while shapes may shift more rapidly. In 3D contexts, you may have a scrolling or twisting camera. It’s far more likely that you will make the camera go too fast than too slow, but again, play around with various speeds and see what works best.

Conclusion

Okay, that covers all the design decisions that I feel are most important to consider when creating animated art. Let’s do a quick recap:

1. Composition - Generally, you want to keep the designs focused in the center and roughly balanced on all sides. If you’re going for an unbalanced look, make it clearly intentional and lean into it!

2. Lighting - Generally, use bright lights and deep shadows. Strong contrast is a great way to make the richest display possible. Use the full range and tweak the gamma as needed. There are exceptions, but most art benefits from a wider range.

3. Colors - Play with saturation, color temperature, and palettes. Limited color palettes are often better than using all the colors. Color gradients are a great way to add large-scale character to your art!

4. Textures - Pay attention to both the fine details and the macro scale. It should look good at a glance and up close, if possible!

5. Motion - Test your art at multiple speeds and see what looks best. Background scenes should be more subtle, and abstract scenes can be more intense. Most people add too much speed, in my opinion! It’s good to mix elements at various speeds!

Hopefully, this gives you some ideas to try with your next piece. I would love to see what you guys come up with. Feel free to tag me!

Have a great night! Thanks,
-Xor

Everyone knows that shaders are super easy to write and to debug, so this should be a quick tutorial. In case it isn’t clear, that was sarcasm. I’ve spent thousands of hours writing shaders, and I’ve gotten quite good at avoiding most of the pitfalls, but even so, I still occasionally get stuck. Today, I’d like to share some advice that could save you dozens of hours and headaches.

Writing For Clarity

The first step is to write cleaner code. It might sound hypocritical coming from me, but you can save a lot of time and headaches later by writing code that others, or future you, can read. Leave comments explaining each part, and name your variables clearly and consistently. This should help you avoid naming conflicts that shorter variable names might lead to (Is “c” short for coordinates or color?). If you copy-paste code from a tutorial, it’s good to practice adding comments line-by-line and make sure you understand each part, if possible.

Try eliminating magic numbers, either with consts, macros, or uniforms. One of the most common issues is a mismatch in uniform names. If you accidentally mistype a uniform name inside or outside the shader, it will default to 0.0 and cause unexpected issues. If your uniforms are broken, check this first!

Colors

Did the screen go black? Or maybe parts of the screen? Wherever this occurs, look for floats containing undefined, “Not-a-Number” values. Once you have a NaN, it’s very hard to get rid of. Any operation on a non-number will result in a non-number answer and more blank pixels.

This can happen when “x” is negative in sqrt(x), log(x), log2(x) or pow(x, y)1. In such cases, you may need to use max(x, 0.0) or abs(x) to keep x from being negative. Same with inverse functions like “acos(x)” or “asin(x)”. When x is outside the expected range [-1, 1], you’ll get NaNs. It should be clamped in such cases.

Also, look out for dividing by zero. 0.0 / 0.0 will cause a NaN, and you should consider this possibility with any division.

While not game-breaking, you should also make sure you are handling Gamma correction properly. I won’t repeat myself here, but you can read my full write-up on the topic over in this tutorial.

When doing lighting, you should choose the right lighting falloff function, and while this may depend on the style, the inverse of the square distance is physically correct.

However, regardless of the falloff function, you may see some banding artifacts, which can compound, especially with Low-Dynamic-Range additive lights. This is where dithering can help!

Textures

When it comes to textures, there are a lot of things that can go wrong. Texture page issues, coordinate issues, texture sizes, mipmap artifacts, and more.

To start, make sure that you understand how sprite drawing works. In a game engine like GameMaker, multiple sprites are put together on one texture called a “texture page” and when you draw a sprite, you’re just drawing part of a texture:

When you draw a sprite, it is actually just drawing a quad of part of the texture page. Texture coordinates range from 0 to 1 across the entire texture page, but individual sprites will only span part of the texture page:

Some shaders are written assuming the texture coordinates will always range from 0 to 1. This may be the case if you specifically put the texture on its own texture page and the texture is not being padded. Some devices do not support non-power-of-two sizes, though, and will add padding around the texture, which may cause unexpected issues on those devices.

//Remap textures coordinates to [0, 1] range
vec2 texcoord_normalize(vec2 coord, vec4 uvs)
{
     return (coord - uvs.xy) / uvs.zw;
}

//Remap textures from the [0, 1] range
vec2 texcoord_unnormalize(vec2 coord, vec4 uvs)
{
     return coord * uvs.zw + uvs.xy;
}

I wrote more about how to manage texture pages here! If you have issues with flipped textures or clamping/repeating textures, you should read that.

When it comes to texture interpolation, the standard texture function interpolates at a resolution of 256. Meaning, interpolated textures only blend in 256 steps, which is enough for most cases, but may not be enough if you need to scale a texture up a lot.

If you enable mipmapping, you may notice 2x2 blocks of artifacts:

This is because mipmaps are computed in 2x2 chunks. If there are sharp changes in the texture coordinates within a 2x2 chunk, it will use a lower LOD. You can address this by either disabling mipmapping, removing the discontinuities and sharp changes in the coordinates, or calculating the mipmap level manually. In GLSL 1.30 or later, you can use textureGrad() and compute the derivatives manually to get around this.

Coordinates

Handling scaling, aspect ratio, and centering at any resolution can be challenging. I wrote specifically about managing this, here:

When it comes to 3D, you often have to convert between different coordinate systems, like model-space, world-space, and screenspace. In 2D, we still sometimes have to convert between texture space, world-space, and screenspace.

This is not something that is super easy to summarize, but if you have issues with coordinate conversions, I wrote about this here:

Precision

Floats actually vary in quality depending on the device and hardware. Mobile devices often default to a lower precision, while desktops may use higher precision.

Lower precisions reduce the range of values and the decimal precision. A shader might work well on your desktop, but have poor quality on your phone. You can set the precision higher, but it may run slower on those devices, so it’s best to use the lowest quality you can get away with. lowp works well for colors, mediump for texture coordinates, and highp for positional coordinates.

When generating noise procedurally, you’re likely to notice a big loss in quality at lower precisions, so it’s best to use high precision for that.

With animated shaders, you may run into precision issues with your time variable:

Anytime you are working with a time variable, you should anticipate it becoming larger and larger. You can try multiplying the time factor by, like 1000, to see if your shader will work over time. If not, the easiest solution is just to loop the time variable every 600 or so seconds. There are several other approaches, though and I might have to do a separate tutorial on it sometime.

And finally, when it comes to sharp, pixelated edges, there’s no excuse not to implement some anti-aliasing:

Conclusion

To recap, let’s summarize everything we’ve covered today:

Clarity:

• Rename variables for clarity

• Write comments to explain each part of the code. Future you will thank you

• Double-check uniform names inside and out of shaders

Color:

• Make sure negative sqrts and logs are impossible.

• Prevent zero divided by zero!

• Clamp inverse trig functions as needed.

• Do color operations in decoded-gamma (linear-color) and reencode to sRGB.

• Optional: Dither to mask banding artifacts

Textures:

• Don't assume normalized 0 to 1 texture coordinates.

• Avoid hardware texture interpolation for highly-stretched textures.

• When mipmapping, avoid sudden changes (discontinuities) in texture coordinates.

Coordinates:

• Make sure your shader works as intended at a variety of resolutions and aspect ratios.

• Know what coordinate system to use for the job and how to convert between them when needed.

Precision:

• Use highp floats when needed to avoid precision artifacts on low-end devices.

• Use lowp or mediump when possible to improve performance on low-end devices.

• Generally, you should generate procedural noise in highp.

• Keep your time uniforms in a reasonable range and test your game at high speed.

• Implement anti-aliasing whenever you can!

If you take these steps, hopefully, you save yourself a lot of time and prevent several problems before they happen. Believe me, I’ve spent a lot of time wrestling with some of these issues personally and I imagine others have as well. I’d suggest bookmarking this page for later, so if you ever run into an issue, you can check this list first. If you find something I missed, don’t hesitate to reach out! Thank you!

Extras

RenderDoc is a well-known shader debugging tool, and for my GameMaker readers, there is a nice script for using this with GM here.

SHADERed is a neat offline tool for editing, debugging, and profiling shaders in a variety of languages.

That’s all for now, thanks for reading! Have a great day!
-Xor

This is commonly used for blurring because it can be more efficient to apply a large blur in separate passes (for example, instead of a 9x9 Gaussian blur, you can do a 9x1 blur and 1x9 blur, 2*N samples instead of N^2). However, multipass effects have downsides. They are more difficult to implement, requiring surfaces/canvases, additional draw calls, and more video memory usage. They will complicate your draw pipeline process, and in some cases, are unfeasible. The alternative is to combine two shaders together. So, when is it worth it to combine shaders?

When To Combine Shaders

Here’s a quick checklist to go over when considering shader compatibility, roughly in order of most important to least important:

• Performance: Are the effects expensive? Chances are, if both shaders being combined are expensive, the combined shader will be very expensive. Unless you can think of some clever optimizations that simplify it, it’s probably not going to work!

• Sample Count: Do these shaders require lots of texture samples? If you have an outline shader that uses 8 texture samples and a blur shader that uses 32 samples, you’ll likely have to do 8 outline samples for every blur sample, meaning you’ll be using 8*32 or 256 samples! That is a lot of texture samples for moderately-sized textures! Generally, it’s safe to combine a multi-sample shader with a single sample shader, but be careful if both shaders use a lot of samples. The shader order does matter, though. If you have an expensive 1-sample shader before a cheap 8-sample blur, you have to do the expensive code 8 times! If the blurring occurs first, you’d only have to do the expensive part once.

• Coordinates: Check if the shaders are operating in the same coordinates. You might have one shader that is a screenspace effect applied to pixel coordinates on the screen, another might be world-space coordinates, or texel coordinates. That doesn’t necessarily mean they are incompatible, but it will take some unit conversion and may add some complications.

• Textures: Do your shaders require specific texture sizes? What about texture filtering (e.g., linear interpolation vs nearest neighbor)? How about texture boundaries? Distortion effects, outlines, or blurs may sample outside of the texture boundary, so you’ll have to consider how you handle these cases. Sometimes it may be texture repeat, texture clamping, or discarding outside fragments. Make sure they can be adapted to work together! You’ll also want to consider the GPU settings: mainly blend modes and alpha testing.

• Uniforms and Inputs: When combining shaders, you’ll need all the uniforms from both of the shaders. While the limits are pretty high, shaders do have limits, especially when it comes to having lots of large textures or uniform arrays. You also want to make sure the shader inputs and outputs match (attributes and varyings in old-school GLSL). The good news is that sometimes you can reduce shader complexity by reusing uniforms for both effects (like resolution or time).

If you’ve made it past that, then you’re probably ready to start combining!

Merging Shader Code

That checklist also hints a bit about how shaders are combined. The first step is to turn your shaders into functions. Let’s start with a sample grayscale shader like this:

//Saturation macro (0.0 = gray, 1.0 = full color)
#define SATURATION 0.0

varying vec2 v_vTexcoord;

void main()
{
    vec2 uv = v_vTexcoord;

    //Sample base texture.
    vec4 tex = texture2D(gm_BaseTexture, uv);
    
    //Output color and alpha
    vec4 col = tex;
    //Grayscale luma
    //https://GMshaders.com/tutorials/tips_and_tricks/#useful
    float gray = dot(tex, vec4(0.299, 0.587, 0.114, 0.0));
    //Mix between gray and color with saturation
    col.rgb = gray + (col.rgb - gray) * SATURATION;
}

We can rewrite this as a function, with fragment shader inputs as the arguments. In this case, we just have the UV coordinates:

//Simple saturation shader:
vec4 saturation(vec2 uv)
{
    //Sample base texture.
    vec4 tex = texture2D(gm_BaseTexture, uv);
    
    //Output color and alpha
    vec4 col = tex;
    //Grayscale luma
    //https://GMshaders.com/tutorials/tips_and_tricks/#useful
    float gray = dot(tex, vec4(0.299, 0.587, 0.114, 0.0));
    //Mix between gray and color with saturation
    col.rgb = gray + (col.rgb - gray) * SATURATION;
    
    return col;
}

Uniforms and macros can be directly referenced in the function, so they do not need to be added as arguments. This is a fairly light-weight function. It doesn’t require a bunch of texture samples, for-loops, branching, or lots of math. Now let’s say you want to combine it with this chromatic aberration shader:

Following a similar process, we end up with this function for radial CA:

//From GM Shaders Chromatic Aberration:
//shadertoy.com/view/DtGSRt

//Chromatic blur intensity
#define BLUR 0.05
//Chromatic constrast
#define CONTRAST 2.0
//Must be an even number
#define SAMPLES 20.0

vec4 chromatic(vec2 uv)
{
    //Color output starts at 0.
	vec4 color_sum = vec4(0);
    vec4 weight_sum = vec4(0);
    
    //Iterate 20 times from 0 to 1
	for(float i = 0.0; i<=1.0; i+=1.0/SAMPLES)
    {
        //Add a texture sample approaching the center (0.5, 0.5)
        //This center could moved to change how the direction of aberation
        //The mix amount determines the intensity of the aberration smearing
        vec2 coord = mix(uv, vec2(0.5), BLUR*(i-0.5));
        
        vec4 weight = vec4(i,1.0 - abs(i+i-1.0), 1.0-i, 0.5);
        weight = mix(vec4(0.5), weight,  CONTRAST);
        
        //Here we use the saturation effect as input
        vec4 color = texture2D(gm_BaseTexture, coord);
	color_sum += color * color * weight;
        //Shift sample tint color from red to green to blue
        //The total should be multiplied by the 2/number of samples, (e.g. 0.1)
        weight_sum += weight;
     }
        
    //Output the resulting color
    return sqrt(clamp(color_sum / weight_sum, 0.0, 1.0));
}

Now that we have both shaders as functions, we can put them together in one fragment shader. While we’re doing that, we should combine the uniforms, macros, functions, and shader inputs. This is a good time to remove any redundancies you find along the way and share functions and uniforms if possible.

Order of Effects

Now is the point where you can actually combine the two functions as needed. In this case, I want to apply the desaturation first and then apply the chromatic aberration. To do this, I need to replace the texture2D in the “chromatic” function with my “saturation” function. If I wanted to apply the chromatic aberration first and desaturate after, I would put the chromatic function inside the saturation function. This way would be faster because it wouldn’t require executing the saturation function within a for-loop, but we don’t want to desaturate after applying a color effect.

I’ve put together a ShaderToy example for this.

Newsletter Update

Just a heads-up, the cost for paid subscriptions is going up to $8/mo or $80/yr soon. This will help me keep a consistent schedule and take fewer contracts. If you’ve ever wanted to join, now is the last chance to get it for $50/yr!

Thank you for the support!

Conclusion

Thankfully, the process for combining shaders is intuitive most of the time. It can be summed up be turning your shaders into functions and feeding one function into another as needed. The inner function is applied first. It’s preferable to do the most samples first because shader costs can compound quickly.

To recap, before you consider combining, you should look at:

Performance - Expensive shader + expensive shader ≈ very expensive!

Sample Count - Avoid combining shaders that use a lot of texture samples.

Coordinates - Make sure the type of coordinates matches up correctly.

Textures - They should share texture settings and formats.

Inputs - Vertex formats, uniforms, and varying will have to match up.

If you pass that test, then it may be worth trying.

Extras

Here are my 3 examples of one-pass blur shaders

1 Pass Blur - A simple, cheap disk blur based on the golden angle.

Mip Blur - An efficient blur that makes use of mipmapping.

Bokeh - A rich Depth of Field effect that is good for backgrounds.

That’s all for today. Thank you for reading and have a great night!

-Xor

Maybe it’s been a few years since you’ve taken a math class, or you’ve never had a strong educational mathematical foundation to begin with. This article is aimed specifically to serve as a reference point to help get you caught up to speed. I was homeschooled and taught myself after Geometry, so I know firsthand how challenging it can be to approach on your own! I have even learned a bit while writing this. If you get stuck somewhere along the way, don’t worry; that’s perfectly normal! Skip that part, or take a break and revisit it later. Hopefully, this will save you lots of time on your journey and give you new mathematical tools to use!

Basic Notation

At this point, you’re familiar with the concepts of scalars (floats), vectors, and matrices, but they are written differently in mathematics papers, so it’s important to know what to look for. Because countless people developed the field of mathematics over the course of thousands of years, there are many different ways things can be written, making it a little more difficult to interpret. This article will serve as a general guideline, but there are exceptions to watch out for.

Scalars are one-letter variables like “a” or “b”.

Vectors are usually written as a boldface “v” or with a right arrow over top, like so v⃗.

Vector components are written in subscript, starting from 1, 2, 3… (not 0), or often just x, y, z, like in GLSL:

Hats are used for unit vectors (normalized vectors with a length of 1.0): â. Cute right?

Matrices are typically written with capital letters like “A”, and the values are arranged in big square brackets, row by row, with spaces to separate components. Sometimes matrices with one row or one column are used as vectors. I wrote an article about matrices if you’d like to learn more!

Tensors are the extension of the idea of scalars (0th order tensors), vectors (1st order tensors), and matrices (2nd order tensors). A first-order tensor can be thought of as a 1D array or vector, and as you can imagine, a third-order tensor is the same as a 3D array. So you’ve already been using Tensors, whether you knew it or not.

Operations

Multiplication is generally just two or more variables concatenated. “ab” is the same as “a*b”. In arithmetic, scalar multiplication may use “a×b” or “a·b”, but it is not to be confused with vector cross products or dot products. We’ll cover that later!

Summations (Σ) and Products (Π) can be recreated using for loops (within reasonable limits). Here’s a handy illustration from Freya Holmer:

Exponentiation is written with superscript exponents: 3² = pow(3.0, 2.0).

In Boolean Algebra, you have the logical operations: “a∧b” (AND), “a∨b” (OR), “¬a” (NOT), and “a⊕b” (XOR, yes… that’s where my username comes from). Boolean equivalence can be written with “a≡b” which would be written as “a==b” in most programming languages. Not-equal is written with “a≠b”

The Absolute Value operation is written with vertical bars like “|x|” instead of the “abs(x)” function.

Vector Length is written with double vertical bars like “||v||”. So, for example, you could write a normalized vector “a” like so:

Dot Products and Cross Products are written with “⋅” and “×” respectively. Not to be confused with arithmetic scalar multiplication. The dot product may also be written as an Einstein Summation, but it does the same thing:

Functions

Functions are typically written like “f(x, y) = x+y” with x and y being the function arguments and “x+y” being the returned value. Sometimes, unambiguous functions are written without parentheses, like “sin x”.

Inverse functions undo the operation of another function. They are typically written like “f^-1(y) = x”. For example, if you have “f(x) = x+2”, then the inverse function would be “f^-1(x) = x-2”. Not all functions are invertible. For example, with ‘f(x) = x²’, ‘f⁻¹(25)’ could be 5 or -5 because both 5² and (-5)² equal 25. A function needs a unique output for every input (one-to-one) to have a proper inverse.”

Arrow Notation may also be used for “inline” functions. For example, an incrementing function could be written like “x ↦ x+1”. So, if x = 5, the output is 5+1 or 6. Barred arrows “↦” are used for remapping elements, while unbarred arrows “→” are used to describe “sets”, which we will cover next.

Set Theory intuitively has to do with sets of numbers. You have Natural Numbers: 1, 2, 3… and these are just positive whole numbers (so no fractions or decimals). Integers include negative numbers: …-2, -1, 0, 1, 2… and are written as “int” in GLSL. Here’s a quick list of the main relevant sets:

• ℕ - Natural numbers, positive whole numbers: 1, 2, 3… In some math contexts, 0 is included (written as ℕ₀), but we’ll stick to excluding 0 (ℕ₁) unless noted, aligning with positive integers. Compare this to uint in GLSL, which starts at 0..

• ℤ - Integers, positive, negative or zero, whole numbers: … -1, 0, 1… These are “ints” in GLSL.

• ℚ - Rational numbers, include integers, fractions, and decimals like 1/2 or -0.8. They include any number that can be written as a ratio of two integers: x/y. “floats” are generally rational numbers that can be written as a ratio. The exceptions are positive infinity, negative infinity, and the undefined “Not a Number”.

• ℝ - Real numbers, include rational numbers and irrational numbers like sqrt(2.0), log(7.0), or π. These numbers cannot be represented with just fractions (decimals), and they have to be rationally approximated with floats. The positive-only real number set is written with a plus: ℝ⁺.

• ℂ - Complex Numbers, include imaginary numbers like “i” and numbers with both real and imaginary components like “2+i”. Most programming languages do not support Complex Number calculations directly, but they can be thought of as 2D vectors with both a real component and an imaginary “i” component. I won’t get into imaginary numbers here, but if you do come across them (e.g., with sqrt or the log of a negative), you will have to calculate the imaginary components manually to avoid errors. All GLSL functions return “undefined” when an imaginary number would occur, so you’ll have to handle these edge cases yourself. A common example might be the Mandelbrot Set or quaternions.

• ∅ - Empty Sets contain nothing.

• {a, b, c} - Finite Sets can contain any number of elements. For example, sign(x) returns values in the set {-1, 0, +1}.

• [a, b] - Closed Intervals include “a”, “b”, and all real numbers between. Parentheses can be used instead of square brackets for “Open Intervals”, which exclude the endpoint numbers. For instance, fract(x) returns a value between 0.0 and 1.0. This is an interval of [0 1). Why? Well, with an input of x=0.0, you get an output of 0.0, but with an input of 1.0, you also get an output of 0.0. You can get close to 1.0, like 0.999, but the interval does not include 1.0. This concept is quite useful to know!

• ∈ - Element of Set, used to show when a number or variable is an element of a set like: “x ∈ ℝ”. This means that “x” is a real number. “∉” is used when an element is not a member of a set.

Hopefully, that wasn’t too overwhelming. The most important are real numbers, sets, and intervals because they show up the most. Now, let’s put Set Theory together with Arrow Notation and look at an easy example of the sign function:

This tells us that “sgn” takes a real number input (between -∞ and +∞) and remaps it to the set -1, 0, or 1. Thankfully, the if-statement logic is pretty intuitive to us programmers:

//Reconstructed sign function
//"x" is any number between -∞ and +∞
float sgn(float x)
{
    if (x >0.0) return +1.0; //Positive numbers
    if (x==0.0) return  0.0; //Zero
    if (x <0.0) return -1.0; //Negative numbers
}

Now on to function domains and ranges…

Read more

What do water, fire, dust, magic, wind, fog, smoke and clouds have in common? They are all heavily influenced by turbulent dynamics.

Gases and non-viscous liquids twirl and flow in a way that is quite difficult to compute. There is a lot of mathematical research into problems of fluid and there is even a $1,000,000 prize if you solve one of them. I don’t say this to discourage you, but I felt this context is important.

Today, we are not going to be solving the Navier-Stokes equations (but I will include some resources at the end if you want to). Instead, we will fake it! Proper simulations require multiple shader passes, are slow, memory intensive, and are limited by resolution. Most of the time, we can get away with cheaper real-time approximations and still create impressive effects. Let’s hop in!

Waves

In essence, all we need to do is add some sine wave displacement. We’ll need to rotate each wave separately to create some curves and break up the visible alignment patterns. The rotation angle isn’t super important as long as the results look natural (not 90 degrees or 45 degrees). For better results, we can also increase the frequency and decrease the amplitude proportionally.

Making a simple horizontal wave might look like this:

//Shift the x-coordinates with a sine wave
pos.x += WAVE_AMP * sin(pos.y * freq) / freq;

WAVE_AMP can be a constant or macro between 0.0 and 1.0 which sets the overall waviness and the frequency can increase with each pass.

We can rotate with a mat2x2, “rot” and animate with the waves with a time uniform:

//Scroll along the rotated y coordinate
float phase = freq * (pos * rot).y + WAVE_SPEED * u_time;

//Add a perpendicular sine wave offset
pos += WAVE_AMP * rot[0] * sin(phase) / freq;

Now let’s bring it all together with a loop like so:

//Number of turbulence waves
#define TURB_NUM 10.0
//Turbulence wave amplitude
#define TURB_AMP 0.7
//Turbulence wave speed
#define TURB_SPEED 0.3
//Turbulence frequency
#define TURB_FREQ 2.0
//Turbulence frequency multiplier
#define TURB_EXP 1.4


//Turbulence starting scale
float freq = TURB_FREQ;

//Turbulence rotation matrix
mat2 rot = mat2(0.6, -0.8, 0.8, 0.6);

//Loop through turbulence octaves
for(float i=0.0; i<TURB_NUM; i++)
{
    //Scroll along the rotated y coordinate
    float phase = freq * (pos * rot).y + TURB_SPEED*iTime + i;
    //Add a perpendicular sine wave offset
    pos += TURB_AMP * rot[0] * sin(phase) / freq;

    //Rotate for the next octave
    rot *= mat2(0.6, -0.8, 0.8, 0.6);
    //Scale down for the next octave
    freq *= TURB_EXP;
}

Here’s an illustration of the compounding waves:

Here we are starting with a red and green grid to visualize wave distortions. On the left side, we add the first wave (highlighted in blue). The blue arrow represents the direction and length of the waves. As we move right, we add additional waves, and you can see the compounding distortion as more waves are added. This simple effect is enough to create a sense of turbulence in the coordinates.

We can use a texture or noise instead of a grid. Even just 8 iterations can produce convincing results!

Try my full ShaderToy demo here. By adjusting the parameters you can get smooth or swirly turbulence. Here’s what various frequency multiplier values look like”

Increasing the multiplier makes finer, more detailed whirls.

Fire

This technique works great for fire as well!

It follows the same basic principle with the layering waves, but also with scrolling upward and stretching the coordinates. It starts with the waves tightly compressed horizontally and stretched vertically to simulate fast expansion upwards. As it rises, the space stretches out horizontally and squishes a little vertically for horizontal expansion. It’s pretty subtle, but these fine tweaks can make a big difference.

I won’t put the code here, but you can check out the full source code over on ShaderToy as well!

Conclusion

The technique for fluid-like motion is surprisingly simple, yet it produces some pretty decent results! In real-time applications, full fluid simulations are often too expensive, complicated, or too limited to be practical. This method is very practical in a wide range of applications like fluids, flames, steam, smoke, or magic effects!

To recap, it all starts with a sine wave. Just shift the coordinates with a sine wave, rotate, scale, and repeat. After just a few iterations, you’ll get some nice swirls and fluid motion!

Now subscribers can help pick the next tutorial

Extras

Here are some great resources I found while putting this tutorial together:

Navier Stokes by Gijs: This is an excellent example of how simple a Navier Stokes simulation can be implemented in 2D with minimal code!

Chimera's Breath by Nimitz: Taking the simulations a bit further with “vorticity confinement”, this shows off some impressive 2D fire and smoke effects.

Cloud Simulation by wyatt: Here is a good example of a 3D steam cloud simulation.

Fast Fluid Dynamics Simulation on the GPU by Mark J. Harris: For a thorough tutorial on fluid simulation, start here! It covers some of the background context, math, and the implementation.

Okay, that’s it for today. Au revoir!

I will be referring to Inigo Quilez’s work a lot today because he’s published many great articles on the topic, however, I’ll try to summarize as much as I can here.

In short, SDFs are functions that describe shapes. More specifically, the distance to a shape’s surface at any given point. The “Signed” part means it will return a negative distance value if the sample point is inside the shape and a positive distance if outside.

That’s it. Now you know what a Signed Distance Field is! These functions are far more useful than you might think.

Why you should learn this

What can you do with SDFs? Let’s look at a few examples

Shapes

Firstly, it’s a nice way to draw vector shapes with pure code. Some have even recreated Rick from Rick and Morty using just SDFs! There are many ways to draw shapes in shaders, but SDFs can make the process of building and editing these shapes more intuitive. There are lots of useful operations that can be applied to them.

I’ve recently written about the process of anti-aliasing, and it can be challenging to implement, but not with SDFs. With SDFs, it’s super easy to implement!

Outlines, lights and drop shadows

Better yet, we can easily add outlines of any thickness when we know the distance from each pixel to the shapes:

float outline_dist = dist - outline_thickness;

You can add glow effects or soft drop shadows when using the distance field as well.

I wrote in more detail about these effects here:

Raymarching

You can even do raycasting or physics simulations with SDFs. Raymarching with distance fields is more intuitive than raytracing, and it’s much easier to build and modify the shapes with raymarching. You can use raymarching in 2D for cheap soft shadows, but the formulas also work well for 3D rendering.

I wrote in more detail about raymarching here (the burgers shown below are fully modeled in code using SDFs too!):

I could go on with some cool technical goodies like: Ambient Occlusion, Depth of Field, collision detection, calculating normals, and more, but hopefully, this is enough to pique your interest! So now that you know a little about how they can be used, how do you actually find the formulas?

How to find them

As much as I like to reinvent the wheel, I can’t recommend writing your own SDFs just yet. Inigo Quilez has done a ton of work to find efficient and exact formulas for many different shapes.

And not just in 2D, but in 3D as well! If you’re just starting out, this is the best way to get a feel for SDFs. Once you get more comfortable, you can experiment with writing your own.

Modifications

Let’s look at some ways you can adapt your distance field for extra variations.

The first class of modifications is distance modifications:

Distance Mods

We can make any shape rounded by subtracting by the desired thickness:

//Set outline thickness around the shape
float round_dist = shape_dist - thickness;

Note: This will make the shape larger, so you will have to reduce the size by the thickness first, which will depend on the shape.

You can also create hollow shapes from any SDF like so:

//Make hollow and set thickness
float hollow_dist = abs(shape_dist) - thickness;

Just for fun, onion-layered distance fields can be made like this:

//Repeat in spaced-out layers
float layered_edge = mod(shape_dist + spacing/2.0, spacing) - spacing/2.0;
//Set layer thickness
float layered_dist = abs(layered_edge) - thickness;

Maybe it’s not the most practical, but it’s a neat trick.

Set Operations

You can combine (union) two distance fields together by taking the minimum of both:

//The union of two distances fields
float union_dist = min(shape_dist1, shape_dist2);

When you think about it, it makes sense. The distance to the closest shape exterior edge will be the lesser of the two distances. And of course, to combine 3 or more shapes, you can just repeat it as needed.

Note: it does break sometimes the interior distance, returning a greater distance than it should. These breaks aren’t usually a big deal, but they can break outline thickness or require more steps to raymarch!

To subtract one shape from another:

//Subtract shape 2 from shape 1
float sub_dist1 = max(shape_dist1, -shape_dist2);

//Subtract shape 1 from shape 2
float sub_dist2 = max(shape_dist2, -shape_dist1);

Or to find the overlapping/intersection of two shapes:

//The intersection of two distances fields
float intersect_dist = max(shape_dist1, shape_dist2);

Note: Union can break the interior distance field, while intersection and subtraction break the exterior distance field. To my knowledge, this is still an unsolved problem, requiring case-by-case solutions or JFA. Read iq’s interior distance article for more insights into this problem.

Spatial Mods

What about modifying the coordinate space itself?

You can mirror the y-axis by using the absolute of y (flipping the negative back to positive):

//Mirror the y-axis
pos.y = abs(pos.y);
//Use these mirrored coordinates with your SDF
float shape_dist = sdf(pos);

You can also flip across an arbitrary (normalized) direction like so:

//Flip in the direction "dir":
vec2 mirror_pos = pos - 2.0 * dir * max(dot(pos, dir), 0.0);

Note: This works best if you’re mirroring perpendicular to the shape’s edge. If you look closely at the left star example above, the mirrored shape creates concave edges, breaking the interior distance field. The new distance field doesn’t know there’s a corner there. Mirroring the bottom half will create a new concave edge and break the exterior.

You can also repeat shapes infinitely by tiling. The simplest way is with mod:

//Repeat the coordinates
vec2 repeat_pos = mod(pos + spacing/2.0, spacing) - spacing/2.0;

This method works for symmetrical shapes like circles and squares however for irregular shapes, it may take a little more work. For instance, these stars are symmetrical horizontally so the left and right sides tile seamlessly, but not vertically:

In this case, it can be solved by sampling the distance field one unit above and below to find the minimum. iq has a written great article on this and much more!

Distortion Mods

If we don’t care about exact accuracy, there are many distortions that can be done.

Minor displacements can be added directly to the distance field for distortions.

Twisting and rotating can be applied directly to the coordinate spaces.

Smooth union, subtraction, and intersections are possible with approximations:

//Exponential smooth minimum
float smin( float a, float b, float k )
{
    float r = exp2(-a/k) + exp2(-b/k);
    return -k*log2(r);
}

Rather than reinvent the wheel, I’ll refer to iq’s work with smooth blending functions here.

Again, these are no longer exact distance fields, but distorted approximations, and the more distorted they become, the more difficult they may be to work with. Now I think we’re ready to talk about constructing our own distance functions!

Read more

You may know of Gamma as a brightness slider in games, but there’s much more to it than that. Color, specifically luminance, is often stored and displayed differently to how light behaves in real life. There are two main formats: linear color (as in real life) and Standard RGB or “sRGB” (encoded light). Images are stored in sRGB because it’s a more efficient use of bits, but it’s incorrect to do our lighting operations in sRGB, so we need to know how to convert back and forth.

Even common shader effects like blurs are often done incorrectly, by not accounting for gamma correction. Here’s how gamma can affect blurring:

So, gamma is not about the overall brightness of an image. Black is still black, and white is still white, but it does affect the distribution of brightness. Doing it correctly can make a big difference in the look and feel of your game!

Encoding and Decoding

You’ve probably heard of Gamma 2.2 before. It’s been the standard in most displays for a while now, but what does the “2.2” mean? Well, the gamma number is the exponent used to map the RGB back to the linear color. Some rare monitors might have a gamma of 2.0 or 2.4, but 2.2 is the general standard to assume.
Here’s an illustration of what that looks like:

The red line represents how colors are stored (black being on the left end of the spectrum and white being on the right). You can see that the gray values in the middle are shifted downward towards darker shades. If you want to reverse this curve, you need to apply the green decoding curve, which gets us back to linear color.

With linear color, you can do any color transformations you want (like additive blending), but then, when you’re done, you need to convert the output back to sRGB.
Here are my little approximate functions to do these conversions:

//Standard gamma exponent
#define GAMMA 2.2

//Decode sRGB to linear color //Note: this is a standard approximation vec3 gamma_decode(vec3 srgb)
{
     return pow(srgb, vec3(GAMMA));
}

//Encode linear color to sRGB
vec3 gamma_encode(vec3 lrgb)
{
     return pow(lrgb, vec3(1.0/GAMMA));
}

I’ve put together a simple example using two point lights:

//Screen coordinates from -1 to +1 (aspect ratio corrected)
vec2 suv = (gl_FragCoord*2.0 - u_resolution.xy) / u_resolution.y;
//2.2 gamma on the right
//Light source positions
vec2 pos = 0.4 * sin(u_time+vec2(0,11)) * cos(u_time*0.618);

//Red light
vec3 light1 = 1.0 / (1.0 + length(suv+pos) * vec3(1,5,9));
//Blue Light
vec3 light2 = 1.0 / (1.0 + length(suv-pos) * vec3(9,5,1));

//Linear color values
vec3 lin1 = gamma_decode(light1);
vec3 lin2 = gamma_decode(light2);

//Add light sources together
vec3 col = lin1+lin2;
//Convert back to sRGB
gl_FragColor = vec4(gamma_encode(col), 1.0);

You can see the image is overexposed on the right and does not blend as cleanly. Anything that has to do with color blending or light should be done in linear color space! If you sample a texture, it will be in sRGB, so you’ll need to convert that to linear color, do your operations, and then finally convert the results back to sRGB.

Exact sRGB

Okay, I must admit I simplified a little bit. sRGB is a bit more complicated than gamma 2.2, but gamma 2.2 is a good approximation.

Here’s the real formula with a lot more magic numbers:

//Decode sRGB to linear
vec3 SRGB_decode(vec3 srgb)
{
    return mix(
        srgb / 12.92,
        pow((srgb + 0.055) / 1.055, vec3(2.4)),
        step(0.04045, srgb)
    );
}

//Encode linear to sRGB
vec3 SRGB_encode(vec3 lrgb)
{
    return mix(
        12.92 * lrgb,
        1.055 * pow(lrgb, vec3(1.0 / 2.4)) - 0.055,
        step(0.0031308, lrgb)
    );
}

The difference is quite subtle, but it does make a difference with darker shades and the upper middle:

In professional contexts where precision is essential, you’ll want to use the exact sRGB formula, but in most contexts, gamma 2.2 is a good, cheaper approximation. It’s way better than nothing!

Gamma Origins

Now that we covered the basics, here’s a little background context.
The sRGB format originated because the old Cathode-Ray Tube displays had a non-linear relationship between the input voltage and the output pixel brightness (usually a gamma of 2.2 to 2.5). This was convenient because our eyes do not perceive lightness linearly either, and we are more sensitive to changes in darker shades than lighter ones, so if we have a limited number of bits to store colors, we should store more darker shades.

Camera sensors capture light in linear color but store their images with gamma encoding for image storage efficiency. This is why it’s crucial to convert images back to linear color before you do anything with them!

Conclusion

As with many topics, gamma correction can be quite complicated, and this tutorial only scratches the surface. I hope that this will make the concepts more approachable so that you can do further experimenting and learning as you go, just with a bit more context about how computers handle colors.

If I could reduce this tutorial down to one point, it’d be that computers store colors at the power of 1/2.2 (sRGB), and if you want to do any math with your colors, you should convert to linear first and then finally convert the end results back to sRGB. This one lesson is actually super important, and not enough shader people do this, so it’s best to start now! As always, I’m including some additional resources below

Extras

John Novak has an excellent and thorough guide on everything about gamma! If you need a little more clarity on anything, I’d check here first!

Kostas Anagnostou wrote about the hidden cost of shader instruction,s which explains why some functions are much slower than others. Avoid the arc trigonometry functions like atan and aco,s particularly!

Thanks for reading! Have a great night!
-Xor

Aliasing occurs when we have more color data than we can fit in the pixels. There are many ways to approach this. We could sample multiple points per pixel and average the results, but this can get expensive at higher resolutions.
In real life, cameras don’t have this issue because the pixel sensors receive zillions of photons to construct an image. They aren’t limited to one sample per pixel. We don’t have the luxury of simulating every photon, so we’ll have to find a way to approximate them.

Previously, we looked at a post-processing solution:

FXAA is a decent generalized solution, but it sometimes can cause unintended softening or other artifacts. There’s only so much that can be done with post-processing on the pixel colors. Let’s take a deeper look at the anti-aliasing process to expand our toolset!

Circle Example

The simplest example I could think of is drawing a circle. You could draw a circle by checking if a pixel is within the radius of the circle:

gl_FragColor = vec4(dist < rad);

This method introduces hard pixel edges. Alternatively, if you know (or can approximate) how close a pixel is to the edge, you can do a little sub-pixel gradient along that edge. This is easy to do with a circle because we already have the distance.

Here’s a close-up illustration of a circle with and without anti-aliasing:

The green dots represent the centers of each pixel. On the left side of the blue line, we simply check if the distance from the pixel to the center of the circle is within the radius. On the right side, we estimate how much of the pixel is within the radius. This could be calculated with complicated integrals of our function, but that is overkill!

Instead, a simple and effective approximation is to use the same distance value as earlier, but we blend from 0 to 1. So if the center of the pixel is on the radius line, we should expect 50% opacity. 50% roughly of the pixel is within the radius and 50% is out (it depends on the radius, but the effects are negligible). We should expect 100% opacity when the circle_radius - pixel_distance is greater than 0.5 pixels because it means that the radius is at the outside edge of the pixel. And we can expect 0% opacity when less than -0.5 pixels because that is the inside edge of the pixel.

So now all we need to do is make sure the distance is in pixel units and clamp the gradient to the [0, 1] range. We can divide by our “texel” scale to correct for

float gradient = clamp((radius - dist) / texel + 0.5, 0.0, 1.0);

Now the opacity can be set based on how close the pixel is to the edge, instead of just doing a distance check. I’ve put together a ShaderToy demo for more details here.

The best part is this method works with all Signed Distance Fields! All you need is to correct the scale of the distance field so that the 0 to 1 range matches the pixel scale. This method is perfect when you know the distance to the edges and the scale, but what if it’s not a perfect distance field? What if the gradient is inconsistent? A common example is with noise functions where some areas may have steep gradients while other spots can be flat. If this is your case, we’ll need to go further!

Derivative Methods

Let’s look at an example with a noise function. We can still get a gradient edge by doing: some_threshold - noise_value, which should generally return higher values as we get further from the edge, but not reliably. Noise is supposed to be unpredictable so it makes this more difficult.

If we try to use a constant scaling factor for the edges as on the left, some edges may be too soft while others could be too sharp. On the right, we are using the same method as before, but we’re calculating the gradient scale for every pixel, which leads to more consistent edges.

This is still an approximation, but it’s a step in the right direction and a big improvement on our previous method!
We can approximate the rate of change in the gradient by using derivatives. Definitely read my article on the topic if you haven’t yet because it’s important here!

The super simple solution here is to use fwidth() to calculate our scaling factor for us. The best part is that this works with most things out of the box:

//Approximate the smooth edges from any continuous function
float antialias_l1(float d)
{
    //Divide d by it's derivative width
    return clamp(0.5 +  d / fwidth(d), 0.0, 1.0);
}

Note: We should be careful about potentially dividing by 0 here! You can do a quick check like so: float scale = width>0.0? 1.0/width : 1e7;

I like to take things a little further and calculate my fwidth manually with length. This produces better results at a slightly higher cost:

//Approximate the smooth edges from any continuous function
float antialias_l2(float d)
{
    //x and y derivatives
    vec2 dxy = vec2(dFdx(d), dFdy(d));    
    //Get gradient width
    float width = length(dxy);
    //Calculate reciprocal scale (avoid division by 0!)
    float scale = width>0.0? 1.0/width : 1e7;
    //Normalize the gradient d with its scale
    return clamp(0.5 + 0.7 * scale * d, 0.0, 1.0);
}

This magic formula can blend the edges of just about any continuous function. It can handle a heavily distorted distance field, noise, and gradients of any sort. It’s only weakness is discontinuous functions since they break the derivatives. A distance expression like dist = floor(x/10.0) will not work because it jumps in steps and there is no gradient width to even approximate the scale with. If this is an issue for your shader needs, continue to the final step!

Edge Cases

There may be some instances where the partial derivatives computed with dFdx and dFdy are not good enough. Even something simple like a checkerboard can seem challenging to do, but there are two ways to solve it. You can either try to get rid of the discontinuities or you can calculate the derivative manually. A checkerboard can also be achieved with a formula like sin(x*PI)*sin(y*PI). This gives a continuous function that ranges from -1 to 1.

Also, sometimes 2x2 derivative chunks are not suitable for your shader or not precise enough. In these cases, you may have to calculate the derivatives manually.

Here’s an example of artifacts produced from coarse derivatives:

For these scenarios, we’ll use this function:

//For when the derivatives must be manually calculated
float antialias_l2_dxy(float d, vec2 dxy)
{
    //Get gradient width
    float width = length(dxy);
    //Calculate reciprocal scale (avoid division by 0!)
    float scale = width>0.0? 1.0/width : 1e7;
    //Normalize the gradient d with its scale
    return clamp(0.5 + 0.7 * scale * d, 0.0, 1.0);
}

Then we can generate our own partial derivatives like so:

//Get gradient (neighbors for manual derivatives) 
float grad00 = grad(pos);
float grad10 = grad(pos+vec2(1,0));
float grad01 = grad(pos+vec2(0,1));
//Compute the xy derivatives
vec2 dxy = vec2(grad10, grad01) - grad00;

Note: This is more expensive than the native derivative functions, which compute derivatives for nearly free! This is sampling our gradient function 3 times, so it should be used cautiously with larger or more complicated functions.

This manual derivative method can be used for anti-aliasing on multiple layers. A common example is with stripy patterns that have many edges:

Let’s say we have a stripe gradient “grad” that we want to range from 0 to 5 for 5 stripes. The edges separating the stripes, can be found with fract(grad) - 0.5, but fract is discontinuous and will break our derivatives. So for this, we want to calculate our derivatives on the original “grad” variable. I’ve put together a shader example here.

This same method can even be applied to pixel art anti-aliasing, but you do it on the x and y axes simultaneously using texture interpolation. I’m not going to go over the details here, but there are excellent resources out there on this topic if you’re interested!

Conclusion

To summarize, anti-aliasing is all about smoothly filtered edges without requiring rendering a higher resolution and downscaling. Today we covered the main 3 levels of filtering which can be used depending on the situation.

For simple shapes like circles, lines, squares, or Signed Distance Fields, it’s pretty trivial to generate smooth edges cheaply and there are very few reasons not to! It’s just a matter of matching the gradients to the pixel scale for consistent edge thickness.

Most other shaders will have more complicated shapes where we won’t have the luxury of knowing the exact distance to the nearest edge, but that’s okay. As long as we have a gradient that generally points towards the nearest edge, we can approximate the distance with derivatives (measuring the rates of change). The math can sound scary, but it’s usually not much more than fwidth(). Using the antialias_l2() function above should handle most situations without much work!

Finally, there are scenarios where you don’t even have a gradient or where gradient is discontinuous (has breaks in it). These cases require a little more work on a case-by-case basis, but many times you can rework it to make the gradient continuous or calculate the derivatives using a continuous, break-less version of the gradient. The derivatives only care about the rate of change and not the absolute value, so they can use independent formulas!

Hopefully, this guide gives you a good idea of how anti-aliasing actually works and how you can start to implement it into your own shaders! This is something every shader programmer should know because it’s useful all of the time. It’s better to produce smooth images from the start than to produce something rough and try to filter it after the fact.

Extras

“Exploring ways to mipmap alpha-tested textures” by ‪Nikita Lisitsa‬ (@lisyarus)

This is a nice overview on handling grass or vegetation textures in large-scale games. Grass textures tend to suffer when viewed from a distance because they are either too sharp (aliasing) or too blobby, but SDFs can be used to address that.

Here’s a reminder of why you should avoid using a lot of trig functions, especially atan2. Generally speaking, if you are converting a vector to an angle (with atan) and then back to a vector (with cos/sin) you’re probably overcomplicating something. Many operations can be applied directly to vectors and that’s how shaders are designed to operate! One atan2 here and there isn’t the end of the world, but it’s something to consider if you’re doing it a lot.

Alright, that’s it for now.

Games like SUPERHOT, INK, Forager, BUZZ, OTXO, Thomas was alone, Minecraft and Inside are all great examples of well-polished games with relatively simple graphics.

Today’s tutorial is all about how visual design concepts and post-processing can improve the visuals of just about any game. Visual appeal is a somewhat subjective topic with a wide range of perspectives and opinions. I’m not here to tell you what style to use, but I would like to share concepts to consider when designing your games.

Color Palette

The first thing I’d consider is color palette. Coloring can be tricky, and it heavily depends on your vision for your game. Generally, it seems that programmers tend to use too many vibrant colors. It’s an easy mistake to make. If you’re not certain about coloring, you should probably use fewer colors. SUPERHOT and OXTO are great examples of games that use limited palettes of just 2 or 3 colors, producing a nice and consistent aesthetic. Dithering is also a great tool for stylizing some games.

Here’s an example from Eclipsium:

Here, I’ve applied a range of color filters and dithering directly to my textures:

In this particular case, I went with the left most coloring by @RowanFuture. It feels quite natural and while still being vibrant and warm, but you can probably imagine other types of games where the other aesthetics may be more appropriate.

It’s also a great idea to look at your screenshots in an image editor like GIMP

GIMP shows you a “histogram” which tells you the distribution and range of pixel brightnesses. Here I’ve found that the brightest pixels seem to be capped at 195 out of 255 (about 76%). This means I could boost the brightness about 30%, and it looks much better (shown on the left). Not all games need to use the full range of values, but most look better when they do!
The same adjustments can be done with the black level, but in this case, it looks good as is.

Resolution and Scale

For pixel art games, it’s especially important to consider texture resolution. You don’t want to mix different pixel art scales together without a good reason. Lower resolution portrays a smaller scale and can give a fun/silly tone. If it’s too small it can be difficult to convey details, so it’s good to get an early idea of what kind of sprites you’ll need and work around that. Higher resolutions can convey a more serious or realistic tone, but may become more time-consuming to work with.

The lower resolution textures could look better with some hand adjustments, but I’m the programmer artist, so you get the picture. Try to find a texture and screen resolution that you’re comfortable working with and stick with it consistently.
Consistent scaling can make an enormous difference in your game’s perception!

Detail Distribution

Another factor I like to think about is the distribution of details in a scene. We programmers tend to focus too much on the function of the scene/objects and can miss the bigger picture. I’ve found it helpful to pay special attention to what the distribution of details. If some objects or elements of the lots of detail, we may need to add more details to the rest of the scene. A minimalistic player sprite can look out of place in a detailed world, or vice versa.
Here’s an example scene with a somewhat detailed lock and key on a plain background:

As you can see on the right, we added a soft wave pattern and some drop shadows. This helps the objects match the scene without requiring a lot of artwork. The background here is still much softer than the objects, but that’s okay. Here, we still want to emphasize the separation of the background and interactive objects, but just with a little more to look at. You could also imagine using patches of grass or other background sprites if you have those. In some contexts, you may want a Depth Of Field effect with a focus on the foreground and a blurry background.

To summarize, develop a design language for emphasizing what should be important to the player and sprinkle in some fun flavoring where it might be missing

Lighting and Shading

Lighting is super important, not just for the overall aesthetic, but also for its usefulness in directing attention where you want it. Lighting is a tool for communicating mood and atmosphere. Make sure you’re considering the many possibilities. You could use warm orange lights or cold blue/white lights. You could have soft-blue shadows, hard-dark shadows, or no shadows at all. Whatever sort of lighting you choose, make it intentional.

I personally love soft drop shadows because they can convey depth and separate the background from the foreground. In the image, I actually put the soft shadows on top, giving it a 3D shaded look without much effort. I wrote more about that here.

Blooms and glows are a good way to draw eyes to treasure and rewards in games. Outlines are often used to highlight interactive objects when you are near. You can also use vignette or fog for an added sense of depth or to direct the player’s focus. Dap is a great example of lighting being put to good work.

Conclusion

If nothing else, I want this tutorial to demonstrate how non-artists can still make pretty things by leaning into styles they are comfortable with and working with what they have available. You don’t need the most detailed textures or the fanciest logo, you only need to be intentional and consistent. Let’s recap what we’ve covered today.
First and most importantly, be intentional with your coloring. Pick a good palette that fits your game and try to stick with it. Adjust the brightness and contrast to match your vision for the game.

Second, pick an appropriate scale and don’t causally mix different texture resolutions.

Third, pay conscious attention with distribution of texture and geometry details. Make sure there are no areas that are unintentionally lacking details. If you are consistent with your detailing, you can use it as a tool to direct your players’ focus!

Finally, using good lighting and shading! Soft shadows, glows, blooms, lights, fog and vignette effects are all great tools at your disposal. They can cover for where art might otherwise be lacking.

Jan Orszulik is an extremely talented artist and programmer who demonstrates all of these concepts put together in his game, Precursor:

You should definitely give him a follow if you haven’t already. His work is rich with post-processing and game polish.

Extras

Foxy Of Jungle is currently developing a powerful 2D light and shadow solution for GameMaker users: forum.gamemaker.io

Here’s a sneak peek for my voxel Ambient Occlusion technique.

Alright, that’s all for now. I’m away next weekend, but I intend to be back the week after. Take care!
-Xor

Today, we’re going to continue from there and get into actually implementing this in a game engine. So far, we can render blocks however we need, but we have no way of interacting with them and our map is generated on the fly. If we wanted a more complex scene, the formula could get big and expensive. We need a way of pre-generating our map so that we don’t have to every frame, and so we can edit it during runtime. Let’s start by generating a map.
This tutorial comes with a full GameMaker demo.

Map Storage

We need an efficient way to pass lots of voxel map data to the GPU. Since I’m using GameMaker for this demo, so we don’t yet have access to Shader Storage Buffer Objects or 3D textures, but we have a backup plan: Every engine has 2D textures!
If you’re implementing this in an engine that supports 3D textures, you can skip this step, but for the rest of us, let’s look at 3D Look-Up-Tables:

For our purposes, LUTs are just textures used to store data in a structured way. In a regular 2D texture, you read from a specific x and y coordinate, and you get the RGBA values back. This could work for a simple height map where at any give x and y coordinate, you get the terrain height and material data (using different color channels). For some purposes, this would be fine, but here we want to be able to have caves and to be able to stack different materials on top of each other and for that we need to add “z” layers to our texture.
The easiest way is to put all the layers on one texture, with each layer side by side. So if we have a 64x64x64 world, we could use a texture that is 64*64x64 (or 4096x64).
Then, when we need to read the texture, we add the z-layer coordinate times 64 to the x coordinate. The biggest texture we can do is 16k, which means we would only be able to go as large as 256 pixel wide cells with 64 layers unless we stack layers in the y-axis too.
You can see in the LUT above, we have 8x8 cells of 64x64 pixels. To read the z layers, you start from the top-left and go right, row by row, like reading a book. Notice the blue channel becomes brighter as you go down. We can do the same for our 3D world, and this allows us to support much larger map/chunk sizes (theoretically up to 1024x1024x256 by using splitting 16 layers vertically and horizontally). This can actually be thought of as a 4D data structure because it requires 4 resolution values (cell width, cell height, horizontal cell count, vertical cell count).

Here are the functions I’ve written to go from UV coordinates (0 to 1) to 3D voxel coordinates and back :

vec3 uv_to_block(vec2 uv)
{
    //Convert uv coordinates to pixel coordinates
    vec2 p = floor(uv * RES.xy * RES.zw);
    //Get the subcell x and y coordinates
    vec2 xy = mod(p, RES.xy);
    //Compute cell coordinates
    vec2 zw = mod((p-xy) / RES.xy, RES.zw);
    //Calculate the z value from xy cell position
    float z = dot(zw, vec2(1, RES.z));
    return vec3(xy,z);	
}

vec2 block_to_uv(vec3 b)
{
    //Clamp the z to the map height range
    b.z = clamp(b.z, 0.0, RES.z * RES.w-1.0);
    //Compute subcell coordinates
    vec2 sub_cell = fract(b.xy / RES.xy) / RES.zw;
    //Compute cell coordinates
    vec2 cell = fract(floor(b.z / vec2(1,RES.z)) / RES.zw);
    return sub_cell + cell;	
}

Read more