junebug.net

Generative Ink

2026-04-30T00:00:00Z

Generative art is just writing down a mathematical function $f : R^{2} \to R^{3}$ that takes coordinates and returns a colour. The following is one such function:

This is a write-up of a skeuomorphic ink-on-paper generative art sketch I wrote. It is very much the spiritual descendant of dipolar, but faster and with a more realistic ink texture. It isn’t intended to be an introduction to generative art or WebGL, and assumes familiarity with both.

The rendering pipeline is roughly:

Paths are defined in javascript and triangulated.
The paper heightmap and gradients are calculated and cached to a texture.
A vertex shader calculates the coordinates for the vertices of this triangulated path, as well as varyings for a few quantities used in ink effects.
A fragment shader estimates the distance of each point in screenspace from the path.
The ink colour is computed as an additional pass on top of this per pigment.
The entire canvas is given a rough paper texture.

Lines

To start, let’s draw some lines on the canvas — the paths are defined in javascript, adding some noise/jitter to help make it look more organic.

To render these to the canvas I used Matt Deslauriers’s blog post Drawing Lines is Hard as a reference which covers the topic of rendering paths in WebGL in much more detail. In summary: the path is triangulated such that each line segment is 2 triangles. These triangles are rendered as a solid colour on top of the canvas.

Paper

To give the image some roughness I add some noise to the canvas. This is the same effect I used in a few of my older pieces, e.g. dipolar and abstraction.

The baseline noise texture is standard Perlin noise $p : R^{2} \to R$ . This is layered together at a few frequencies to give fractal Perlin noise

p_{fract} (\vec{x}) : - \sum_{n = 0}^{N} a^{n} p_{perlin} (f^{n} \vec{x})

for some choice of parameters $a$ , $f$ , $N$ .

The heightmap is a sum of a larger low-frequency noise contribution, flattened with $\tanh$ to give the big soft grains, and a small high-frequency contribution which gives an additional rough texture. I think it’s quite effective. The first WebGL program here calculates and returns $(h (\vec{x}), \frac{\partial h}{\partial x} (\vec{x}), \frac{\partial h}{\partial y} (\vec{x}))$ on the red, green and blue channels. These are used to seed randomness/noise in other parts of the pipeline, and since this work only has to be done once it’s good to cache it into a texture.

A second program takes a baseline colour $\vec{v}$ (which may vary across the page) and generates the visible paper texture as $\vec{v} + (\vec{l} \cdot \vec{\nabla} h) \vec{1}$ , which is an approximation of what a textured surface would look like lit by soft white directional lighting. Play with it below, use your mouse to change the value of $\vec{l}$ (the lighting direction).

Inky effects

A few simple effects are added to the vertex shader which triangulates the path, these modify the width and opacity of the path.

For the following I parameterise the path as $\vec{X} (l)$ where $l \in R^{+}$ is the “distance from the end of the path”.

Drip is intended to capture extra thickness caused by a droplet of ink being deposited by the nib as it is lifted. The two parameters are $(D_{w}, D_{l})$ and the width of the line at $l$ is increased by $D_{w} {clamp}_{[0, 1]} (1 - \frac{l}{D_{l}})$ . With a well chosen (small) value of $D_{w}$ this gives some nice directionality when there are many short strokes.

Weight is intended to simulate the effect on a line of the weight of the hand and thickest part of the pen being aligned with a downstroke. This has four parameters: $(θ_{W}, W_{o p}, W_{width}^{1}, W_{width}^{2})$ .

$θ_{W}$ defines the angle of the downstroke and $w (l) \in [- 1, 1]$ is the dot product of the path direction with this downstroke direction. The width of the line at $l$ is increased by $W_{width}^{1} w (l) + W_{width}^{2} w (l)^{2}$ , and the opacity of the ink by $W_{o p} w (l)$ . The idea here is that the directional $W_{w i d t h}^{1}$ component captures something like a flexing nib, and the bidirectional $W_{width}^{2}$ captures something like an italic nib.

