Procedurally generating marble dice textures with simplex noise

I built a 3D dice roller as a Chrome extension and wanted dice that look like the marbled Chessex ones — those rich, swirling, Old-World-stone dice every tabletop player covets. The catch: the renderer (@3d-dice/dice-box) lets the user pick a color per die kind (d4 red, d6 blue, d20 gold, etc.), so the texture can't just be a flat painted bitmap. The marble pattern has to stay, but the color underneath has to follow whatever the user picked.

This post is the recipe for generating those textures from scratch with simplex noise — no Photoshop, no marble photo, just code that produces something like this for every die:

The pipeline is three layers stacked on top of plain noise, plus one trick about the alpha channel that took me a while to spot. Let's walk through it.

Layer 1: Multi-octave simplex noise

Start with the basic noise field. One sample of simplex noise gives you smooth, organic blobs that look more like cloud cover than rock. To get the multi-scale detail real marble has — broad slabs of color and fine hairline streaks — you sum several octaves of noise at doubling frequencies, halving the amplitude each time:

import { createNoise2D } from 'simplex-noise';
const baseNoise = createNoise2D(/* seeded PRNG */);

function sample(x, y) {
  let amp = 1;
  let freqX = BASE_FREQ * 0.7;  // mild horizontal stretch
  let freqY = BASE_FREQ * 1.3;
  let acc = 0;
  let totalAmp = 0;
  for (let o = 0; o < OCTAVES; o++) {
    acc += amp * baseNoise(x * freqX, y * freqY);
    totalAmp += amp;
    amp *= 0.5;
    freqX *= 2;
    freqY *= 2;
  }
  return acc / totalAmp;   // in roughly [-1, 1]
}

The slight asymmetry between freqX and freqY gives the streaks a hint of horizontal flow, like the grain in cut stone. Here's what that looks like as a grayscale field:

It's already organic-looking, but it's also too uniform — straight parallel-ish bands like wood grain, not the curling whorls of marble. Real marble veins bend, swirl, and double back on themselves. That's the next layer.

Layer 2: Domain warping

Domain warping is one of those tricks that feels like cheating because it's so simple and the result is so dramatic. Instead of sampling the noise on a straight (x, y) grid, you offset every (x, y) by another noise field before sampling:

const warpA = createNoise2D(/* different seed */);
const warpB = createNoise2D(/* yet another seed */);

const WARP_FREQ = 0.003;    // broad, slow swirls
const WARP_AMOUNT = 90;     // pixels of displacement at peak

for (let y = 0; y < H; y++) {
  for (let x = 0; x < W; x++) {
    const wx = warpA(x * WARP_FREQ, y * WARP_FREQ) * WARP_AMOUNT;
    const wy = warpB(x * WARP_FREQ, y * WARP_FREQ) * WARP_AMOUNT;
    const v = sample(x + wx, y + wy);
    // ...
  }
}

You're literally bending the input space before reading the noise. Two independent low-frequency noise fields (one per axis) push each pixel up to 90 pixels in some random direction, so the patterns above get twisted into curls. Same noise, same algorithm, different coords:

Now we're getting marble whorls. But the field is still soft — gradual gradients everywhere. Marble has veins: sharp edges where dark meets light. That's the third layer.

Layer 3: Ridged transform

The ridged transform is a one-line operation: 1 - |n|. It folds the noise field around zero and inverts it, so what used to be a smooth roll between -1 and +1 becomes a series of sharp peaks at every zero-crossing of the original noise. Mathematically, the zero-crossings of a smooth random field form a set of curves — and 1 - |n| lights those curves up.

function sample(x, y, ridged) {
  // ... octave summing as before ...
  const n = acc / totalAmp;
  return ridged ? 1 - Math.abs(n) : (n + 1) / 2;
}

Apply that and the soft swirls turn into something with backbone:

That's the geometry of marble veins — long, curving ridges with a clear edge between "vein" and "background". Now we have a usable pattern.

Composition: dual fields + thresholds

The actual marble texture uses two of these fields with different seeds — one for dark veins, one for light highlights — and per pixel picks whichever signal is stronger. Threshold each field at around 0.86 so only the sharpest ridge crests become streaks:

const darkStrength = Math.pow(
  Math.max(0, dn - DARK_THRESHOLD),
  STREAK_CONTRAST,
);
const lightStrength = Math.pow(
  Math.max(0, ln - LIGHT_THRESHOLD),
  STREAK_CONTRAST,
);

const darkAlpha = Math.min(MAX_DARK_ALPHA, darkStrength * DARK_GAIN);
const lightAlpha = Math.min(MAX_LIGHT_ALPHA, lightStrength * LIGHT_GAIN);

if (lightAlpha > darkAlpha) {
  // light streak wins
  r = g = b = 255;
  a = lightAlpha;
} else if (darkAlpha > 0) {
  // dark vein wins
  r = g = b = 0;
  a = darkAlpha;
} else {
  // nothing — see "the trick" below
  a = 0;
}

MAX_DARK_ALPHA is higher than MAX_LIGHT_ALPHA (215 vs 160) so the dark veins read as proper marbling and the light streaks stay subtle highlights — flip those and the dice look chalky.

The trick: alpha as the actual lever

Here's the part that bit me for half an evening. @3d-dice/dice-box's color shader is essentially this line of GLSL:

finalColor = mix(themeColor.rgb, textureColor.rgb, textureColor.a);

If the texture's alpha is 1.0 (opaque), the result is 100% texture, 0% themeColor. Which means: if you generate a normal RGB marble texture — black veins on a white background, fully opaque — the user's color choice (the themeColor) is completely invisible. Every die comes out the same washed-out gray, no matter what color is selected.

The fix isn't in the colors — it's the alpha channel.

Write the marble pattern into alpha, not RGB. Where you want a dark vein, the RGB is black and the alpha is high (the texture covers the themeColor). Where you want a light streak, RGB is white with moderate alpha. Where you want pure themeColor, alpha is zero and RGB doesn't matter. The texture is essentially a black-and-white-and-transparent stencil through which the themeColor shows.

That's why the snippet above sets r = g = b = 0 (or 255) and modulates the alpha. The alpha channel is doing the actual work; the RGB just decides whether visible pixels are "darker than themeColor" or "lighter than themeColor".

One more wrinkle: the original dice texture has numbers on the faces, and those need to stay readable. The fix is a simple override — wherever the source atlas has a high-alpha pixel (a number glyph), force the output to opaque black:

if (numbersAlpha[i] > 200) {
  r = g = b = 0;
  a = numbersAlpha[i];   // preserve anti-aliasing
  continue;
}

Numbers always win.

The result

Stack all of that — two warped, ridged, thresholded noise fields composed into a single texture with the alpha trick — and the renderer produces dice that share a consistent marble pattern but pick up whatever per-die color you've configured:

The whole texture-generation pass runs offline as a build step (one Node script with simplex-noise and sharp), so there's zero runtime cost — the extension just ships the resulting 1024×1024 PNG.

Try it / read the code

If you want to see this running in a real Chrome extension, I published the dice roller it's a part of here:

🎲 Dice Roller on the Chrome Web Store: https://chromewebstore.google.com/detail/dice-roller/oiknfbfchalpjggppamjfchhlplaieol