The Art of Tiny GLSL: Mastering Graphics in 512 Characters

In the world of creative coding, constraints often breed innovation. For developer bµg, this has meant channeling artistic ambition into a tiny but powerful format: GLSL graphics demos limited to just 512 characters. Over the past two months, they've crafted a series of mesmerizing visual experiences—Moonlight, Entrance 3, Archipelago, and Cutie—that showcase remarkable technical ingenuity within these extreme boundaries.

"A tiny demo has to focus on one or two very scoped aspects of computer graphics, which makes it perfect as a learning support," bµg explains. This focus has yielded not just beautiful visuals, but elegant solutions to complex rendering problems that push the boundaries of what's possible with minimal code.

Moonlight: The Physics of Volumetric Rendering

The Moonlight demo presents a serene, moonlit landscape rendered in just 460 characters. What makes this implementation particularly interesting is its approach to volumetric rendering.

In previous work like Red Alp, bµg used traditional volumetric raymarching with complex absorption and emission calculations. For Moonlight, they discovered a simpler alternative: using a 1/d contribution method within the raymarching loop, where d represents the density at the current ray position.

"The first time I saw it, I wondered whether it was a creative take, or if it was backed by physical properties," bµg shares. Through mathematical analysis, they discovered that this seemingly simple formula actually has a basis in physics, modeling the integration of photon density along a ray path.

The derivation shows that when discretely sampling along a ray, the integrated photon density between two points can be expressed as Δt/(d_n × d_{n+1}), which simplifies to 1/d_n when the stepping distance equals d_{n+1}.

// Our mysterious contribution to the output
o += 1./d;

This elegant approach avoids the complex calculations typically required for convincing volumetric effects, while still producing physically plausible results. For transparency, bµg further refined the technique using d = A×abs(d)+B, where A controls absorption and B allows penetration into solid objects.

Entrance 3: Navigating Isometric Views and Driver Bugs

The Entrance 3 demo (465 characters) presented different challenges, particularly in achieving an atmospheric isometric view while working within tight character limits. Initial experiments with voxels proved too resource-intensive, leading bµg back to raymarching with an L-∞ norm for distance calculations—appropriate for the cubic geometry.

The lighting system uses actual ray casting: after the initial raymarch to a surface, the ray direction is reoriented toward a light source, and another march determines if the fragment should be illuminated.

Perhaps unexpectedly, this demo revealed critical mobile driver bugs:
- Issues with complex for-loop compounds on Snapdragon/Adreno GPUs
- Problems with chained assignments on Imagination/PowerVR GPUs (found in devices like Google Pixel Pro 10)

These bugs required clever workarounds, including the creation of a macro that not only fixed the issues but actually saved characters in the process.

The mathematical challenge of setting up an isometric camera proved equally fascinating. When standard approaches failed, bµg turned to symbolic computation with Sympy to derive proper transformation matrices:

# Rotation by 45° on the y-axis
m45 = rot.subs({a:rad(-45), ax0:0, ax1:1, ax2:0})

# Apply the 2nd rotation on the x-axis to get the transform matrices
isometric = m45 * rot.subs({a:asin(tan(rad(30))), ax0:1, ax1:0, ax2:0})
dimetric  = m45 * rot.subs({a:rad(30), ax0:1, ax1:0, ax2:0})

The resulting matrices enable precise isometric and dimetric projections, allowing for the distinctive architectural perspective seen in the demo.

Archipelago: Procedural Generation with Domain Warping

Archipelago (472 characters) presents an infinite procedurally generated Japanese landscape, marking a departure from bµg's previous red/orange color schemes. While visually distinct, the technical approach builds upon foundations established in earlier work.

The mountains and islands use familiar noise functions, but the water employs a different technique: a per-octave noise curve defined by w=exp(sin(x)), with a distinctive domain warping that shifts the x coordinate by its derivative: x-=w×cos(x).

"When I say x, I'm really referring to the x-axis position. It is not needed to work with the z-component because each octave of the fbm has a rotation that 'mixes' both axis," bµg explains.

This technique, which bµg discovered in a video by Acerola, creates the characteristic wave patterns seen in the demo. The domain warping combined with octave-level rotations produces complex, organic-looking water surfaces without requiring extensive code.

Cutie: Smooth Merging and Iteration-Based Rendering

The most ambitious of the series, Cutie (616 characters) pushed beyond the 512-character target but introduced several novel techniques. The character design uses smooth min operators to merge spheres into rounded cone shapes, creating limbs that appear as if metaballs.

#define C(A,B,X,Y)k=L-A)-X,e=L-B)-Y,h=max(.8-abs(k-e),z),d=min(d,min(k,e)-h*h/3.2)

This smoothmin operator allows for natural-looking transitions between different sized spheres, forming the basis for the character's anatomy.

The animation employs simple inverse kinematics (IK) with carefully sized leg parts that simplify the mathematical expressions. Perhaps most interestingly, the visual style doesn't use traditional depth mapping but instead leverages the iteration count of the raymarching algorithm itself.

"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," bµg notes. The iteration count is wrapped in an exponential function and directly influences the output color.

The Philosophy of Constraint

The 512-character constraint might seem arbitrary, but bµg has several compelling reasons for maintaining it:

1. Focused Learning: Each demo must concentrate on one or two specific graphics techniques, making them excellent educational resources.

2. Artistic Performance: The wizardry of fitting complex graphics into minimal code is part of the artistic appeal.

3. Project Completion: The constraint provides a natural stopping point, preventing endless refinement cycles.

4. Portfolio Consistency: The format creates a cohesive body of work that defines a specific artistic and technical approach.

5. Creative Joy: "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."

The choice of 512 characters specifically comes from bµg's Mastodon instance, where it matches the maximum toot length. "I found it to be a good balance," they explain.

The Future of Tiny Graphics

As graphics hardware becomes increasingly powerful, the art of creating complex visual experiences with minimal code represents an important counterpoint to the trend toward larger, more resource-intensive applications. These demos showcase not just technical skill but a deep understanding of the mathematical foundations of computer graphics.

"I will continue making more of those, keeping my artistic ambition low because of the 512 characters constraint I'm imposing on myself," bµg concludes. This dedication to constraint-driven innovation promises more elegant solutions to complex graphics problems, all while fitting within the humble boundaries of 512 characters.