Use Cases

Use Cases

VTX is infrastructure. This page walks through the product categories that sit on top of it: what people build once they have frame-accurate, self-describing state data in an open container.

If you're deciding whether VTX is the right substrate for something you're building, this is also the page that covers when it isn't. See When VTX is not the right tool at the bottom.

Broadcast replay

Every frame, every angle, every entity, live or on-demand.

A VTX capture carries full state per frame, not a summary: positions, weapons, abilities, scores, bone transforms, events. Broadcast tooling can scrub, re-camera, and re-cut a moment without going back to video. Any angle, any entity, frame-accurate.

Because VTX is random-access by frame (see File Format, Footer / time index), a director can jump to any point in a match in sub-millisecond time when the target chunk is warm, or tens of milliseconds on a cold seek. Scrubbing is a binary search in the footer plus one chunk decompress.

What broadcast tooling on top of VTX typically does:

• Multi-angle virtual cameras reconstructed from the bone and transform data.
• Live heat maps and tactical overlays driven from the entity bucket.
• Event-triggered replays (kills, goals, round wins) using the events bucket as the index.

AI training data

Structured per-frame state straight from gameplay. Ground truth for motion, decision, and simulation models, at gameplay fidelity rather than reconstructed from video.

Why VTX is a good training substrate:

• Self-describing. The embedded schema means a file is independently interpretable; your training pipeline does not need engine-specific decoders.
• Generic query layer. An AI pipeline can consume the generic API output directly and stay cross-title by default. See Concepts, Dual-schema architecture.
• Random access. Sample frames for batches without sequential replay. The footer index makes out-of-order access cheap.
• Portable. Pure C++ reference reader plus language bindings anywhere Protobuf or FlatBuffers exist (Python, Go, Rust, Java, JS, ...).
• Type safety. Entity properties carry explicit types on the way in and out. No guessing whether a float field actually holds an int.

Common pipelines:

• Motion and pose models trained on per-bone transforms.
• Decision models trained on (state, action, outcome) tuples pulled from the event bucket.
• Reinforcement learning environments seeded from recorded states.

Live analytics and overlays

Streaming-first binary. Low-latency data for real-time overlays, in-venue screens, and tactical feedback.

The same format works for both streaming and storage: a tool written for archival analysis can be pointed at a live stream without changes. One capture drives any number of downstream applications. See File Format, Streaming vs. storage.

Coaching tools

Full-state replays teams can scrub, annotate, and query. Not a heatmap over a minimap; the actual positions and decisions, frame by frame.

Good fit for coaching because:

• Every frame is complete. There is no "you had to be there" data loss.
• Contextual schemas expose game-specific concepts (weapon loadouts, ability cooldowns, economy state) without forcing every tool to care about them.
• Annotations and derived analysis can be layered on top of the raw state without modifying the VTX file.

Common tooling patterns:

• Timeline-scrubbing UIs with attached voice / text notes.
• Automated highlight extraction from the events bucket.
• Team-aggregate stats computed over a season of captures.

Second-screen and fan companions

Mobile companions that track a live match with structured data. Stat cards, per-player views, interactive timelines, all from a single VTX stream.

Because VTX is open and the reader is portable C++, a mobile app can read the same stream a broadcast overlay reads. One source of truth across platforms. Mobile clients typically either:

• Consume the stream directly (using Protobuf / FlatBuffers bindings in the app's language).
• Consume a downsampled derivative produced by a backend service from the full VTX feed.

Both are supported by the same format.

Third-party apps

Any tool that can read a binary file can read VTX. Analytics dashboards, second-screen companions, coaching tools, mods, training-data pipelines, community tooling. The format is open, the reference reader is portable, the licence is Apache-2.0.

This matters because it flips the default. Historically, third-party tooling for a given title waited on the publisher to ship an API. With VTX, capture is decoupled from the publisher and the container is decoupled from any single reader.

3D Game Twins

Combine VTX with an asset layer (meshes, materials, animations, VFX) and you get a live Game Twin running in a rendering engine like Unreal: the actual game, re-rendered live, fully accessible to every tool in the stack.

VTX is the data side of a Twin. Frame-accurate, self-describing, engine-independent. Pair it with whatever asset system you already have.

Your use case

The format is open, the reference reader is portable, the licence is Apache-2.0. If you're building anything that needs frame-accurate, structured, engine-independent state data, VTX is designed to be the thing you build on top of.

Get in touch via the Zenos Interactive site or open a discussion on the VTX repo.

When VTX is not the right tool

Being candid about the other direction:

• Pixel-level broadcast workflows. VTX is state, not video. If your pipeline is fundamentally video-based (colour grading, compositing, traditional NLEs), you want a video format; VTX sits alongside it, not instead of it.
• Asset storage. VTX stores state and asset references, not the assets themselves. If you need a container for meshes / textures / materials, look at UAF (a separate Zenos project) or an existing asset format.
• Tiny, fire-and-forget telemetry. If you're emitting a handful of counters per second with no replay need, JSON over HTTP or a timeseries DB is simpler. VTX is worth the setup cost when you want full state per frame, random access, and a format you'll keep reading years later.
• Zero-dependency environments. The C++20 SDK needs a modern compiler and depends on Protobuf and/or FlatBuffers. For hard-embedded targets or restricted toolchains, evaluate the dependency surface first.
• Situations requiring a stable public ABI today. Pre-1.0, the SDK can break between minor releases. If you need a drop-in shared library with long-term binary compatibility, pin a tag and plan for source-level upgrades. See Stability.