Gaussian Splats and Sports: Why We Believe Real Time Requires a Different Architecture

We get asked all the time whether we are using Gaussian splats for sports.

The short answer is no.

That is not because we think Gaussian splats are unimportant. Quite the opposite. They are an exciting addition to the volumetric media landscape and are already helping push the industry forward in areas where traditional photogrammetry and other approaches have limitations.

But when it comes to sports, especially broadcast-quality sports, our view is different.

Sports is one of the hardest environments in media. It is fast, crowded, time-sensitive, and built around moments that matter immediately. That changes the technical requirements in a fundamental way. For sports, the challenge is not just visual quality. The challenge is whether a system can scale across athletes, cameras, frames, devices, and networks while still operating in real time.

That is where we believe Gaussian splats run into serious limitations.

This post is not meant to dismiss the work happening in splats. There are many smart teams doing valuable work in this area. Our goal here is simply to explain why, for sports, we have chosen a different path.

What Gaussian Splats Are Trying to Do

At a high level, Gaussian splats are designed to represent a scene in a way that can synthesize realistic viewpoints between captured camera perspectives. There are many good visual explanations of how this works, and we will link to some of those separately for anyone who wants to go deeper.

For this discussion, the important point is simple: splats depend on captured visual information from multiple perspectives and then use that information to reconstruct or render the scene from viewpoints that were not directly captured.

That can work very well in certain contexts.

But from a systems perspective, there is a tradeoff built into that approach: as you increase the number of perspectives, the amount of data and processing complexity rises as well. In sports, both of those variables escalate very quickly.

More Cameras Means More Processing

One of the biggest practical challenges with splats in sports is that adding more cameras to improve quality also increases the amount of data that needs to be processed.

That matters because sports is not a simple scene.

If you are trying to represent a surface area from multiple viewpoints, each additional camera adds more information about that area. In theory, that can improve reconstruction quality. In practice, it also means more data to ingest, organize, compare, and process.

The key issue is that this does not behave like a clean linear system.

In a very simple scene, adding one more camera may not change processing requirements dramatically. But sports is not a simple scene. Real-world sports environments include specular materials, motion, occlusion, varying textures, uniforms, lighting changes, and constantly shifting geometry. The more cameras you add, the more the processing burden rises, and that rise is not always predictable.

So while more cameras may improve coverage, they also push the system further away from real time.

That is a difficult tradeoff if your goal is live sports.

More Athletes Means More Scene Complexity

Even if the camera count stays the same, adding more athletes increases the complexity of the scene. A single athlete is one challenge. Two athletes are not simply double that challenge. Three or four athletes, plus objects, interactions, and occlusions, create a very different processing problem.

Yes, there are preprocessing approaches that can help organize data. Point-cloud organization, region-based segmentation, scene partitioning, databases, and related techniques can all help structure what the system is working on.

But architecturally, that means introducing more preprocessing and orchestration to improve the efficiency of something that was not originally designed for real-time sports processing in the first place.

The problem also does not scale in a clean or consistent way. Two athletes do not necessarily mean exactly twice the processing burden. The increase depends on motion, overlap, lighting, surface behavior, camera placement, and what the system is doing internally to resolve the scene. Sometimes the increase may appear manageable. Sometimes it may spike sharply.

That unpredictability is a serious issue for broadcast systems, where consistency matters almost as much as peak performance.

Sports Compounds Both Problems at Once

This is where the challenge becomes especially difficult.

In sports, when you add more athletes, you usually also need more coverage. That means more cameras. So the two scaling problems compound each other.

More cameras increase the amount of data per subject or surface area. More athletes increase scene complexity and interaction complexity. Put those together, and you do not get a small increase in processing burden. You get a system design problem that becomes harder and harder to manage in real time.

A tightly constrained demo may work under controlled assumptions: a limited scene, a known number of subjects, careful camera placement, minimal interference, and no surprise complexity.

Sports is not that.

A basketball game, football play, or baseball sequence does not stay clean and bounded. Players cluster. Bodies overlap. Objects move unpredictably. The scene changes instantly. The complexity is exactly what makes sports compelling, and it is also what makes sports such a difficult target for splat-based real-time systems.

At some point, the question is no longer whether an output can be produced eventually. The question becomes whether the architecture itself was meant to solve this class of problem.

Real-Time Sports Pushes You Into a Very Heavy Compute Architecture

Once you push splats toward real-time sports, you are no longer talking about a lightweight processing setup.

You are talking about a multi-GPU, multi-server clustered architecture that must move and process massive amounts of data with extremely low latency. You are likely in a world where GPU-direct data movement, high-performance interconnects such as InfiniBand, careful workload partitioning, and highly optimized orchestration become mandatory rather than optional.

That alone is a useful signal.

When a system requires that level of infrastructure just to approach the problem, it is worth asking whether the underlying approach was designed for the problem in the first place.

That does not mean research should stop. It means expectations should stay grounded.

Streaming Scales Too

Let’s assume, for the sake of argument, that the processing problem has been solved.

You still have to stream the result.

