DEV Community: Furiosa Studio

Rendering historical events on a Three.js globe with React Three Fiber

Furiosa Studio — Tue, 14 Jul 2026 08:00:05 +0000

The hard part isn't the dots

Plotting points on a 3D globe is the easy afternoon. Making them readable — labels you can actually parse, markers that don't z-fight into a shimmering mess, camera moves that frame an event instead of flinging you into space, and all of it holding 60fps on a mid-range phone — is where the real work lives. Here is how that breaks down.

Lat/long to a point on the sphere

The core conversion is spherical-to-cartesian. The two gotchas: latitude runs from the equator but the polar angle runs from the pole, and longitude needs a sign flip to match most equirectangular textures.

function latLngToVec3(lat, lng, radius = 1) {
  const phi = (90 - lat) * (Math.PI / 180);   // polar angle from +Y
  const theta = (lng + 180) * (Math.PI / 180); // azimuth, texture-aligned
  return new THREE.Vector3(
    -radius * Math.sin(phi) * Math.cos(theta),
    radius * Math.cos(phi),
    radius * Math.sin(phi) * Math.sin(theta)
  );
}

If your markers land in the ocean off the coast of where they should be, you have a sign or offset wrong here — not in your data.

React Three Fiber, not raw Three.js

R3F lets the scene be a function of state. When the selected event or the timeline year changes, the globe re-renders declaratively instead of you hand-mutating a scene graph inside a useEffect. You keep React's data flow and lose the imperative bookkeeping.

<Canvas camera={{ position: [0, 0, 2.6], fov: 45 }}>
  <ambientLight intensity={0.6} />
  <directionalLight position={[5, 3, 5]} />
  <mesh>
    <sphereGeometry args={[1, 64, 64]} />
    <meshStandardMaterial map={earthTexture} />
  </mesh>
  <Events data={events} />
</Canvas>

drei gives you OrbitControls, Html, and Billboard so you are not reinventing camera math.

Keeping labels legible as the globe turns

Two problems compound as the sphere rotates: labels rotate with their anchor and become unreadable, and markers on the far side bleed through. Billboarding fixes the first — the label always faces the camera. For the second, hide anything whose normal points away from the viewer:

useFrame(({ camera }) => {
  const toCam = camera.position.clone().sub(worldPos).normalize();
  const facing = toCam.dot(worldNormal) > 0;
  label.visible = facing;
});

Cap visible labels to what fits. We show labels only for events near the camera's focus and within the current timeline window; the rest stay as bare markers until selected. A globe with 200 simultaneous labels is noise, not information — and with this data, noise is the wrong register entirely.

Wiring markers to the timeline scrubber

Selecting an event (from a marker click or the scrubber) should animate the camera to frame it, not teleport. Compute a target position along the vector from the globe center through the event, then ease toward it each frame:

useFrame(() => {
  if (!target) return;
  camera.position.lerp(target, 0.08);
  controls.target.lerp(eventPos, 0.08);
  controls.update();
});

A lerp factor around 0.06–0.1 reads as deliberate. Drive target from the same state the scrubber writes to, so dragging the year forward sweeps the camera across the events of that period in order.

Performance: one draw call, not a thousand

Each marker as its own mesh means a draw call each, and a phone GPU will stall. Use InstancedMesh: one geometry, one material, N transforms.

const ref = useRef();
useLayoutEffect(() => {
  const m = new THREE.Matrix4();
  events.forEach((e, i) => {
    m.setPosition(latLngToVec3(e.lat, e.lng, 1.01));
    ref.current.setMatrixAt(i, m);
  });
  ref.current.instanceMatrix.needsUpdate = true;
}, [events]);

return (
  <instancedMesh ref={ref} args={[null, null, events.length]}>
    <sphereGeometry args={[0.012, 8, 8]} />
    <meshBasicMaterial />
  </instancedMesh>
);

Budget rules that held up on real devices: keep the steady-state under ~100 draw calls, cap pixel ratio with dpr={[1, 2]}, use low-poly marker geometry (8 segments is plenty at that scale), and gate the render loop with frameloop="demand" so you only redraw when something actually moves.

Making the data citable for LLMs

A canvas is opaque to crawlers and language models — they cannot read a WebGL buffer. So every figure rendered on the globe also exists as server-rendered, sourced text. Each event carries structured metadata (Event / Place schema.org JSON-LD with startDate, location, and a numeric toll) and a visible citation to the source for that figure. Death tolls vary across historiography, so we render a range with its source rather than a single confident number. That way a model summarizing the period quotes a figure it can attribute, and a reader can trace it back. The GEO win and the editorial integrity are the same discipline.

Closing

This is the engine behind DeathVault and its sibling PlagueAtlas — free, interactive maps of historical death tolls from wars, disasters, and pandemics, built to be read carefully rather than scrolled past. The techniques above are general; the care taken with the numbers is not optional.