Shading captures the higher density of ink at the end of a path, caused by ink being dragged by a nib across the page. This has three parameters $(S_{op}, S_{start}, S_{width})$ and increases the ink opacity by $S_{op} \cdot {clamp}_{[0, 1]} (1 - \frac{l - S_{start}}{S_{width}})$ .

Ink bleed and pigments

Drawing the ink ended up quite a bit more complicated. I wanted an ink-drawing routine which gave nice feathered ink bleed edges, and I wanted this to behave well at corners and intersections. The approach I decided to go with was to use Signed Distance Functions, computed in a fragment shader. A trick here is that you can map a colour to $f (sdf (\vec{x}))$ for some monotonically decreasing $f : R \to [0, 255]$ , change the blending function to gl.MAX, and compose the sdfs from different triangles/paths together:

gl.enable(gl.BLEND);
gl.blendEquation(gl.MAX);
gl.blendFunc(gl.ONE, gl.ONE)

This works because in effect this is taking the minimum of two SDFs, which gives you (outside the shapes/sets) an SDF for the shape formed from the union of the two shapes/sets. (Strictly, inside the set you no longer have an SDF, but a function which returns a lower bound on the distance from the boundary).

In the final pass, we compose a translucent colour per pigment. A pigment is an rgba tuple and a bleed value which controls how soft the edge of the path is. Layering multiple pigments per line is expensive, but gives a nice subtle effect at the edge of the path where different pigments bleed further into the paper.

The main body of the fragment shader for this one is quite concise so I’ll show it here:

float cutoff(float v) {
    return 0.5 - 0.5 * tanh(v);
}

void main() {
    float sdfNoisy = sdf() - u_penNoiseScale * height();
    float alpha = cutoff(sdfNoisy / u_bleed) * (1.0 + density());
    outColor = vec4(u_pigment.rgb, u_pigment.a * alpha);
}

This has a single extra parameter, the “pen noise scale” $β$ which adds some noise to the path edge. Here, density() brings in the sum of the effects described in the previous section. This is seeded from the paper noise texture, both so the paper and ink look more like they are interacting, and to save some effort in recalculating the Perlin noise.

Conclusions

On a modern laptop it’s pretty fast — the bottleneck seems to be the js -> flat-format array conversions. For a simple sketch with a few lines it’s fast enough to be calculated in realtime. Try drawing on the sketch below:

I’m quite proud of it! I know not everyone is a fan of skeuomorphism, but I hope you agree that it achieves what I wanted it to effectively. I find it quite useful when I’m imagining a plotter as the canonical output target. It’s fast enough to do interactive or animated pieces. There are still some issues — it currently behaves badly at sufficiently sharp corners. I think it could be made even quicker, so it could support realtime on much more complicated sketches.

The javascript for the demos here lives next to this post at ./demo.js and pulls in ./lines.ts (transpiled to ./lines.js) from the same folder. Take a look.

Meta note: I wasn’t sure how to pitch this between demos, maths, or code. What an appropriate amount of detail is etc. I’d welcome feedback.

Should two-boxers say so?

2026-03-22T00:00:00Z

This is a meta-discussion of Newcomb’s problem. If you’ve never come across the problem I’d recommend you think about it for at least a few minutes before reading on. The original formulation is as follows:

An alien named Omega has come to Earth, and has offered some people the following dilemma.

Before you are two boxes, Box A and Box B.

You may choose to take both boxes (“two-box”), or take only Box B (“one-box”).

Box A is transparent and contains $1,000.

Box B is opaque and contains either $1,000,000 or $0.

The alien Omega has already set up the situation and departed, but previously put $1,000,000 into Box B if and only if Omega predicted that you would one-box (take only the opaque Box B and leave Box A and its $1,000 behind). Omega is a perfect predictor of human behaviour.

This is an interesting problem because it’s a scissor, it divides people on what the correct answer is. The two camps are sometimes called one-boxers, who take the opaque box B and leave box A, and two-boxers who take both box A and box B. A two-boxer might argue that taking the $1,000 couldn’t possibly impact what’s in box B (causality flows ever-forward), so regardless of what’s in B, taking A gets you an extra $1,000. Two-boxing dominates one-boxing. A one-boxer would say that two-boxing as a strategy reliably loses you the $1,000,000, so it is worse / less rational than one-boxing.

