ApexLab — Interactive F1 Race & Strategy Studio

Relive real Formula 1 races in interactive 3D, experience cockpit views, explore historical race data, and test alternative pit-stop strategies in a What-If Lab.

Comment

Inspiration

Formula 1 is a sport where milliseconds matter, but the decisions that shape a race are not always obvious from a broadcast. A tyre change, an early pit stop, or a changing track surface can transform the result long before the final overtake.

We wanted to give fans the freedom to investigate those moments themselves. What was happening around a particular driver? Why did one strategy succeed? What might have changed if a team had stopped earlier?

That curiosity inspired ApexLab — Interactive F1 Race & Strategy Studio, a browser-based application combining historical race exploration, interactive 3D reconstruction, and accessible strategy analysis.

Our goal is to help newcomers understand Formula 1 while giving experienced fans meaningful ways to explore the data and decisions behind a race.

What it does

ApexLab connects three experiences: exploring a race, understanding its strategy, and experimenting with alternatives.

Historical race archive

The archive contains 114 Grands Prix spanning 2021–2025, with available information including:

  • Actual driver lineups and teams.
  • Starting grids and final classifications.
  • Recorded lap timing.
  • Available tyre stints and pit-stop records.
  • Race-control information where available.
  • Positional data for supported replay experiences.

Coverage varies by event. Races with suitable positional records support spatial replay, while other events provide timing and historical information without generating fictional trajectories.

Interactive 3D replay

Users can select a driver and explore the race through cockpit-inspired, trackside, helicopter, and whole-circuit camera perspectives.

Playback controls allow users to pause, restart, adjust speed, and navigate the timeline. Timing panels and strategy information follow the selected replay moment, helping users connect the action with the underlying records.

Circuit surroundings, car bodywork, cockpit interiors, and pit-crew animations are visual reconstructions. They support an immersive experience without claiming to reproduce every physical detail of the original event.

Race timing and strategy exploration

Driver order, available timing gaps, tyre information, and pit-stop records help explain how a race developed.

Users can move between a close driver perspective and an overhead view to understand both individual moments and the wider race situation.

What-If Lab

The What-If Lab lets users investigate a nearby alternative to an eligible historical pit stop. They can adjust:

  • Pit-stop timing within the supported window.
  • The next dry-tyre compound.
  • Assumed tyre-wear cost.
  • Assumed net pit-stop loss.
  • An optional rejoin-traffic penalty.

The application calculates a separate hypothetical comparison. The recorded race remains unchanged, and simulated outcomes are clearly distinguished from historical facts.

Strategy School

Strategy School explains concepts such as tyre degradation, undercuts, overcuts, safety-car opportunities, and pit-stop timing through accessible lessons and interactive activities.

It helps users understand the reasoning behind the decisions they encounter in the replay.

How we built it

Frontend and 3D experience

We built ApexLab with React and TypeScript, using Vite for development and production builds.

The 3D experience uses Three.js, React Three Fiber, and Drei to render circuits, cars, lighting, animations, and camera perspectives.

Historical records, replay state, visual presentation, and hypothetical strategy calculations are handled separately. This allows users to explore different views and scenarios while preserving the original data.

Historical data pipeline

ApexLab uses historical records from Jolpica and OpenF1, subject to their coverage and usage terms.

Jolpica supplies race calendars, results, grids, and available lap and pit-stop records. OpenF1 provides available timing, tyre stints, race-control messages, positions, and telemetry for supported events.

Import scripts organize these records into JSON datasets served with the website. For supported races, additional positional data and car telemetry can also be downloaded directly from OpenF1 when requested.

The data flow is:

Historical providers → Import scripts → JSON datasets → Azure hosting → Browser

For on-demand recordings:

OpenF1 → Browser download → Optional device cache

ApexLab currently runs without a separate application backend. Replay processing, rendering, and What-If calculations happen in the browser.

Mathematics behind the replay and strategy model

The following equations describe the core calculations. They support data reconstruction and educational strategy comparisons rather than a complete vehicle-physics simulation.

1. Position interpolation