Built by Furiosa Studio.

Building a timezone meeting planner that doesn't lie to you

Furiosa Studio — Tue, 07 Jul 2026 08:00:03 +0000

Timezone math is one of those problems where the bug is invisible until it ships: the demo works because everyone testing it sits in the same offset, and then someone in Kathmandu joins a "10am" call at the wrong hour. The root cause is almost always the same — treating a clock reading as if it were an absolute instant.

Why you should never do timezone math by hand

The naive approach is to grab a UTC offset and add hours. It breaks on contact with reality:

Offsets aren't whole hours. India is UTC+5:30, Nepal is UTC+5:45, parts of Australia run +8:45.
Offsets aren't fixed. A zone's offset changes across the year because of DST, and the transition dates differ by country (and have changed historically).
"Working hours" aren't universal. 9–5 in one place overlaps with a lunch break or a pre-dawn hour in another.

A stored "+2" is a fact about one instant, not about a place. The moment you persist an offset and reuse it, you've baked in a bug.

Get correct local hours from the IANA database

The fix is to stop storing offsets and start storing IANA zone identifiers (Europe/Madrid, Asia/Kolkata). The runtime owns the offset rules and applies whichever one is correct for a given instant. Intl.DateTimeFormat does this today, no dependencies:

function localHour(instant, timeZone) {
  const parts = new Intl.DateTimeFormat('en-US', {
    timeZone, hour: 'numeric', hour12: false, minute: 'numeric',
  }).formatToParts(instant);
  const h = +parts.find(p => p.type === 'hour').value;
  const m = +parts.find(p => p.type === 'minute').value;
  return h + m / 60; // 5.75 for Kathmandu when it's midnight UTC + offset
}

The fractional return matters: a person in Nepal whose day starts at 9:00 local is at a different grid position than someone on a whole-hour offset. The emerging Temporal API makes this cleaner — Temporal.ZonedDateTime carries the zone with the instant, so arithmetic stays correct:

const zdt = Temporal.Instant.from('2026-03-29T09:00Z')
  .toZonedDateTimeISO('Europe/Madrid');
zdt.add({ hours: 6 }).hour; // DST-aware, not naive +6

The DST trap

Here's the part that catches people twice a year. Say Madrid and New York agree on a recurring 3pm Madrid call. Both observe DST, but they switch on different weekends. For about two weeks each spring and fall, the gap between them is 5 hours instead of the usual 6. A meeting that was comfortable for New York silently moves an hour earlier in their day — without anyone touching the invite.

This is why you must compute overlap for the specific date the user is planning, never from a cached offset. Resolve each zone's local hours at that instant and the DST handling falls out for free.

Intersecting working hours across N people

Model each person as a local working range, normalize everything to a common axis (UTC works), then intersect. With each range expressed as [startUtc, endUtc) in minutes-from-midnight-UTC, the N-way intersection is a fold:

function intersect(ranges) {
  return ranges.reduce((acc, r) => {
    const start = Math.max(acc.start, r.start);
    const end = Math.min(acc.end, r.end);
    return { start, end: Math.max(start, end) };
  });
}
// empty result (start === end) means no shared hour

Because each range was derived from the IANA rules at the planned date, half-hour offsets and DST are already encoded in the UTC bounds — the intersection logic itself stays trivial and correct.

Render overlap as a gradient, not a yes/no

The interesting UX decision: a binary "works / doesn't work" grid throws away information. With five people across enough zones, a perfect slot often doesn't exist — but "4 of 5 are in core hours and the 5th is in their early evening" is a real answer.

So color each hour cell by how many participants are inside their preferred range, with a lighter band for "awake but outside ideal." Count overlaps per hour:

function overlapScore(hourUtc, people) {
  return people.filter(p => hourUtc >= p.start && hourUtc < p.end).length;
}

Mapping the score to opacity turns the grid into a heatmap. The eye finds the darkest column in a second — no arithmetic required from the user.

Hand back a shareable invite

Once a slot is chosen, the planner should emit a real calendar event, not a screenshot. iCalendar is plain text, and the trick is to write the times in UTC (Z suffix) so every client re-renders them in its own zone correctly:

function toICS({ startUtc, endUtc, title }) {
  const z = d => d.toISOString().replace(/[-:]/g, '').replace(/\.\d{3}/, '');
  return [
    'BEGIN:VCALENDAR', 'VERSION:2.0', 'BEGIN:VEVENT',
    `DTSTART:${z(startUtc)}`, `DTEND:${z(endUtc)}`,
    `SUMMARY:${title}`, 'END:VEVENT', 'END:VCALENDAR',
  ].join('\r\n');
}

