A series of tricks and techniques I learned doing tiny GLSL demos
In the past two months or so, I spent some time making tiny GLSL demos. I wrote an article about the first one, Red Alp . There, I went into details about the whole process, so I recommend to check it out first if you're not familiar with the field. We will look at 4 demos: Moonlight , Entrance 3 , Archipelago , and Cutie . But this time, for each demo, we're going to cover one or two things I learned from it. It won't be a deep dive into every aspect because it would be extremely redundant. Instead, I'll take you along a journey of learning experiences. See it on its official page , or play with the code on its Shadertoy portage . In Red Alp, I used volumetric raymarching to go through the clouds and fog, and it took quite a significant part of the code to make the absorption and emission convincing. But there is an alternative technique that is surprisingly simpler. In the raymarching loop, the color contribution at each iteration becomes 1/d or c/d where d is the density of the material at the current ray position, and c an optional color tint if you don't want to work in grayscale level. Some variants exist, for example 1/d^2 , but we'll focus on 1/d . Let's see how it looks in practice with a simple cube raymarch where we use this peculiar contribution: The signed function of the cube is from the classic Inigo Quilez page . For the rotation you can refer to Xor or Blackle article. For the general understanding of the code, see my previous article on Red Alp . The first time I saw it, I wondered whether it was a creative take, or if it was backed by physical properties. Let's simplify the problem with the following figure: The glowing object sends photons that spread all around it. The further we go from the object, the more spread these photons are, basically following the inverse square law 1/r^2 , which gives the photons density, where r is the distance to the target object. Let's say we send a ray and want to know how many photons are present along the whole path. We have to "sum", or rather integrate, all these photons density measures along the ray. Since we are doing a discrete sampling (the dots on the figure), we need to interpolate the photons density between each sampling point as well. Given two arbitrary sampling points and their corresponding distance d_n and d_{n+1} , any intermediate distance can be linearly interpolated with r=\mathrm{mix}(d_n,d_{n+1},t) where t is within [0,1] . Applying the inverse square law from before ( 1/r^2 ), the integrated photons density between these 2 points can be expressed with this formula (in t range): t being normalized, the \Delta t is here to covers the actual segment distance. With the help of Sympy we can do the integration: So the result of this integration is: Now the key is that in the loop, \Delta t stepping is actually d_{n+1} , so we end up with: And we find back our mysterious 1/d . It's "physically correct", assuming vacuum space. Of course, reality is more complex, and we don't even need to stick to that formula, but it was nice figuring out that this simple fraction is a fairly good model of reality. In the cube example we didn't go through the object, using . But if we were to add some transparency, we could have used instead, where could be interpreted as absorption and the pass-through, or transparency. I first saw this formula mentioned in Xor article on volumetric . To understand it a bit better, here is my intuitive take: the causes a potential penetration into the solid at the next iteration, which wouldn't happen otherwise (or only very marginally). When inside the solid, the causes the ray to continue further (by the amount of the distance to the closest edge). Then the multiplication by makes sure we don't penetrate too fast into it; it's the absorption, or "damping". This is basically the technique I used in Moonlight to avoid the complex absorption/emission code. See it on its official page , or play with the code on its Shadertoy portage . This demo was probably one of the most challenging, but I'm pretty happy with its atmospheric vibe. It's kind of different than the usual demos for this size. I initially tried with some voxels, but I couldn't make it work with the light under 512 characters (the initialization code was too large, not the branchless DDA stepping). It also had annoying limitations (typically the animation was unit bound), so I fell back to a classic raymarching. The first thing I did differently was to use an L-∞ norm instead of an euclidean norm for the distance function: every solid is a cube so it's appropriate to use simpler formulas. For the light, it's not an illusion, it's an actual light: after the first raymarch to a solid, the ray direction is reoriented toward the light and the march runs again (it's the macro). Hitting a solid or not defines if the fragment should be lighten up or not. A bad surprise of this demo was uncovering two driver bugs on mobile: The first was worked around with the macro (actually saved 3 characters in the process), but the 2nd one had to be unpacked and made me lose 2 characters. Another thing I studied was how to set up the camera in a non-perspective isometric or dimetric view . I couldn't make sense of the maths from the Wikipedia page (it just didn't work), but Sympy rescued me again: Inspecting the matrices and factoring out the common terms, we obtain the following transform matrices: The ray direction is common to all fragments, so we use the central UV coordinate (0,0) as reference point. We push it forward for convenience: (0,0,1), and transform it with our matrix. This gives the central screen coordinate in world space. Since the obtained point coordinate is relative to the world origin, to go from that point to the origin, we just have to flip its sign. The ray direction formula is then: To get the ray origin of every other pixel, the remaining question is: what is the smallest distance we need to step back the screen coordinates such that, when applying the transformation, the view wouldn't clip into the ground at y=0 . This requirement can be modeled with the following expression: The -1 being the lowest y-screen coordinate (which we don't want into the ground). The lazy bum in me just asks Sympy to solve it for me: We get z>\sqrt{2} for isometric, and z>\sqrt{3} for dimetric. With an arbitrary scale of the coordinate we end up with the following: The is an arbitrary small value to make sure the y-coordinate ends up above 0. In Entrance 3, I used a rough approximation of the isometric setup. See it on its official page , or play with the code on its Shadertoy portage . For this infinite procedurally generated Japan, I wanted to mark a rupture with my red/orange obsession. Technically speaking, it's actually fairly basic if you're familiar with Red Alp. I used the same noise for the mountains/islands, but the water uses a different noise. The per octave noise curve is , with the particularity of shifting the coordinate with its derivative: . This is some form of domain warping that gives the nice effect here. When I say , I'm really referring to the x-axis position. It is not needed to work with the z-component (xz forms the flat plane) because each octave of the fbm has a rotation that "mixes" both axis, so is actually backed in . I didn't come up with the formula, but found it first one this video by Acerola . I don't know if he's the original author, but I've seen the formula being replicated in various places. See it on its official page , or play with the code on its Shadertoy portage . Here I got cocky and thought I could manage to fit it in 512 chars. I failed, by 90 characters. I did use the smoothmin operator for the first time: every limb of the body of Cutie is composed of two spheres creating a rounded cone (two sphere of different size smoothly merged like metaballs). Then I used simple IK kinetics for the animation. Using leg parts with a size of 1 helped simplifying the formula and make it shorter. You may be wondering about the smooth visuals itself: I didn't use the depth map but simply the number of iterations. Due to the nature of the raymarching algorithm, when a ray passes close to a shape, it slows down significantly, increasing the number of iterations. This is super useful because it exaggerate the contour of the shapes naturally. It's wrapped into an exponential, but defines the output color directly. I will continue making more of those, keeping my artistic ambition low because of the 512 characters constraint I'm imposing on myself. You may be wondering why I keep this obsession about 512 characters, and many people called me out on this one. There are actually many arguments: Why 512 in particular? It happens to be the size of a toot on my Mastodon instance so I can fit the code there, and I found it to be a good balance. One with tricky for-loop compounds on Snapdragon/Adreno because I was trying hard to avoid the macros and functions. One with chained assignments on Imagination/PowerVR (typically affect Google Pixel Pro 10). A tiny demo has to focus on one or two very scoped aspects of computer graphics, which makes it perfect as a learning support . It's part of the artistic performance : it's not just techniques and visuals, the wizardry of the code is part of why it's so impressive. We're in an era of visuals, people have been fed with the craziest VFX ever. But have they seen them with a few hundreds bytes of code? The constraint helps me finish the work : when making art, there is always this question of when to stop. Here there is an intractable point where I just cannot do more and I have to move on. Similarly, it prevents my ambition from tricking me into some colossal project I will never finish or even start. That format has a ton of limitations, and that's its strength. Working on such a tiny piece of code for days/weeks just brings me joy . I do feel like a craftsperson, spending an unreasonable amount of time perfecting it, for the beauty of it. I'm trying to build a portfolio, and it's important for me to keep it consistent . If the size limit was different, I would have done things differently, so I can't change it now. If I had hundreds more characters, Red Alp might have had birds, the sky opening to lit a beam of light on the mountains, etc.
CSS
Frontend
Tutorial
Programming
C#
Shell
Web Development
Linux
Hardware
Database
JSON
Open Source
Security
Dart
Culture
AI
Kotlin
Java
TypeScript