DEV Community: 3D Roll

Building physics-based 3D dice in the browser (three.js + cannon-es, PWA, 11 languages)

3D Roll — Fri, 16 Oct 2026 17:23:06 +0000

I built 3DRoll, a free dice roller where the dice actually tumble. Here's how it works.

Why physics instead of Math.random()

The easy way is to choose the result first and animate the die to it. I went the other way: I throw rigid bodies with a random impulse and spin, let cannon-es simulate the roll, and read the result from whichever face ends up on top once the dice settle.

Making it feel good on phones

Sleep thresholds tuned so dice stop quickly instead of jittering
"Hold to charge" and shake-to-roll using DeviceMotion (iOS asks for permission)

Themed dice

A die is just a list of faces, so "What to eat", "Date night", "Chores" and "Truth or dare" use the same engine with text or emoji textures drawn onto a canvas. You can also make custom dice the same way.

PWA + i18n

The site is static, with a manifest and a service worker, so it can be installed and still works after the first load. There are 11 languages, each with its own prerendered URLs and hreflang tags, and a sitemap that is pinged through IndexNow.

Sharing results

After a roll, the share button adds the result to the text and can generate an image.

Try it: https://3droll.com/?utm_campaign=3day1016&utm_source=devto&utm_medium=article . I'd love feedback on how the physics feels. I'm the author of this project.

I chi-square tested my physics dice, found a bias with five dice, and fixed it (three.js + cannon-es)

3D Roll — Thu, 15 Oct 2026 13:27:21 +0000

3DRoll is a free browser dice roller. It doesn't pick a random number and then play an animation to match. The animation is the random number. Each die is a rigid body in cannon-es that gets a random launch impulse and spin. The simulation runs until every body sleeps, and the result is whichever face points up. three.js only draws what the physics already decided.

That design has one obvious weakness. With Math.random() * 6 you know the distribution is uniform. With a physics engine you only hope it is. So I tested it, and the test found a real bias.

How a roll is read

Each d6 has six local face normals: ±X, ±Y and ±Z. Once the dice stop, I rotate each normal by the body's quaternion and take the one most aligned with world up:

const FACE_NORMALS = [
  new THREE.Vector3(0, 1, 0),  new THREE.Vector3(0, 0, 1),
  new THREE.Vector3(1, 0, 0),  new THREE.Vector3(-1, 0, 0),
  new THREE.Vector3(0, 0, -1), new THREE.Vector3(0, -1, 0),
];

function topFace(body) {
  const q = new THREE.Quaternion(body.quaternion.x, body.quaternion.y,
                                 body.quaternion.z, body.quaternion.w);
  let best = 0, bestDot = -2;
  FACE_NORMALS.forEach((n, i) => {
    const d = n.clone().applyQuaternion(q).y;
    if (d > bestDot) { bestDot = d; best = i; }
  });
  return { index: best, dot: bestDot };
}

Note which values sit on the X axis. In this face order, faces 3 and 4 are the ±X faces. That matters later.

The tilted-die problem

Real dice sometimes come to rest leaning on a wall or on another die. A browser roller can't tell the user "cocked die, roll again", so the app needs a rule. If the top face's dot is below 0.988, the die isn't flat enough to count, and the app corrects it:

If the die is nearly flat and nothing is nearby, rotate it the rest of the way (a short "flatten" animation).
Otherwise, kick it. A "tip" gives it a small hop and a spin around the axis that would tip it over. After a few tries, a more random "nudge" takes over.

The kick seemed harmless at first. It turned out to be the source of the bias.

The test setup

I didn't want to click "roll" 60,000 times, so I rebuilt the app's physics in Node and ran it headless. I used the same cannon-es world and copied every parameter from the production bundle:

gravity −30, SAP broadphase, 16 solver iterations, contact stiffness 1e7
die/floor friction 0.42 and restitution 0.32; die/wall 0.05 / 0.40; die/die 0.20 / 0.38
mass 1, linear damping 0.08, angular damping 0.12, sleep limits 0.07 / 0.6 s
1/120 s physics steps at 60 fps
the same launch code (random target point, random upward speed, random spin), the same settle check, and the same flatten/tip/nudge corrections
dice stay where they landed between throws, like a real session

One thing is only approximate. In the app the tray comes from the camera frustum, so it depends on screen size. The script uses a fixed desktop-sized trapezoid instead.

