Aleksandr Shchilkin
Get in touch

Aleksandr Shchilkin

Viewing: Design Lab

shchilkin@gmail.com GitHub (opens in new tab)

Car Dashboard

A live browser cockpit where gauges, drivetrain simulation, engine sound, gamepad input, and acceleration tests read from one simulated car.

Speed, RPM, fuel, gear state, audio, and controls update from the same loop.

Clean speed gauge is 0 km/h.
P
mode
Off
17:54
000000 km
Clean speed gauge is 0 km/h.

Vehicle configuration

Change the drivetrain setup and apply it to the live cockpit simulation.
Try the acceleration test
  • Astro
  • React
  • TypeScript
  • Web Audio API
  • Gamepad API
  • Motion
  • Deterministic simulation

Car dashboards are dense everyday interfaces: speed, RPM, fuel, temperature, drive mode, warnings, and navigation all need to be readable at a glance. This browser version keeps those instruments tied to a running vehicle model.

The same work now feeds the newer configurable dashboard editor, with the next generation CarPlay design system as a reference for adaptable instrument surfaces WWDC 2024[1].

The dashboard is assembled from small pieces, but the visible result behaves like one cockpit.

Visual instruments stay separate from the simulation that feeds them. Gauges can be redesigned without changing the car model, and powertrain changes can be tested without touching the React layout.

Instrument layer

Speed, RPM, fuel, coolant temperature, gear state, and the on-board computer pages all share the same live car state.

Simulation layer

Car, chassis, powertrain, transmission, wheels, brakes, and fuel storage are modeled as focused TypeScript classes with unit coverage.

Input layer

Keyboard and Gamepad API input are merged every animation frame, while cockpit controls stay outside the instrument panel.

Audio layer

A procedural Web Audio graph follows RPM, throttle, engine type, and cylinder count without relying on recorded engine samples.

The same gauges, driver controls, and on-board computer are also mounted outside the car frame for inspection: open the instrument primitives.

A fresh car instance starts, shifts into Sport, runs full throttle, and reports the resulting acceleration numbers.

The physics layer produces repeatable numbers, which makes the cockpit easier to reason about while tuning drivetrain behavior.

Drag the sliders to change engine power, vehicle weight, or rev limit. The benchmark re-runs immediately because it does not depend on real time, rendering speed, or browser frame rate.

Benchmark inputs

Each control changes one physical assumption before the same acceleration run is replayed.

Engine power
Changes acceleration and drag-limited top speed.
Vehicle mass
Changes inertia, so the same engine needs more time to reach speed.
Rev limit
Changes shift timing and the RPM window used by the automatic transmission.
Fuel model
Keeps the dashboard values live while the benchmark still runs deterministically.

Configurable run

Change the car setup and compare how quickly the simulated vehicle reaches speed.

200 HP
80600
1500 kg
8002500
6000 rpm
40009000
73%
50100

The audio is generated in the browser. No engine samples are played back.

The synthesizer starts from the firing frequency of a four-stroke engine: f = RPM x cylinders / 120. Oscillators follow that frequency and its harmonics, then filtered noise and soft clipping add exhaust texture.

Parameter changes use short smoothing windows so RPM, throttle, and engine type can update every animation frame without clicks. The Web Audio API[3] context is still created lazily after user interaction to respect browser autoplay policy.

Sound playground

Listen to how RPM, throttle, cylinders, and engine type change the procedural engine sound.

Engine type
Cylinders
800 rpm
4008000
0%
0100

Keyboard and controller input feed the same simulation loop.

The dashboard accepts keyboard input and standard gamepads. The browser-native Gamepad API[4] is read with a polling model every animation frame, which matches how the simulation already advances.

Analog triggers become proportional throttle and brake. A dead-zone filters resting drift, while edge detection compares current and previous button state so drive-mode changes happen once per press.

The durable part of the study is the shared state model behind the instruments.

Modeling the powertrain as a chain of objects made the behavior easier to test: engine, ECU, transmission, wheels, chassis, fuel storage, and brakes all have separate responsibilities.

React handles the interface, TypeScript keeps the simulation explicit, Web Audio handles responsive sound, and the Gamepad API lets throttle, brake, and drive-mode input reach the same state loop.

The cockpit is becoming a configurable instrument system instead of one fixed dashboard layout.

