Coding for Creative Research · Final Assignment
Beyond the Screen
Making F1 telemetry tangible
A first-person, practice-based account of turning raw Formula 1 gear-change telemetry into a physical object you can hold — and of asking whether that translation makes technical race data legible to people who cannot read it on a screen.
01 · Integers
Gear is a whole number between 1 and 8, sampled around the lap.
02 · Height
Each gear value is mapped to a vertical height along the track.
03 · Geometry
A ring is added at every gear change, sealing the mesh and marking it by touch.
Diagram of the translation, not a plot of the dataset. The real exports and the printed object appear further down.
Programme
MRes Creative Computing
Institution
University of the Arts London
Submitted
30.11.2025
Methods
Python · 3D printing · Data physicalisation · Accessibility
01 — The question
What creative and technical possibilities emerge when exploring the conversion of raw F1 telemetry data into tactile, three-dimensional forms? How can this exploratory design practice reveal new approaches to accessible data visualisation?
Formula 1 generates an enormous amount of data and delivers almost all of it to a screen. Line traces, sector deltas, colour-coded track maps — formats that assume you already know how to read them. If you do not, or if you cannot see them, the data is effectively closed.
This project asks what happens if you take one narrow slice of that data and give it a body. Not a better chart. An object, printed at desk scale, that carries the same information in height and texture instead of in colour and line. The question is deliberately exploratory: it does not ask whether the object beats the chart, it asks what becomes possible when you try to make one, and what the attempt teaches on the way.
The second sentence is the harder one. Calling something an accessible visualisation is a claim about other people, and claims about other people need evidence from other people. This write-up is honest about where the project sits on that. It produced a working artefact and a great deal of process knowledge. It did not produce validation.
Data physicalisation: representing data through physical form and material rather than pixels, so that it can be read by touch and by handling as well as by sight.
I began this with no Python, no experience of 3D geometry processing and no 3D printing. Learning those was not preparation for the research. It was the research.
02 — Project overview
One lap, one number, made solid
The scope is deliberately small, because the point was never coverage. From a single lap of telemetry I take one channel — the gear the car is in — and turn that stream of integers into a physical object you can pick up. Height carries the gear; a ring marks every change. Nothing on the model needs a legend.
Choosing gear was a practical decision as much as a design one. It is already an integer between 2 and 8, so the mapping from data to height is honest and direct — no normalisation curve to argue with, no interpolation inventing values the car never held. That constraint is what made a first physical output reachable for someone starting from zero.
The lap itself is Max Verstappen’s opening lap of the 2024 São Paulo Grand Prix, taken from the race session. That single choice sits at the end of a long funnel of decisions, and it is worth seeing how narrow the slice really is.
Objective
Convert raw F1 telemetry into something you can read without training
Medium
Python, 3D geometry processing, FDM 3D printing
Output
A desk-scale printed model of one driver’s gear changes over one lap
Data source
Tracing Insights — Formula 1 data archives
1 / 5
sessions in the weekend
1 / 20
drivers on the grid
1 / 71
laps in the race
1 / 16
telemetry channels — gear
03 — Approach
First-person practice: the learning was the method
This is practice-based research where the learning journey is the methodology, not the preface to it. I set out to convert one-dimensional numerical telemetry into a three-dimensional tactile model, to test whether physical form could improve comprehension for people who cannot, or do not want to, read a conventional F1 data trace.
Because I began with no Python and no 3D-printing experience, every technical obstacle was also a finding. The interesting record is not a clean pipeline from idea to object; it is what each unfamiliar tool refused to do, and how the design changed to accommodate it. Failure and constraint are treated here as generative forces, not as noise to be cleaned out of the write-up.
Practice-based research: knowledge produced through the act of making, where the artefact and the process of arriving at it are themselves the evidence.
01
Document the complete process, from zero technical knowledge to a working, executable solution.
02
Investigate how wrestling with unfamiliar computational tools drives design innovation.
03
Explore the design space between abstract data and physical embodiment through making.
04
Use failure and constraint as generative design forces, not as problems to hide.
04 — Tools & data
Learning the toolchain by building with it
The environment came first: Visual Studio Code for editing, Git and GitHub for version control, and a Miniconda environment to keep Python and its packages isolated. Each of these was new. Setting them up correctly was the first real exercise in the tolerance for fiddliness that the rest of the project demanded.
The data arrives as JSON from the Tracing Insights archive — one lap holding sixteen synchronised channels. I read three of them: the x and y coordinates that trace the circuit, and the gear the car was in at each of 765 samples. Gear is the payload; x and y are only there to give it a path to sit on.
Multiplying gear by a scale factor turns it into a height, and a Savitzky–Golay filter softens the vertical steps just enough to print without erasing the changes themselves. That single filter choice — how much to smooth — turns out to be the hinge the whole build pivots on later.
The stack
VS Code · GitHub · Miniconda
Python · NumPy · SciPy
trimesh · matplotlib · plotly
Ultimaker Cura → FDM print
# load one lap of telemetry
data = json.load(open(‘1_tel.json’))
gear = np.array(data[‘tel’][‘gear’]) # integers, 2–8
# gear becomes height, then a gentle smooth
gear_scale = 80 # mm per gear
z = savgol_filter(gear * gear_scale, window_length=15, polyorder=3)
# downsample the path so the tube stays watertight
points = np.column_stack((x, y, z))[::2]
From telemetry_to_3D_refinement.py — the refined pass. gear_scale, the filter window and the [::2] downsample are the three dials the build kept returning to.
05 — The build
First, everything that did not work
The first idea was the obvious one: a flat track with a vertical bump at every gear change. It failed immediately. trimesh could not generate a watertight surface from that topology and exported a point cloud instead — a scatter of points describing a shape with no solid skin. For a 3D printer that is nothing at all.
Redesigning the track as a cylinder with ramped transitions held the geometry together, but watertightness stayed out of reach. What follows is the actual log of attempts — the mesh repairs and the smoothing passes — and what each one did. None of them, alone, produced something I could print. That is not a detour in the story. It is the story.
Watertight: a mesh whose surface fully encloses a volume, with no holes or unreferenced edges. It is the non-negotiable condition for a model to be sliceable and printable.
THE ATTEMPT LOG
✕
Flat track, vertical bumps
trimesh exported a point cloud — a shape with no solid skin. Unprintable.
✕
Cylindrical track with ramps
Geometry finally held together, but the surface still wasn’t watertight.
✕
Concatenation & mesh merging
Joined the parts; the seams between them stayed open.
✕
Hole-filling algorithms
Closed some gaps, missed others. Never a fully sealed volume.
✕
Duplicate & unreferenced vertex removal
A cleaner mesh, but cleaning is not sealing. Still not watertight.
✕
Linear interpolation
Smoothed the steps by flattening them — the gear changes went with them.
✕
Cubic spline interpolation
Introduced smooth curves the car never actually drove.
✕
Rolling average filter
Blurred exactly the transitions the model exists to show.
✕
Savitzky–Golay smoothing
The best of the four, but sensitive points still bumped the surface open.
None of these, on its own, produced a model I could print. Eventually the pattern became clear: the problem was never the smoothing. It was the architecture of the object itself.
06 — The breakthrough
A ring at every gear change
The fix did not come from smoothing harder. It came from changing what the object was made of. Instead of deforming the track surface to signal a gear change, I added a ring — a short toroidal tube — around the track at each change point. The ring is a closed, self-contained piece of geometry, so wherever one sits, that stretch of the mesh is watertight by construction.
What makes this the real result is that one move solved four problems at once. The constraint that had blocked the project for weeks — watertightness — turned out to be the thing that generated the model’s final form. The rings are not decoration added afterwards. They are the structural answer and the tactile language of the object, the same feature doing both jobs.
In the code, the tall gear-change bump (height 3× the tube radius) becomes a thin ring (0.9× the radius, 1.5× the width), placed from the full-resolution path while the track itself is downsampled. That diff between the two scripts is the whole breakthrough.
✓ Watertight
Each ring is a sealed surface, so the mesh encloses a real volume — printable at last.
✓ Tactile
Raised rings you can count by touch give an accurate, eyes-free reading of every gear change.
✓ Legible
Distinct ring structures stopped the gear data from being lost in the noise of the track.
✓ Robust
The mesh became reliable enough to slice and print without repair, every time.
THEN, THE REFINEMENTS
✓
Height vs. distinguishability
More height made changes clearer but re-opened watertightness — so height was traded back down until both held.
✓
Ring orientation
Perpendicular rings overlapped and clashed; aligning them to the track’s local direction let them sit cleanly.
✓
Resolution & data quality
The track path was downsampled (every 2nd point) to tame irregular smoothing while the rings kept full-resolution placement.
07 — Iterations
Twelve discarded exports
Every model below was abandoned. Read left to right, they are the actual sequence of the build — from a cloud of points that could not be printed to the ringed geometry that could.
01 · Point cloud model
trimesh returns points, not a surface. Nothing to print.
02 · Track line model
A path exists, but it has no thickness — still not a solid.
03 · Cylindrical track
A real tube at last. No gear information on it yet.
04 · Gear ramp model
Gear becomes height. Ramps open gaps in the mesh.
05 · Reduced height
Lower ramps close some gaps and cost some legibility.
06 · Smoothened
Filtering softens the steps — and starts erasing the data.
07 · Ringed model
The breakthrough: sealed rings mark each gear change.
08 · Thickness tweak
Tuning tube radius against ring radius.
09 · Enlarged model
Scaled up to test tactile readability by hand.
10 · Perpendicular
Rings set perpendicular overlap and collide.
11 · Reduced thickness
Thinner rings, cleaner separation between markers.
12 · Aligning tubes
Rings aligned to the track direction. This one prints.
08 — The outcome
The object that came off the printer
The finished print: one lap of the Sao Paulo circuit, height carrying the gear, a ring at each of the 33 gear changes.
What exists at the end is a single piece of black PLA about the size of an open hand. The loop is the circuit; the rise and fall along it is the gear; the beads are the moments the driver changed. You can find every one of them with your eyes shut, which was the point.
It is worth being precise about what this object is and is not. It is a faithful, physical trace of 765 telemetry samples from one lap. It is not a general-purpose visualisation system, and it has not yet been handed to the audience it was designed for.
Dimensions
134.2 × 207.5 × 17.5 mm
Print time
3 h 38 min
Material
41 g · 5.21 m filament
Gear changes
33 rings on one lap
Samples
765 telemetry points
Close up: the rings sit proud of the tube, so a fingertip can count them.
The same mesh in Ultimaker Cura — sliceable, with no repair warnings left to clear.
09 — Critical reflection
What it achieved, and what it cannot claim
Both columns below matter equally. The limitations are not caveats attached to a success — several of them are the most useful things the project produced.
WHAT WORKED
✓ Rapid skill acquisition
VS Code, Git, Python, Miniconda and Cura, learned from nothing in a single project. I am no longer afraid to open a programming language.
✓ Problem-solving under constraint
The ring architecture was not planned. It was forced out by a technical limit and became the design.
✓ Physical embodiment
A tangible object invites handling in a way a screen does not. People pick it up without being asked to.
✓ A pathway to accessibility
The model creates a multi-sensory route into telemetry that does not depend on sight or on prior F1 literacy.
WHAT IT CANNOT CLAIM
✕ No user validation
No testing was carried out with blind or non-technical audiences. Every accessibility claim here is a design intention, not a finding. This is the significant one.
✕ Print constraints came late
Printability was not designed for from the start, which is why so much of the build was spent recovering the geometry.
✕ Scope drifted to geometry
Time went into making the mesh printable rather than into the interaction or interpretation of the object.
✕ One variable, one lap, one driver
Throttle, brake and speed were never attempted, and no comparison between drivers or sessions was made.
Accessible design requires user testing to be valid. Exploratory prototyping generates evidence about possibility, not proof of accessibility.
10 — Where it goes
Phase two starts with the people
The honest next step is not a better model. It is user testing with visually impaired participants, because that is the only thing that can convert this from a plausible idea into an accessibility claim worth making. Everything else on this list is secondary to it.
Listed in the order I would actually do them, not in order of technical interest.
01
User testing
Put the model in the hands of visually impaired participants and validate whether the tactile language actually reads.
02
Embedded audio
Attach audio metadata to the model so it can describe the lap it represents.
03
Multi-scale versions
A macro model for whole-race performance, a micro model for lap-by-lap detail.
04
More telemetry layers
Throttle, brake and speed — individually and simultaneously — beyond the single gear channel.
05
Colour-coded prints
Multi-material printing so a second variable can be carried by colour as well as by form.
06
Comparative models
Two drivers side by side, or qualifying against race, so difference becomes physically obvious.
11 — Findings
What the process taught
01
Constraint as design catalyst
The ring solution did not come from inspiration. It came from a technical limit that refused to move, and it produced a better object than the original plan would have.
02
Tool literacy as creative practice
Learning the tools while solving the problem enhanced the outcome rather than delaying it. The fluency and the design decisions arrived together.
03
Iterative failure as knowledge
Each unsuccessful approach — the smoothing passes, the geometry attempts, the scale changes — generated a specific, actionable insight. Twelve discarded exports are twelve findings.
04
Physical translation reveals new questions
Moving from screen to printed object surfaced constraints that were invisible on screen, and those constraints shaped the final form more than any aesthetic choice did.
05
Documentation is research data
The record of what did not work, why, and what changed in response is not project admin. For practice-based research it is the evidence itself.
NEXT PROJECT
Reinforcement Learning and F1 Race Strategy
An MRes essay on whether a learning agent can outperform the pit wall — and what it would have to give up to do it.
Read the essay →