Serve that as a .ics download or a data: URL and the recipient gets a one-click add that lands at the correct local time on their machine — the same instant, rendered honestly everywhere.

Closing

None of this is exotic; it's just the discipline of storing instants plus zones instead of offsets, and recomputing at the planned date every time. That discipline is exactly what TimezoneMatcher implements — drop in everyone's cities, see the overlap as a heatmap, and export the invite, free and with no login.

Built by Furiosa Studio.

How we model the Golden Boot race across 30+ leagues

Furiosa Studio — Tue, 30 Jun 2026 08:00:05 +0000

"Top scorer of a league" sounds like one line of SQL: SELECT player, COUNT(*) FROM goals GROUP BY player ORDER BY 2 DESC. Build a live product around that query and you find it's wrong in at least four ways. Here's what actually goes into a multi-league golden-boot table that stays correct.

1. The naive query, and why it lies

Three things break the one-liner immediately:

Mid-season transfers. A striker who scores 9 for one club and 6 for another is one player with 15, not two rows. Key your goals on (player_id, club_id) and he splits in two and drops off the chart.
Penalties and own goals. Some boards count penalties, some publish a separate non-penalty tally; own goals must never be credited to the scorer. "A goal" is not one thing.
What "the race" even means. Goals only? Goals + assists? Per-90? Each is a different leaderboard, and people want to switch between them.

2. The data model

Scope every event to a (league, season) and resolve players to one canonical entity across clubs:

players(id, canonical_name, ...)
appearances(player_id, club_id, league_season_id, minutes)
goal_events(id, player_id, league_season_id, minute, type)  -- open_play | penalty | own_goal

Aggregate over player_id scoped to league_season_id (not club), so transfers within a league sum correctly, and the type column lets you include or exclude penalties on the fly.

The hard part isn't the schema — it's entity resolution. 30+ feeds spell names differently ("J. Bellingham", "Jude Bellingham", "Bellingham, J."), reuse IDs, and disagree on accents. Normalize the name, match on (normalized_name, club, birth_year), and keep a manual override table for the genuinely ambiguous cases. Reconciling messy third-party feeds is the unglamorous 80% of any sports-data product.

3. Goals vs expected goals (xG)

A raw count says what happened; xG says how sustainable it is. A striker on 12 goals from 6.0 xG is overperforming and likely to regress; one on 8 from 11.0 xG is unlucky and probably about to score. Store xG per shot, sum per player-season, and show the delta next to the raw count — it's the most useful column for anyone predicting the rest of the race.

4. Keeping it live

Goals arrive continuously and stats get retroactively corrected (a goal reassigned, a penalty reclassified days later). So ingestion is idempotent: every event has a stable source key, re-ingesting updates in place, and a nightly reconciliation pass catches corrections. Without idempotent upserts you double-count; without reconciliation you drift from the official record.

5. Serving it

A leaderboard is read-heavy and identical for everyone, so it's cached hard and exposed through a small public REST API (/players, /standings, compare endpoints). Caching is easy; invalidating the moment a goal lands without hammering the origin is the interesting part — key the cache on (league_season, stat, updated_at) and let new events bump the tag.

Takeaway

"Aggregate a leaderboard from several unreliable sources" is a pattern far beyond football — pricing, reviews, any vendor feed. The shape is always the same: resolve entities, define the metric precisely, make ingestion idempotent, cache the read path.

This is what powers top-scorers.com — live top scorers across 30+ leagues, goals vs xG, and a free public API. Built by Furiosa Studio.

Eclipse mechanics for programmers: turning ephemeris data into a "next eclipse from here" countdown

Furiosa Studio — Wed, 24 Jun 2026 08:00:02 +0000

"When's the next eclipse visible from here?" sounds like a lookup. It's actually two hard problems stacked on top of each other: predicting when an eclipse happens, and predicting whether it's visible from one specific point on Earth. The total solar eclipse crossing Spain on 12 August 2026 — the first over the Spanish mainland in over a century — is a perfect worked example, so I'll use it throughout.

This is a write-up of how we built the prediction and countdown logic behind a small eclipse tracker. No framework lock-in; the ideas port to any language.

1. Where eclipse predictions actually come from

You do not compute eclipses from scratch in a web app. The orbital mechanics (lunar position to arc-second precision, Besselian elements) are solved problems, and re-deriving them in JavaScript is how you ship a tracker that's quietly wrong.

Instead you consume a canon — a precomputed catalog of eclipses with their circumstances. NASA's Five Millennium Canon of Solar Eclipses is the reference dataset; for each event it gives the instant of greatest eclipse (in Terrestrial Time), the magnitude, and the Besselian elements that let you reconstruct the shadow's geometry.

The pragmatic move: bake the events you care about into a static JSON file at build time.