The new layer keeps the live simulation, but changes how instruments are assembled. Gauge families now come from shared recipes, so the same speed, RPM, range, and power data can be drawn as technical dials, compact metrics, segmented strips, or hybrid-focused layouts.

That direction matters because the editor work needs real primitives to configure: not a screenshot of a cockpit, but slots, layers, scale density, styling, and data bindings that can survive outside one demo.

Canvas gauge recipes

Round dials, segmented strips, compact metrics, ticks, labels, arcs, and needles now render from reusable Canvas recipes.

Shared dashboard snapshot

The simulation is translated into one instrument-ready state, so visual gauges do not need to know how the car model is built.

Drivetrain-aware layouts

Combustion, electric, and hybrid dashboards can choose different instrument presets while staying on the same data contract.

Deep dive Open the Canvas gauge system Inspect the primitives, reference board, pattern catalog, and configurable gauge previews

The same gauge recipes can now be arranged, bound to vehicle data, tuned, saved, and reloaded as a dashboard document.

The composer is the first end-to-end editor pass: choose a module family, place it on the dashboard canvas, bind it to speed, RPM, power, range, or temperature, then adjust the exposed slots without changing the underlying simulation.

It keeps customization local to the dashboard document for now. That makes the prototype concrete enough to test persistence, unit switching, data binding, and slot controls before adding a larger preset library.

Dashboard composer

Arrange gauges as widgets

Preview settingsWide · 12x4 · Metric · AmberLocal document
Layout
Gridx
Theme
State
Normal driving state for balanced readability.Local document
LayoutWideGrid12x4Widgets4
Select a widget on the canvas
Clean speed gauge is 60 km/h.
Range is 218 km.
Average speed is 45 km/h.
Clean RPM gauge is 2200 rpm.

  1. v3.0

    Canvas instrument system

    The dashboard started moving from one hand-built cockpit toward configurable gauge families and drivetrain-aware layouts.

    Changed
    • Added a Canvas gauge renderer with reusable primitive recipes for dials, strips, ticks, labels, arcs, needles, icons, and readouts.
    • Added an instrument snapshot layer that separates simulation values from visual gauge recipes.
    • Added drivetrain-aware layout and preset selection for combustion, electric, and hybrid dashboard variants.
    • Added a component gallery for inspecting the new gauge vocabulary outside the live cockpit.
    • Added a dashboard composer prototype for arranging, binding, tuning, saving, and reloading gauge modules.
  2. v2.1

    Study refresh

    The page moved to the current Design Lab study structure used by Smiley Spheres.

    Changed
    • Moved the public URL to /design-lab/studies/car-dashboard.
    • Reframed the page around the working demo, acceleration test stand, procedural audio, input model, release log, and references.
    • Kept the old case-study URL as a permanent redirect.
  3. v2.0

    Simulation cockpit

    The dashboard became a richer cockpit with multiple powertrains, procedural audio, and controller input.

    Changed
    • Added gasoline, diesel, and electric powertrain variants.
    • Added automatic and manual transmission models with ECU-driven shift behavior.
    • Built procedural engine audio with Web Audio API oscillators, filtered noise, and soft clipping.
    • Added Gamepad API support with analog throttle and brake triggers.
    • Added the configurable acceleration benchmark and on-board computer pages.
  4. v1.0

    Initial dashboard

    First working browser dashboard with core gauges and a testable vehicle simulation.

    Included
    • Core instruments: Speedometer, Tachometer, circular gauges, linear gauges, and fuel level.
    • Physics classes for car, chassis, engine, fuel tank, transmission, and wheels.
    • Manual gear-shift logic with transmission utility tests.
    • Full dashboard layout and component previews for the instrument primitives.

Hybrid behavior

Add battery assist, regenerative braking, and blended power delivery to the drivetrain model.

Manual transmission depth

Model clutch engagement, stalls, missed shifts, and more driver-controlled gear behavior.

Driving scene

Connect the dashboard to a lightweight driving surface so the instruments react to road state.

Shareable editor states

Turn saved composer documents into shareable links, named presets, and comparison snapshots.

Source material and browser APIs that shaped the study.

  1. WWDC 2024: Say hello to the next generation of CarPlay design systemAutomotive interface reference for adaptable dashboard surfaces.
  2. Misha Charoudin on YouTubeVehicle behavior and performance reference for powertrain feel.
  3. Web Audio APIBrowser audio graph used for the procedural engine sound.
  4. Gamepad APIBrowser controller surface used for analog throttle and brake input.