This post isn’t actually about the paradox itself so I won’t give my own answer to what I would do. Instead, this post addresses the question should a two-boxer honestly report that they are a two-boxer. I came across this question recently in a tweet from Rob Miles:

Rob Miles @robertskmiles

Amazing how many people not only two box, but post on the public internet under their real name that they'd two-box. You're predictably fumbling a million bucks, son

10 March 2026

This is the second time I have seen a similar idea from someone I respect, and I totally disagree, which motivates this response. Miles elaborates:

Rob Miles @robertskmiles

I don't go in for galaxy brain shit, I one box for the normal/obvious reasons. But like, if you're a two-boxer, your whole strategy depends on beating the predictor, doesn't it? So two boxing in secret is at least coherent, but two boxing in public never makes sense to me?

10 March 2026

As I understand it, the argument is as follows

You should try to get the money.
In Newcomb's paradox with a fallible predictor, predictably two-boxing means you won't get the money.
Tweeting that you'd two-box would make you predictably two-box.

∴ You should not tweet that you'd two-box.

But this is wrong! What actually follows from this is “In Newcomb’s paradox with a fallible predictor, you should not tweet that you’d two-box.” The distinction is important. You can’t pull a conclusion out of a hypothetical and apply it to life without making additional claims about the world.

An example which illustrates this is Pascal’s wager. Pascal’s wager doesn’t work because you can come up with a hypothetical of an “anti-God”, who will give you equal and opposite punishments and rewards to the God in Pascal’s hypothetical. What actions you should take require you to consider which of the states of the world (which hypotheticals) is more probable, using whatever epistemic tools you find appropriate.

I can come up with an analogous hypothetical for Newcomb’s: “If Omega predicts you would one-box then <punishment>, if Omega predicts you would two-box then <reward>.” Under this thought experiment, I think many one-boxers would say the solution is to adopt a strategy of two-boxing. What the optimal solution is in real life depends on which you think is more likely, and more generally, what the expected outcome is of tweeting about one-boxing or two-boxing.

Someone could make the argument that honestly reporting yourself as a two-boxer has a negative expected value, perhaps by arguing that proxy problems appear in real life (in trust, reputation, cooperation, or hiring for example). Newcomb’s problem specifically seems like a low-signal way of getting at these proxies. It doesn’t involve moral counterparties (like the prisoner’s dilemma), and has a causal structure which does not appear in the proxy problems (unlike Kavka’s puzzle). This is an empirical claim, and I don’t want to focus on it; my contention is with the argument as I understand it above. I’d be interested to see the empirical case made rigorously — in Reasons and Persons Parfit makes a structurally similar argument that if you hold a certain theory of self-interest S, the theory itself gives you reasons to abandon S. I think it’s quite elegant.

To me it’s clear that a two-boxer could rationally discuss that they are a two-boxer. It would require them to believe that the probability of something like Newcomb’s paradox occurring is sufficiently small that it’s more valuable to them to openly discuss philosophy. In the same way, a one-boxer could believe that the probability of something like my “anti-Newcomb” hypothetical is sufficiently small that it’s more valuable to them to openly discuss philosophy. A disagreement with either of these positions is a disagreement about the world, not a disagreement about rationality. Personally I’m quite happy that we’re all openly discussing philosophy.

Followup (2026-03-24)

Miles clarified his argument as:

Rob Miles @robertskmiles

The world contains many situations where reasonably capable systems try to predict you, and offer you something good as long as they predict you won't defect for marginal gains.
“I’ll pay you well to look after my business concern, as long as I predict you’re the kind of person who wouldn’t embezzle even if you knew you could get away with it”, etc

If you’re like “Hey, once I’ve got the job, I know I can get away with pocketing the extra $100, and that can’t affect my employer’s decision to hire me, since it’s in the past, so I’d do it”, that makes you an untrustworthy person who is unlikely to get hired

24 March 2026

Which is not far off what I guessed at as the empirical claim being made, and helps me understand his position much better.

My feeling is that here Newcomb’s is a worse proxy for these problems than Parfit’s Hitchhiker, in which ‘failing’ is more clearly defection, and the event ordering better aligns with some intuitions around commitments.