{
  "id": "2026-08-12-total-solar",
  "type": "total",
  "peakUTC": "2026-08-12T18:46:13Z",
  "magnitude": 1.039,
  "centralPath": "2026-08-12-path.geojson"
}

Now the runtime never does ephemeris math. It does timezone conversion and a point-in-polygon test — both cheap and both correct.

2. Event vs. visibility: the part everyone gets wrong

An eclipse is a single global event in time, but visibility is local. A solar eclipse is total only along a narrow path of totality (often under 200 km wide); on either side you get a partial eclipse; far enough away you see nothing.

So "is the 2026 eclipse visible from the user's location?" is really three questions:

Is the user inside the path of totality? → they see totality.
Are they inside the much wider partial zone? → they see a partial eclipse.
Outside both? → not visible.

The path of totality is a polygon (a long thin one). Once you have it as GeoJSON, the test is ordinary computational geometry — ray casting:

// point-in-polygon via ray casting; ring is [[lng, lat], ...]
function inside(point, ring) {
  const [x, y] = point;
  let hit = false;
  for (let i = 0, j = ring.length - 1; i < ring.length; j = i++) {
    const [xi, yi] = ring[i];
    const [xj, yj] = ring[j];
    const crosses = (yi > y) !== (yj > y) &&
      x < ((xj - xi) * (y - yi)) / (yj - yi) + xi;
    if (crosses) hit = !hit;
  }
  return hit;
}

For the partial zone you can either ship a second, wider polygon, or approximate: if the user is within a few thousand km of the central path, the Sun is at least partially eclipsed. For a consumer tracker the polygon test is plenty.

A subtlety worth knowing: the path of totality is computed on an idealized ellipsoid, so right at the edges (the "graze line") real visibility depends on local terrain and your exact altitude. Don't promise totality to someone sitting on the boundary — show them "edge of the path" and let them move.

3. Local timing and a countdown that survives reloads

The canon gives you the peak in UTC. Converting to the user's wall clock is a one-liner with Intl — and you should let the browser own the timezone rather than storing an offset (offsets change with DST; zones don't):

const peak = new Date("2026-08-12T18:46:13Z");
new Intl.DateTimeFormat(undefined, {
  dateStyle: "full",
  timeStyle: "long",
}).format(peak);
// → "Wednesday, 12 August 2026 at 20:46:13 CEST" for a user in Madrid

For the live countdown, the trap is setInterval(fn, 1000) as your source of truth. Intervals drift, throttle in background tabs, and pause when the device sleeps. Always recompute from the absolute target each tick:

function tick() {
  const ms = peak.getTime() - Date.now();   // recompute every frame
  render(ms);
  if (ms > 0) requestAnimationFrame(tick);
}

Date.now() is wall-clock truth; the loop just decides when to read it. Now a backgrounded tab that wakes after an hour shows the correct remaining time instead of being an hour behind.

4. Make it an installable, offline PWA

An eclipse tracker is exactly the app you want working when you're standing in a field with one bar of signal. Everything it needs — the event JSON, the path GeoJSON, the timing logic — is static, so it caches cleanly.

// service worker: cache-first for the eclipse data
const CACHE = "eclipse-v1";
const ASSETS = ["/", "/eclipses.json", "/2026-08-12-path.geojson"];

self.addEventListener("install", (e) =>
  e.waitUntil(caches.open(CACHE).then((c) => c.addAll(ASSETS)))
);

self.addEventListener("fetch", (e) =>
  e.respondWith(
    caches.match(e.request).then((hit) => hit ?? fetch(e.request))
  )
);

Add a web app manifest with display: "standalone" and the user can install it to the home screen. The countdown then runs entirely offline — the math doesn't need a network, only Date.now() and a cached target.

5. The 12 Aug 2026 path, end to end

Putting it together for one user in, say, Bilbao:

Load eclipses.json, find the next event with peakUTC > now → the 2026 total.
Geolocate the user (or let them pick a city), run the point-in-polygon test against the path GeoJSON.
Bilbao sits inside the path → render "Totality. ~1m 30s of darkness."
Convert peakUTC to local time via Intl, start the requestAnimationFrame countdown.
Service worker has all three files cached → it keeps counting with the phone in airplane mode.

No server round-trips at runtime, correct to the second, works in a field.

If you'd rather not build it, this is exactly what we ship at NextEclipse — a free, installable PWA that tracks every upcoming solar and lunar eclipse, with local visibility and a live countdown for your spot (including 12 Aug 2026). Built by Furiosa Studio.

Hello from Furiosa Studio

Furiosa Studio — Tue, 16 Jun 2026 21:59:57 +0000

Furiosa Studio is an indie studio shipping small, useful web tools and data sites — football stats, timezone tools, astronomy trackers and more.

This post is published automatically through our own multi-channel publisher (Supabase queue + edge function). More to come.

— Furiosa Studio