Recorded coordinates arrive at discrete timestamps. Between two valid samples, the recorded-position sampler uses linear interpolation:

alpha = (t - t0) / (t1 - t0)

position(t) = position0 + alpha × (position1 - position0)

Where:

  • t is the requested replay time.
  • t0 and t1 are neighboring recorded timestamps.
  • position0 and position1 are the corresponding coordinates.
  • alpha represents progress between the samples.

Interpolation is limited to valid intervals within the configured gap threshold, which defaults to three seconds. Longer gaps are marked instead of being filled with invented recorded positions.

The 3D presentation also uses track-guided reconstruction to follow circuit curvature smoothly. Source records and visual reconstruction remain distinct.

2. Direction of travel

A direction estimate is calculated from neighboring valid horizontal samples:

heading = atan2(y1 - y0, x1 - x0)

This estimates orientation from movement. It does not measure steering angle or reproduce complete vehicle dynamics.

3. Smooth visual transitions

Selected rendered properties use exponential smoothing:

smoothingFactor = 1 - exp(-k × frameTime)

newValue = oldValue + (targetValue - oldValue) × smoothingFactor

Where:

  • k controls responsiveness.
  • frameTime is the elapsed time between frames.
  • targetValue is the desired visual state.

This helps animations respond smoothly across varying frame rates without changing historical timing records.

4. Initial tyre-wear estimate

The historical What-If model estimates an initial wear coefficient from eligible consecutive lap-time changes:

lapChange = currentLapTime - previousLapTime

estimatedWear = clamp(median(eligibleLapChanges), 0, 0.300)

The coefficient is measured in seconds per additional tyre-age lap. When suitable observations are unavailable, the model uses an explicit fallback of 0.050 seconds.

The observed trend also includes fuel, weather, track evolution, and driver effects. It is therefore an editable scenario assumption rather than a pure measurement of tyre degradation.

5. Compound pace calibration

The model compares clean observations from the same race lap:

relativeCompoundPace = median(compoundLapTimes) - median(allEligibleLapTimes)

It then combines eligible observations and normalizes them against the recorded reference compound:

compoundOffset = median(relativeCompoundPace) - referenceCompoundMedian

The implementation prefers observations near the selected stint when enough are available. Driver and car differences remain a calibration limitation.

6. Simplified tyre pace contribution

For a supported dry-tyre lap:

tyreContribution = compoundOffset + wearCoefficient × max(0, tyreAge - 1)

The candidate pace change is:

paceDelta = candidateTyreContribution - baselineTyreContribution

This adjusts the historical baseline locally. It does not generate a completely new race.

Wet-to-dry crossover scenarios require additional assumptions and a separate observed transition adjustment; they do not simulate weather or grip physics.

7. Pit-stop loss

The model distinguishes recorded pit-lane duration from assumed net race-time loss.

The historical What-If baseline uses:

baselinePitLoss = 22 seconds

The candidate change is:

pitLossDelta = candidatePitLoss - baselinePitLoss

For lap-by-lap accounting, the cost is divided between the pit lap and the following lap:

pitLapCost = splitFraction × totalPitLoss

followingLapCost = (1 - splitFraction) × totalPitLoss

The split is estimated from recorded pit-lane overlap when available. It is an accounting approximation rather than a measurement of stationary service time.

8. Hypothetical lap and race time

For each affected lap:

lapDelta = paceDelta + pitCostDelta + trafficPenalty

The optional traffic penalty is applied once on the lap after the candidate stop.

The total difference is:

totalDelta = sum(allLapDeltas)

The hypothetical total is anchored to the recorded classification time:

hypotheticalRaceTime = actualRaceTime + totalDelta

Interpretation:

  • Negative totalDelta means faster in the model.
  • Positive totalDelta means slower in the model.
  • Zero totalDelta matches the baseline.

9. Comparison rank

For eligible full-distance finishers:

comparisonRank = 1 + numberOfEligibleRivalsWithFasterRecordedTimes

Rivals retain their historical times. This comparison does not simulate overtaking, defensive driving, incidents, or rival responses, and it is not a prediction of an actual finishing position.