The statistic is Pearson's chi-square against a uniform distribution, with 5 degrees of freedom. As a reference, χ² above 11.07 means p < 0.05, and above 20.52 means p < 0.001.

What I found (v12)

One die at a time looked fine. Over 42,000 throws every face landed between 16.3 % and 17.0 % of the time (ideal: 16.67 %). A 30,000-throw run gave χ² 4.20 (p 0.52). A separate 12,000-throw run gave χ² 12.30 (p 0.031), which is borderline at most.

Five dice per throw was different. Two independent runs of 6,000 throws each (30,000 results per run) both failed:

Run	Faces 1–6	χ²	p
1	5008 / 5045 / 4790 / 4895 / 5196 / 5066	20.00	0.0013
2	4915 / 5177 / 4715 / 4950 / 5187 / 5056	32.08	< 0.0001
pooled	9923 / 10222 / 9505 / 9845 / 10383 / 10122	48.58	≈ 3×10⁻⁹

Face 3 came up 15.84 % of the time and face 4 16.41 %. Those are the ±X faces, and the same pattern showed up in both runs. One caveat: five dice in one throw collide, so their results aren't fully independent, which makes χ² somewhat overconfident. But two separate runs with p values that small and the same faces low point to something real.

In practice it's a fraction of a percentage point, and no one would notice it at a game table. But a dice roller that claims real physics shouldn't favour faces.

Finding the suspect

The correction counters gave it away. In the five-dice runs, tilted dice were very common, since dice lean on each other. Each 6,000-throw run needed roughly 1,600–1,700 tips. The tip spins the die around an axis computed from its current orientation, so the correction isn't neutral with respect to the die's own axes. Fire it that often and it starts to shape the result.

The fix (v13)

The new version changes three things.

1. A plain box collider. The d6 collision shape was a rounded box (a convex hull with a 0.045 bevel). It's now a plain CANNON.Box with half-extent size/2. The rounded look stays in the rendered mesh.

2. Slide, don't kick. A tilted die now gets a settleSmooth step before any kick. The app finds the nearest flat orientation and a free spot next to the die, then slides it there over 0.3 s:

settleSmooth(die) {
  const body = die.body;
  const from = body.position.clone();
  const q0 = body.quaternion.clone();
  // rotate the current "most-up" face to exactly +Y
  const q1 = new THREE.Quaternion()
    .setFromUnitVectors(die.topFace().up, UP).multiply(q0);
  const restY = this.restHeight(die, q1);
  // try the current spot, then rings of 0.35–1.25 × size around it,
  // biased away from the nearest neighbour; must be clear of other dice
  for (const [r, angle] of this.candidateSpots(die)) {
    const x = from.x + Math.cos(angle) * r;
    const z = from.z + Math.sin(angle) * r;
    if (this.spotIsFree(die, x, z)) {
      die.slide = { p0: from, p1: new THREE.Vector3(x, restY, z), q0, q1, t: 0 };
      return true;
    }
  }
  return false; // no room: fall back to tip / nudge
}

Each frame the slide eases position (lerp) and rotation (slerp) together, with velocities zeroed. This runs on the first three correction passes. Only if there's no free spot does the old tip (now up to pass five) or nudge run.

3. Ordering and waiting. Tilted dice are corrected highest first, so a die resting on top of another moves before the one under it. The result isn't read until every slide and flatten has finished.

Launch spin, materials, damping and face reading are all unchanged.

After the fix

Same script, updated to v13's settings:

Test	v12 χ² (p)	v13 χ² (p)
1 die, 30,000 throws	4.20 (0.52)	0.74 (0.98)
5 dice, run 1 (6,000 throws)	20.00 (0.0013)	1.54 (0.91)
5 dice, run 2 (6,000 throws)	32.08 (< 0.0001)	5.98 (0.31)
5 dice pooled (60,000 results)	48.58 (≈ 3×10⁻⁹)	2.71 (0.75)

The raw v13 counts:

1 die, 30,000 throws: 5040 / 4996 / 4975 / 5022 / 4998 / 4969
5 dice pooled, 60,000 results: 10018 / 10027 / 10049 / 9951 / 10078 / 9877, every face between 16.46 % and 16.80 %

