Skip to main content

Helios case study

Building a Solar System that admits its limits.

The hard part was not drawing spheres. It was keeping cinematic motion, physical scale, changing data, visual provenance and user control inside one coherent product.

Helios began as a small planetary explorer and grew into a connected product with clear scene ownership, sourced body records, bounded visual assets, validated external data and tests that protect both scientific language and interaction behavior.

Detail destinations
6157 real bodies and 4 context regions with semantic routes.
Featured moons
22Planetary satellites with sourced orbit data and documented visual treatment.
Small bodies
18Asteroids, dwarf and Kuiper objects, and comets in the documented catalogue.
Texture ceiling
2KA fixed ceiling verified from the display asset list.

01 · Problem

Most Solar System products choose one extreme

Rich simulators can be difficult to read. Polished visual demos can hide weak data and scale assumptions. Helios needed editorial depth without giving up a continuous, explorable scene.

User question

What would another world feel like?

Diameter alone does not answer this. The product connects gravity, day and year length, atmosphere, light delay, missions and surface character to a human reference.

Engineering question

How can the scene stay trustworthy?

Body scale, orbital motion, camera behavior, visual assets and external observations each need clear rules that still resolve into one experience.

02 · Early corrections

The product improved by removing ambiguity

Several early directions were visually convenient but structurally weak. Each correction became an explicit architecture rule.

Scene controls

From overlapping controls to owned docks

Selection, Navigator, View and Time became distinct responsibilities. Retired quality and motion controls were removed instead of being left as inactive branches.

Texture lifecycle

From selection-triggered loading to staged readiness

The Sun loads first, followed by the eight planets and required primary layers. Secondary bodies use a scheduler and never block the opening sequence.

Time

From local animation state to a persistent simulation clock

Scrubbing, pause, speed, reset and ephemeris requests now share one timestamp. Returning to timestamp A must reproduce the same deterministic scene state.

Small bodies

From decorative points to source-backed systems

Moons, dwarf systems, asteroids and comets gained central IDs, orbit policies, source metadata, visual profiles and explicit fallback behavior.

03 · Key decisions

Decisions that keep the product consistent

Scene authority

Selection, camera and time have one owner

Bodies publish interaction intent. Central stores and the camera rig resolve focus, overview, the transition to manual control and deterministic time without allowing individual meshes to move the camera or rewrite the clock.

Scale

Legibility and physical ratio are separate profiles

Exploration mode enlarges bodies and compresses distance. Scientific mode uses a shared ratio. Both reuse the same scene system, materials and catalogue so the switch does not become a second implementation.

Assets

Every surface documents its representation

Real maps, derived maps and reference-guided visual reconstructions carry source, coverage, orientation and calibration notes. Display textures stay within a fixed ceiling and load from the Sun outward.

Orbit precision

A smooth animation is not called an ephemeris

Horizons-backed windows, representative mean elements and propagated previews are labelled separately. Missing poles or angular elements remain unresolved rather than being randomized for visual variety.

External data

External records are prepared before display

Server adapters validate and normalize responses, attach observation and retrieval metadata, apply service-specific cache rules and choose between current data, verified snapshots and static explanations.

Accessibility

The product survives without the canvas

Semantic navigation, server-rendered body pages, comparison tables, visible focus, reduced-motion behavior and a WebGL fallback ensure that 3D is an enhancement rather than the only information channel.

04 · Architecture

Server-rendered pages around a focused interactive core

The 3D experience stays client-side, while body narratives, metadata and most data presentation remain server-rendered.

Presentation

Routes and editorial composition

Next.js App Router pages, responsive CSS modules, semantic tables and body-specific layouts expose content without requiring WebGL.

Application

Selection, camera and simulation

Zustand stores hold bounded interaction state. Fast Three.js transforms stay inside the frame loop and do not write React state every frame.

Domain

Bodies, scale and orbital evaluation

Validated planet records, celestial registries, reference frames and shared orbit evaluators keep UI labels and rendered geometry tied to the same model.

Data

Adapters, cache and fallback

Zod schemas normalize provider responses. Each service defines its own timeout, revalidation, snapshot and unavailable behavior.

05 · Quality

Release confidence comes from evidence, not file presence

  • Static qualityFormatting, lint, Next.js route type generation, strict TypeScript, unit tests and the display-texture audit run together.
  • InteractionPlaywright covers smoke routes, keyboard flows, responsive layouts, time behavior, asset readiness and selection/camera contracts.
  • Visual evidenceReal canvas screenshots verify surfaces, lighting, orbit context, city-light rejection and small-body framing where DOM assertions are insufficient.
  • Scientific languageTests and source records distinguish accurate windows, representative models, historical observations, latest-available data and fallbacks.

06 · Result

A foundation that can grow without changing its story

The product is broader and clearer about its limits.

Explore can represent a body or region, its detail page can explain it, the Data page can state when an observation happened, and the case study can show the shared rules that keep those surfaces aligned. Later visual refinement can build on that foundation without redesigning camera, time, source or scale ownership.