Hosting and deployment

ApexLab is deployed on Microsoft Azure Static Web Apps.

A GitHub Actions workflow installs dependencies, runs automated tests, builds the production application, and deploys successful updates.

The deployed release passed 75 automated tests, followed by live checks of data loading, application routing, and 3D rendering.

Challenges we ran into

Incomplete historical coverage

Historical datasets vary in detail. Lap timing may exist where positional telemetry does not, and sparse samples cannot establish every movement.

We addressed this through coverage information, limited interpolation, and timing-based alternatives for events without reliable spatial data.

Balancing immersion with accuracy

A polished scene can appear more precise than its source records. We had to distinguish recorded data, interpolation, reconstructed presentation, and hypothetical calculations throughout the experience.

Car overlap and camera visibility

Cockpit views made clipping and overlapping cars especially noticeable. We worked on presentation spacing, visibility handling, and camera behavior.

These rendering adjustments improve readability without claiming to establish exact historical lateral placement or physical collisions.

Browser performance

Multiple animated cars, circuit scenery, overlays, and pit crews create a substantial rendering workload.

Balancing detail with responsiveness required attention to reusable geometry, rendering costs, and efficient frame updates.

Explainable strategy analysis

A useful strategy comparison needs clear assumptions. We constrained the historical What-If model to supported local changes and kept the original records intact.

Users can inspect how pace, assumed pit loss, and traffic contribute to the calculated result.

Accomplishments that we're proud of

  • A connected experience: historical exploration, interactive 3D views, timing, and strategy analysis in one application.
  • Five seasons of race records: an archive of 114 Grands Prix with coverage-dependent features.
  • Multiple camera perspectives: close driver views alongside aerial and whole-circuit exploration.
  • An explainable What-If Lab: deterministic calculations with visible assumptions.
  • Accessible education: Strategy School connects racing terminology with interactive examples.
  • Clear distinctions between data and simulation: historical records remain separate from hypothetical outcomes.
  • Automated deployment: tested production builds delivered through GitHub Actions.
  • A working Azure release: verified data access, routing, and 3D rendering outside the development environment.

We are especially proud of connecting immersion with understanding. Users can watch a moment, investigate the strategy, and explore an alternative within the same application.

What we learned

We learned that an interactive racing application depends on synchronization. Race time, car presentation, timing panels, camera behavior, and user controls must agree about the moment being shown.

We also learned that historical accuracy requires communicating uncertainty. Interpolation is useful within valid intervals, while missing information needs clear treatment.

Building the What-If Lab taught us to separate observation from assumption. An observed lap-time trend is not pure tyre degradation, and recorded pit-lane duration is not equivalent to net time lost.

Usability proved equally important. Clear controls, readable timing, and understandable explanations make complex information easier to explore.

Finally, automated testing and deployment helped us iterate with greater confidence as the application expanded.

What's next for ApexLab — Interactive F1 Race & Strategy Studio

Improve visual fidelity

We plan to refine circuit geometry, vehicle assets, cockpit environments, camera transitions, and pit-stop presentation while maintaining browser performance.

Strengthen historical coverage

We want to expand supported datasets where reliable information and permitted usage allow it. Clearer coverage indicators will help users understand each event's capabilities before starting a replay.

Develop deeper strategy analysis

Future improvements include circuit-specific pit-loss assumptions, clearer uncertainty ranges, and sensitivity analysis.

Users should be able to investigate how a result changes across plausible assumptions rather than relying on a single estimated time difference.

Connect lessons to historical moments

We want to link more educational content directly to race events so users can learn a concept and immediately examine an example.

Improve accessibility

Planned improvements include smaller-screen layouts, keyboard navigation, reduced-motion behavior, and clearer controls for users with different levels of racing knowledge.

Our goal is to make ApexLab a place where fans can experience races, understand pivotal decisions, and explore alternatives with transparent evidence and assumptions.

Project links

Live website: Open ApexLab

GitHub repository: View source code

Built With

Share this project:

Updates

Submission history