The corrections changed just as much. Each five-dice run now needs about 885 slides and only 11–14 tips, instead of about 1,650 tips. The single-die run needed 642 slides and no tips or nudges at all.

No detectable bias in any v13 run.

What I'm not claiming

Not "proven fair". A test that doesn't reject uniformity hasn't proven uniformity. It means no bias showed up at this sample size.
It's a simulation. The tray is approximate, so these numbers describe the headless setup. Your screen's tray shape is slightly different.
The cause is inferred. I changed three things at once. The kick-axis explanation fits the numbers (the bias vanished when tips nearly vanished), but I didn't test each change on its own.
Only the d6 is covered. The d4, d8, d10, d12 and d20 are next.

Takeaways for anyone building physics dice

Test what you ship, headless. Copy the real parameters and the real correction logic. Most of the bias came from the "fix-up" code, not the physics engine.
Test multiple dice, not just one. The single-die runs were basically clean. The bias only appeared when dice interacted.
Count your corrections. Logging flattens, tips and nudges was what pointed at the cause.
Run more than once. One borderline p value means little. The same faces low in two independent runs means a lot.
Be careful with "fair". "No detectable bias in N throws" is a claim you can back up.

You can roll the fixed dice at 3droll.com. It's free, works in the browser, and needs no sign-up. If you have ideas for testing the d10 or d20 fairly, or a better approach than a simulated tray, I'd love to hear them in the comments.

I stopped arguing about chores and date night: building decision dice with real 3D physics

3D Roll — Wed, 14 Oct 2026 17:59:33 +0000

Every household has the same three arguments on repeat: who does the dishes, where do we eat, and what do we do Friday night. None of them is hard. All of them are tiring. That's decision fatigue: the energy isn't spent on the choice, it's spent on negotiating it.

The idea

Instead of debating, roll a die. If the die is physical and a bit theatrical, nobody feels outvoted: the dice did it. It works for:

Roommates: dishes, bins, bathroom, "whose turn is it to call the landlord".
Couples: date night, movie pick, who plans the next trip.
Anyone: the "I don't care, you pick" loop.

Rolling is quick and oddly fun, and the result feels fair because everyone watched it happen.

The light technical bit

I built 3droll on top of a real 3D physics engine, so the die tumbles, bounces off walls and settles on a face, rather than picking a random number and animating toward it.

Custom labels

Each face is just a texture. Draw the label on a canvas and use it as the material for that face:

function faceTexture(label) {
  const c = document.createElement('canvas');
  c.width = c.height = 256;
  const ctx = c.getContext('2d');
  ctx.fillStyle = '#fff';
  ctx.fillRect(0, 0, 256, 256);
  ctx.fillStyle = '#111';
  ctx.font = 'bold 40px sans-serif';
  ctx.textAlign = 'center';
  ctx.fillText(label, 128, 140);
  return new THREE.CanvasTexture(c);
}
const labels = ['Dishes', 'Bins', 'Cook', 'Vacuum', 'Laundry', 'Day off!'];
const materials = labels.map(l => new THREE.MeshStandardMaterial({ map: faceTexture(l) }));

Weighted faces

Want "Day off!" to come up less often, or the pizza option more? With real physics you can't just tweak a probability, so you shift the center of mass. A die lands on the face opposite its heavy side more often:

// Move the center of mass toward the face you want to land DOWN.
// That makes the opposite face more likely to end up on top.
// Offsetting the shape biases the die toward landing on the opposite face.
body.addShape(shape, new CANNON.Vec3(0, -0.05, 0));

Small offsets give a gentle bias, larger ones a loaded die. Fun for "the person who forgot last week gets worse odds" house rules.

Wrap-up

Fewer arguments, more rolling. Try it for a week with your roommates or partner and see how many decisions you can hand over to a die.

https://3droll.com/

Farkle / Zehntausend scoring as a pure function: a small JavaScript kata

3D Roll — Wed, 14 Oct 2026 17:12:13 +0000

Farkle (known in Germany as Zehntausend, "ten thousand") is a push-your-luck dice game. It is also a great little kata: the scoring rules are small enough to fit in your head, yet full of edge cases. In this post we will write the scorer as a pure function, then use it to compute the famous bust probabilities.

The rules in 60 seconds

