Research / 2026-05-16 / 7 min read
Why running TDA in real time is an unreasonable thing to try
Topological data analysis has excellent offline algorithms. A 16ms frame budget is where those algorithms stop being convenient and start becoming an engineering problem.
What TDA is actually doing
Topological data analysis extracts shape information from data. The key tool is persistent homology: for a set of points, you grow a neighbourhood around each point and track when connected components merge, when loops form, and when voids appear or disappear. The result is a persistence diagram or barcode — a summary of topological features and how long they survive as the neighbourhood radius increases.
This is genuinely useful. Persistent homology is stable under noise and deformation in ways that distance-based metrics are not. It captures structure that neither clustering nor dimensionality reduction sees cleanly. For static datasets and offline pipelines, the tooling is mature.
The difficulty is that every mainstream TDA algorithm assumes you have the data before you start. They are batch algorithms operating on snapshots.
The offline assumption
A full Vietoris-Rips complex computation on n points is O(n²) or worse in the dimensions that matter. Standard persistent homology reduction using boundary matrices is expensive in both time and memory. These costs are acceptable when you run the computation once on a static point cloud, wait, and use the result.
They are not acceptable when the point cloud is a live game scene and the result is required before the frame ends.
The field has known this. Most responses are one of three things: approximate the topology, reduce the dataset aggressively before computing, or accept that real-time TDA is a theoretical exercise rather than an engineering one. The Hyperplex.TDA research architecture commits to the first, hard: compute cheaper topological signals in real time, and keep full persistence offline where it belongs.
Why 16ms is the interesting number
A game running at 60 FPS has 16.6 milliseconds per frame. That budget covers physics, AI, rendering, audio, and everything else the engine does before the GPU presents the next image. A frame that misses budget is visible. Repeated misses are a complaint, a refund request, or a review with the word 'unplayable'.
A TDA runtime that cannot fit inside a frame budget is not a real-time system. It is a slow batch system with a marketing problem.
The 16ms constraint is not arbitrary. It is the filter that determines whether topological information can participate in gameplay decisions, rendering effects, AI perception, or spatial analysis in a live system. Below the threshold, topology becomes a tool. Above it, it remains a research curiosity.
The honest move: don't run persistent homology in real time
The decision that makes Hyperplex.TDA tractable is refusing the premise. It does not try to compute persistent homology every frame. Full persistence is exactly the batch, allocation-heavy reduction that has no business inside a 16ms budget, so it stays in an offline tier where it can take the time it needs.
What the runtime computes instead is a small set of cheaper topological signals that still answer the operational questions. β₀, the number of connected components, comes from a union-find pass and detects splits and merges directly. λ₂, the Fiedler value of the graph Laplacian, tracks algebraic connectivity — how close the network is to falling apart — using a fixed iteration budget. A β₁ proxy approximates the number of independent loops from cycles in a spanning forest, bounded per component and shown only once it stays stable for several frames.
None of these is the full persistence diagram. All of them fit inside the budget, and for a live swarm they carry most of the signal that matters: is the fleet one network or several, where are the bottlenecks, which loops are holding. Persistent homology stays available — offline, on snapshots, where its cost is affordable.
Where the work actually runs
With full persistence off the hot path, the runtime stops being a topology solver and becomes a budgeted pipeline. The expensive geometry — spatial hashing and building a bounded-degree neighbour graph — runs as Burst-compiled jobs on the CPU, in structure-of-arrays layout with no per-frame managed allocation. The connectivity passes (union-find, the spectral iteration, cycle extraction) consume that graph.
The GPU's job is visualization, not topology. Component colours and active cycles are written to compute buffers and drawn with indirect instancing, so rendering ten thousand agents and their structure does not mean instantiating ten thousand objects. This is the inversion of the obvious design: the GPU is not where the homology happens; it is where the result is shown.
All of it runs as a strict multi-rate pipeline with a per-subsystem budget that has to add up to one frame. The cheap signals run hot; the loop proxy runs slower and is best-effort, skipped and reused stale rather than allowed to stall the main thread. The full reduction runs offline, in a separate .NET 10 CLI, against exported snapshots.
What is solid, and what is still being measured
What is solid is the design. The tiered budget contracts, the determinism and replay policy, and the golden-dataset test methodology are locked. The runtime computes the budgeted signals; the offline .NET 10 CLI computes the high-fidelity analysis, including full persistent homology, validated against reference implementations on known datasets with deterministic, tolerance-bounded results.
What is honestly still in progress is the published evidence at scale: profiler captures, zero-allocation reports, and benchmark numbers at real agent counts. The claim today is architectural, not numerical. Invented benchmark numbers would be easy and worthless; the open question is whether the budget discipline holds as the swarm grows, and that is the work.
Research notes will be published here and on this blog when results are stable enough to be useful rather than merely suggestive. If you work in computational topology, real-time systems, or swarm robotics and have thoughts on the approach, the contact form is the right place. Questions that challenge the methodology are more useful than encouragement.