If one splat-based subject can be streamed at a certain bitrate, then two similarly complex subjects are likely to require roughly double the bitrate. Three subjects require roughly triple. Ten subjects require roughly ten times as much. At that point, the scaling becomes much more direct.

That is a major challenge for sports.

A team sport is not one subject. It is many athletes, plus objects, plus space, plus the need for viewpoint flexibility. So even if a single person can be streamed at an acceptable bitrate, that does not mean a full game can be streamed efficiently in a way that works for real products and real audiences.

This is one reason we think compression and distribution need to be part of the architecture from day one, not treated as something to solve later.

Level of Detail Is Not Optional

In a sports scene, not everything should be treated equally.

A player close to the virtual camera matters more than a player far away. A ball in motion may matter more than a crowd section in the distance. A foreground athlete likely needs more detail than an object at the far end of the court.

That means any practical sports system needs some form of level-of-detail strategy.

For more established graphics and geometry pipelines, there are already mature ways to think about reducing complexity. Mesh-based systems, for example, have a longer history of decimation, normals-aware simplification, angle-aware reduction, and other established workflows.

Splats are newer. That means level-of-detail strategies for splats are much less mature, especially if the goal is automated, scalable, real-time use in sports.

In practice, that opens up a whole new problem set. Which splats should be reduced? By how much? Based on what priority? Distance? Visibility? Motion? Importance? Perceptual thresholds? Temporal stability?

Even a simple example shows the challenge. If a model contains a million splats and you want to reduce it by 50 percent, there are many different ways to choose that 50 percent. Those choices do not all produce the same result. Some reductions may preserve quality well. Others may fail badly.

To automate that well at scale may require entirely new training data, new decision systems, and new frameworks around real-time level-of-detail selection.

And in sports, that is not optional.

Sports Also Raises the Frame Rate Problem

There is another important gap between how splats are often demonstrated and what sports actually requires.

A lot of splat workflows are shown in controlled or offline settings, where there is time for preprocessing, cleanup, interpolation, or post-processing. That is very different from live sports.

Sports is motion-heavy. Athletes move quickly. Objects move even faster. Motion blur becomes a serious issue if capture conditions are not right. Shutter, lighting, frame rate, optics, and exposure all matter. And once motion blur is baked into the input, it is not trivial to remove reliably in an automated way.

This matters because real-time volumetric sports needs clean input.

Thirty frames per second is already limiting for many types of motion. Sixty frames per second is better and should be considered a practical baseline for serious volumetric capture. But for many sports use cases, 120 frames per second is where things start to make more sense if you want cleaner temporal sampling and more reliable capture of fast action.

That changes the math dramatically.

At 120 frames per second, the system is dealing with a new frame every 8.3 milliseconds. If you want truly real-time behavior, the entire system has to keep pace with that cadence while handling all the camera data, scene complexity, processing, compression, transmission, and playback requirements discussed above.

That is not a small extension of the problem. It is a fundamentally harder class of system.

And that is why we believe splats, at least in their current form and typical architectural assumptions, are not a practical foundation for real-time sports.

Where We Think Gaussian Splats Do Matter

None of this means Gaussian splats do not matter.

We believe they do.

They are useful for pushing the industry forward in areas such as site surveys, 3D product capture, special effects, certain training scenarios, and controlled capture environments involving one or a small number of subjects. They may also continue to evolve in ways that improve efficiency and expand their role over time.

There will likely be strong one-off experiences built with splats. There will be impressive demos. There will be branded activations, music videos, introductions, holographic moments, and other projects where the economics are supported by marketing or promotional value.

That is real progress.

But those use cases should not automatically be mistaken for a solution to real-time sports at scale.

Why We Are Investing in a Different Path

At Skyrim.AI, we believe the future of sports volumetric media requires an architecture built for real time from the ground up.

That is why we have invested in Stadium OS for real-time volumetric workflows. It is why our Echo model is not based on Gaussian splats or NeRFs. It is why our Atlas platform focuses on compression and distribution. And it is why Relay is designed as a playback and SDK platform that can support everything from smart TVs to XR headsets and everything in between.

We do not see volumetric media as a one-off effect or niche demo category. We see it as a new media format. That means workflow fit, scalability, standards, compression, interoperability, and playback all matter from the beginning.

In our view, sports demands that full-stack perspective.

Final Thought

Gaussian splats are a meaningful and important part of the broader volumetric conversation. We respect the innovation happening in that space, and we expect it to continue contributing to the industry.

But for sports, especially live sports, we believe the harder truth is this: the problem is not just rendering quality. The problem is scaling capture, processing, compression, streaming, and playback together in real time.

That is why we chose a different architecture.

And that is why we continue to invest so heavily in Echo, Stadium OS, Atlas, Relay, and the broader infrastructure required to make real-time volumetric sports practical.

---

• Corridor Crew: “THIS is the Biggest Thing Since CGI” https://www.youtube.com/watch?v=X8yRlA7jqEQ&vl=en&utm_source=chatgpt.com

• Original 3D Gaussian Splatting paper / project page https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/