Thanks to him for responding.

Counting spins on an ESP32

2026-01-27T00:00:00Z

I’ve had some time during my no-compete period between jobs; one distraction has been this little project, which aims to count how many times I spin around. The inspiration for this is twofold:

xkcd 2882

"Net Rotations" by xkcd, CC BY-NC 2.5

Over Christmas my family like to play a game where we make a bet on the behaviour of one of the dogs (how long will they sleep?, how long can we get them to stay?, etc). One that was floated was how many times will Bella spin around?. Bella you see, is a very excitable dog, something she communicates with pacing, barking, and spinning. This idea was discarded because keeping track would be onerous, but for next year it struck me that a technological solution was available.

I bought an M5StickC Plus2 (photo below), which is a small self-contained device containing an ESP32, 6-axis IMU, LiPo, and screen. It’s small and light enough to attach to a dog collar without bothering the dog. Because of the constraints of dog-mounted devices, it was important that the device work regardless of its mounting orientation. My rough implementation plan for this was:

Use the gyroscope to keep track of the device’s orientation $R \in SO (3)$ .
The accelerometer measures the “up” direction and uses this as an anchor to correct drift in orientation.
The rotation rate measured by the gyroscope is transformed into the lab frame, and if the rotation is in the $x y$ plane, added to an accumulated rotation angle.
If the accumulated angle goes past a full turn in either direction, add a turn to the counter.

For numerical convenience, I tracked orientation as a Rotor, which actually lives in $Spin (3)$ , a double cover of $SO (3)$ . This approach is equivalent to using quaternions (popular in game engines) and is discussed in this great blog post.

An aside on topology: point 3 is somewhat more complex than I’ve stated. Imagine the device on a turntable; if the turntable is flat, rotating in the $x y$ plane, it’s obvious when it has done a full turn left or right. If it’s on its side and rotating in the $x z$ plane, it’s obvious that it is not spinning either left or right. What about if it’s on an angle? I think there are lots of defensible choices here, but more interesting is why it’s a hard problem at all.

In 2D, the orientation of an object is a point in $SO (2)$ . If we look at different trajectories in this space which take us from some orientation back to itself, we can group these into equivalence classes under smooth deformation (homotopy), these classes are identified by an integer winding number $π_{1} (SO (2)) = Z$ . A consequence of this is that, in 2D, it is very easy to determine if an object has done a full spin left or right. In 3D the classes are just trivial and sign, $π_{1} (SO (3)) = Z_{2}$ , and a full rotation in any direction just moves you from one to the other (see the plate trick). In 3D you can smoothly deform a left turn into a right turn, in 2D you cannot. This has a lot of interesting implications for physics and also makes this toy project slightly harder. Another consequence is that the xkcd is wrong, and you only need to make sure you do an even number of rotations each day.

Results of the counter after 2 hours of Ceroc.

In my own code, I just counted the rotation if it was within 45 deg of the $x y$ plane. The rest of the implementation is pretty straightforward: I’m relatively generous in counting spins, especially if alternating directions, and there are some other corrections for drift in there. The code is here, Claude Code wrote a lot of the rotor implementation, although got some of it wrong. If you press the big button on the front of the device it will show you how many turns it’s counted in each direction, the total amount of twist/worldline torsion, and a little axis gizmo of its current orientation. The battery life is just over six hours, I think this could be stretched with some optimisation but it’s good enough for now.

To test this, I took it with me dancing. During the class and freestyle, I apparently did 352 clockwise and 138 anticlockwise turns, totalling a spin every ~15s. This feels high, but the (short) routine we were practicing did actually have quite a few spins and the ratio is right, so I think it’s probably close to accurate.

I’m not going to get a chance to visit my parents and their dog for quite a while, so dog-based experiments will have to wait.

junebug.net

Generative Ink

§ Lines

§ Paper

§ Inky effects

§ Ink bleed and pigments

§ Conclusions

Should two-boxers say so?

§ Followup (2026-03-24)

Counting spins on an ESP32

Lines

Paper

Inky effects

Ink bleed and pigments

Conclusions

Followup (2026-03-24)