You roll six dice. You must set aside at least one scoring die (or combination).
You may then stop and bank your turn total, or re-roll the remaining dice.
If a roll contains no scoring dice, you bust (Farkle) and lose everything from this turn.
If all six dice score ("hot dice"), you may pick up all six and keep going.
The first player to reach 10,000 points wins.

Common scoring (house rules vary, which is exactly why a pure function is handy):

Combination	Points
Single 1	100
Single 5	50
Three 1s	1000
Three of X (2-6)	X × 100
Four / five / six of a kind	2× / 4× / 8× the triple value
Straight 1-2-3-4-5-6	1500
Three pairs	750

The scoring function

The function takes an array of die faces and returns the best score that uses all given dice, or 0 if some die doesn't score. No I/O, no randomness, no mutation.

const counts = (dice) => {
  const c = [0, 0, 0, 0, 0, 0, 0];
  for (const d of dice) c[d]++;
  return c;
};

const tripleValue = (face) => (face === 1 ? 1000 : face * 100);

export function score(dice) {
  const c = counts(dice);
  const n = dice.length;
  if (n === 6 && c.slice(1).every((x) => x === 1)) return 1500; // straight
  if (n === 6 && c.filter((x) => x === 2).length === 3) return 750; // three pairs
  let total = 0;
  for (let f = 1; f <= 6; f++) {
    let k = c[f];
    if (k >= 3) {
      total += tripleValue(f) * 2 ** (k - 3);
      k = 0;
    }
    if (k > 0) {
      if (f === 1) total += 100 * k;
      else if (f === 5) total += 50 * k;
      else return 0; // a non-scoring die was included
    }
  }
  return total;
}

// Does a roll contain *anything* that scores?
export const hasScore = (roll) => {
  const c = counts(roll);
  return c[1] > 0 || c[5] > 0 || c.some((x) => x >= 3) ||
    score(roll) > 0; // catches three pairs
};

Some tests that pin down the behaviour:

console.assert(score([1]) === 100);
console.assert(score([5, 5]) === 100);
console.assert(score([2, 2, 2]) === 200);
console.assert(score([1, 1, 1, 1]) === 2000);
console.assert(score([1, 2, 3, 4, 5, 6]) === 1500);
console.assert(score([2, 2, 3, 3, 4, 4]) === 750);
console.assert(score([2, 3]) === 0);

Bust probability with 1-6 dice

Because hasScore is pure, we can brute-force every outcome of n dice (6^n, at most 46,656) and count the busts:

function bustChance(n) {
  let busts = 0, total = 6 ** n;
  for (let i = 0; i < total; i++) {
    const roll = [];
    for (let j = 0, x = i; j < n; j++, x = Math.floor(x / 6)) roll.push((x % 6) + 1);
    if (!hasScore(roll)) busts++;
  }
  return busts / total;
}

Dice left	Bust chance
1	2/3 ≈ 66.7%
2	4/9 ≈ 44.4%
3	5/18 ≈ 27.8%
4	≈ 15.7%
5	≈ 7.7%
6	≈ 2.3%

Sanity check for small n: with one die only a 1 or 5 scores, so the bust chance is 4/6 = 2/3. With two dice both must avoid 1 and 5: (4/6)² = 4/9. With three dice, (4/6)³ = 8/27, minus the triples of 2, 3, 4, 6 (4/216), giving 60/216 = 5/18.

The table explains the strategy most players learn the hard way: re-rolling one or two dice is risky, while re-rolling five or six is almost free.

Kata extensions

Make the scoring table a parameter so house rules become data.
Write bestSelection(roll) that returns the highest-scoring subset.
Compute the expected value of continuing vs. banking at a given turn total.

If you want to try the game with real-feeling virtual dice, roll them here: https://3droll.com/farkle-dice/

How Japanese Chinchiro and Chinese Bo Bing dice games are scored (and simulating them with 3D physics in the browser)

3D Roll — Wed, 14 Oct 2026 16:35:07 +0000

Two of the most fun "roll and shout" dice games in East Asia are Chinchiro (チンチロ / チンチロリン) from Japan and Bo Bing (博饼, "cake gambling") from Xiamen, China, traditionally played around the Mid-Autumn Festival. Both are simple to play, but their scoring tables hide some interesting probability. In this post I'll go through the rules, the combination tables, the exact probabilities (computed by enumerating every outcome), and finally how to make the dice actually tumble in the browser with a physics engine.

Part 1: Chinchiro (3 dice)

Rules

Players roll three dice into a bowl (traditionally a rice bowl).
Each player gets up to three tries to make a scoring combination. The first scoring roll stands.
A die that jumps out of the bowl is usually an immediate loss (shonben).
In the classic banker game, each player's hand is compared to the banker's, and some hands pay multiples of the bet.

Combination table

Hand	Japanese	Dice	Typical payout
Pinzoro	ピンゾロ	1-1-1	wins 5x
Arashi / Zorome	嵐・ゾロ目	triple 2–6	wins 3x
Shigoro	シゴロ	4-5-6	wins 2x
Point (me)	目	a pair + one odd die; the odd die is the point (1–6)	compare points
Menashi	目なし	anything else	no hand (roll again, up to 3 times)
Hifumi	ヒフミ	1-2-3	loses 2x

Payouts vary between house rules; ranks are almost always the same: Pinzoro > other triples > 4-5-6 > point 6 … point 1 > no hand > 1-2-3.

Probabilities

Three dice have 6³ = 216 equally likely outcomes.

Hand	Count	Probability
1-1-1	1	0.46%
Triple 2–6	5	2.31%
4-5-6 (any order)	3! = 6	2.78%
1-2-3 (any order)	6	2.78%
Point (pair + odd die)	6 × 5 × 3 = 90	41.67%
– each specific point 1…6	15	6.94%
No hand	108	50.00%

Exactly half of all single rolls are "no hand". With three tries, the chance of ending with no hand is (1/2)³ = 12.5%, and the chance of eventually making something is 87.5%.

function chinchiro(d) {
  const [a, b, c] = [...d].sort((x, y) => x - y);
  if (a === c) return a === 1 ? 'pinzoro' : 'arashi';
  if (a === 4 && b === 5 && c === 6) return 'shigoro';
  if (a === 1 && b === 2 && c === 3) return 'hifumi';
  if (a === b) return 'point ' + c;
  if (b === c) return 'point ' + a;
  return 'menashi';
}

// Exact enumeration
const tally = {};
for (let x = 1; x <= 6; x++)
  for (let y = 1; y <= 6; y++)
    for (let z = 1; z <= 6; z++) {
      const k = chinchiro([x, y, z]);
      tally[k] = (tally[k] || 0) + 1;
    }
console.log(tally); // menashi: 108, point N: 15 each, ...

Part 2: Bo Bing (6 dice)

Rules

Players take turns throwing six dice into a large porcelain bowl.
Each throw is checked against the prize table; if it matches a tier, the player takes a prize (traditionally mooncakes) from that tier.
Fours are special: the 4 face is red, so the number of fours drives most tiers.
The game ends when all prizes are claimed. The top prize, Zhuangyuan, can be "stolen" by a later, higher Zhuangyuan roll.

Combination table (from highest to lowest)

Tier	Chinese	Condition
Zhuangyuan (top scholar)	状元	4 fours, or 5 of a kind, or 6 of a kind (sub-ranked: 6 fours > 6 of a kind > 4 fours + 2 ones > 5 fours > 5 of a kind > 4 fours)
Duitang (straight)	对堂	1-2-3-4-5-6
Sanhong (three reds)	三红	exactly 3 fours
Sijin (four of a kind)	四进	4 of the same non-4 face
Erju (two reds)	二举	exactly 2 fours (and not Sijin)
Yixiu (one red)	一秀	exactly 1 four (and nothing higher)
—	—	anything else: no prize

Probabilities

Six dice have 6⁶ = 46,656 outcomes. Counting by k, the number of fours:

Zhuangyuan: six 4s (1) + five 4s (6 × 5 = 30) + four 4s (C(6,4) × 5² = 375) + five of a kind of another face (5 × 6 × 5 = 150) + six of a kind of another face (5) = 561
Duitang: 6! = 720
Sanhong: C(6,3) × 5³ = 2,500
Sijin: 5 faces × C(6,4) × 5² = 1,875 (this includes four-of-a-kind with one or two fours alongside, which still ranks as Sijin)
Erju: C(6,2) × 5⁴ = 9,375, minus the 75 where the other four dice are a four of a kind = 9,300
Yixiu: 6 × 5⁵ = 18,750, minus 720 straights, minus 30 five-of-a-kinds, minus 600 four-of-a-kinds = 17,400
Nothing: the rest = 14,300

Tier	Count	Probability	About 1 in
Zhuangyuan	561	1.20%	83
Duitang	720	1.54%	65
Sanhong	2,500	5.36%	18.7
Sijin	1,875	4.02%	24.9
Erju	9,300	19.93%	5.0
Yixiu	17,400	37.29%	2.7
No prize	14,300	30.65%	3.3

Two fun observations:

Sijin is rarer than Sanhong but ranks below it. The table is driven by tradition (the color red and the imperial exam metaphor), not strictly by probability.
Roughly 69% of throws win something, which keeps the game lively for a family table.

A verification script that enumerates all 46,656 outcomes:

function boBing(d) {
  const c = Array(7).fill(0);
  d.forEach(v => c[v]++);
  const max = Math.max(...c.slice(1));
  const fours = c[4];
  if (fours >= 4 || max >= 5) return 'zhuangyuan';
  if (c.slice(1).every(n => n === 1)) return 'duitang';
  if (fours === 3) return 'sanhong';
  if (max === 4) return 'sijin';
  if (fours === 2) return 'erju';
  if (fours === 1) return 'yixiu';
  return 'none';
}

const t = {};
for (let i = 0; i < 6 ** 6; i++) {
  const d = [];
  let n = i;
  for (let j = 0; j < 6; j++) { d.push(n % 6 + 1); n = Math.floor(n / 6); }
  const k = boBing(d);
  t[k] = (t[k] || 0) + 1;
}
console.log(t);
// { zhuangyuan: 561, duitang: 720, sanhong: 2500, sijin: 1875,
//   erju: 9300, yixiu: 17400, none: 14300 }

Part 3: Rolling the dice with 3D physics in the browser

Math.random() gives perfectly fair dice, but it's not much fun to watch. For a "real" feel you can simulate rigid bodies and read the result from the final orientation:

Physics world – use a library like cannon-es or Rapier (WASM). Create a static floor plus walls (or a bowl built from a few static shapes) and one Box body per die.
Throw – give each die a random position above the bowl, a random rotation, a linear velocity toward the center, and a random angular velocity. Step the world at a fixed timestep (e.g. 1/60 s) and copy body transforms to your Three.js meshes each frame.
Settle detection – consider the roll finished when every body's linear and angular speed stays below a small threshold for a few frames (or let the engine put bodies to sleep).
Read the face – rotate each face's local normal (+X, −X, +Y, −Y, +Z, −Z) by the body's quaternion and pick the one whose world-space normal has the largest dot product with the up vector (0, 1, 0). Map that face to its pip value.
Edge cases – if the best dot product is below ~0.9 the die is "cocked" against a wall; nudge it or re-roll. For Chinchiro, a die whose final position is outside the bowl radius is a shonben (instant loss), which a physics sim models for free.

const faces = [
  { n: new CANNON.Vec3(0, 1, 0), v: 1 }, { n: new CANNON.Vec3(0, -1, 0), v: 6 },
  { n: new CANNON.Vec3(1, 0, 0), v: 2 }, { n: new CANNON.Vec3(-1, 0, 0), v: 5 },
  { n: new CANNON.Vec3(0, 0, 1), v: 3 }, { n: new CANNON.Vec3(0, 0, -1), v: 4 },
];
function readDie(body) {
  let best = null, bestDot = -Infinity;
  for (const f of faces) {
    const w = body.quaternion.vmult(f.n);
    if (w.y > bestDot) { bestDot = w.y; best = f.v; }
  }
  return { value: best, cocked: bestDot < 0.9 };
}

Because the initial conditions are random and the dynamics are chaotic, the resulting face distribution is very close to uniform, and you can sanity-check it by running a few thousand headless throws and comparing the counts against the tables above.

Wrap-up

Chinchiro: 216 outcomes, half of single rolls are "no hand", 1-1-1 is 1/216.
Bo Bing: 46,656 outcomes, Zhuangyuan about 1.2%, and about 69% of throws win a prize.
Physics-based dice add drama (and the occasional die flying out of the bowl) without hurting fairness.

If you want to try physics-based dice rolling in your browser, I built a free set of 3D dice tools here: https://3droll.com/