Skip to main content

Building Bridges

with Real-Time Data and Unreal Engine

| Matt Merryfull |

TL;DR – A Hackathon Recap

We set out to prove that Unreal Engine can be more than a rendering tool—it can be a live, integrated node in a real-time digital ecosystem.

In just a few days, we:

  • Prototyped a WebSocket-based sync layer connecting UE with a web UI (Google Maps) and .NET backend using MassTransit + AWS SQS.

  • Used Cesium for UE to build a 3D twin of the real world.

  • Demonstrated two-way communication, not just visualisation—allowing interactions from and to UE.

  • Skipped auth (for now) to focus on real-time viability and cross-system collaboration.

  • Explored how SpacetimeDB’s timewarp unlocks “experiential analytics”—revisiting moments in time spatially.

We also leaned into a cross-disciplinary team model, where engineering and technical artistry collaborated closely—proof that diverse perspectives create richer solutions.

This wasn’t about shipping production code. It was about momentum toward something bigger – BRAID-like 🤓, if you will.


Foundations are everything…

At Neon Light HQ here in Sydney, we recently ran a focused internal hackathon aimed at solving a deceptively simple but expansive problem: how do you synchronise Unreal Engine (UE) with other platforms in real-time – and in a way that’s extensible, scalable, and meaningful beyond the confines of game development?

The goal was to prototype a WebSocket service that could shuttle data back and forth between UE and external interfaces, making UE not just a rendering endpoint, but a participant in a broader digital ecosystem.

We landed on a three-tiered architecture:

  • A .NET Core backend acting as an intermediary layer, built using MassTransit for message orchestration and AWS SQS for queueing and fan-out

  • A React web interface that displayed contextual overlays via Google Maps.

  • A Cesium for UE setup rendering a rich 3D digital twin of the real world (this is almost trivial these days – so big thank you to the team over at Cesium).

The intent? If a user clicks something in the web interface, a WebSocket event fires to UE. UE responds with spatial context or 3D metadata. And just as crucially, if UE detects a spatial interaction (e.g. an object selected in-world), that event fans out to web dashboards, logs, and notification systems.

This may sound modest, but the core principle flips a common pattern on its head. Most integrations (Bentley Systems, for instance) are read-only. Data flows into the visual system but not out. We’re proving that the loop can – and should – close.

It’s not that these systems don’t have the capability, the desire just hasn’t been there, until now.


Why It Matters

Most of today’s visual-based workloads – spreadsheets, reports, PDFs – exist in ecosystems that sit around spatial engines, not within them. And while tools like UE Datasmith help ingest content into Unreal, they don’t help facilitate collaboration or insight generation from inside the experience – realistically, that’s not what Datasmith or UE was designed to do.

We believe that real value comes when spatial platforms become expressive interfaces—not just canvases.

Think: stakeholder walkthroughs that generate insights, not just impressions. Engineers observing user focus patterns. Designers iterating based on behaviour, not assumptions. Expand this use case through to future governance and the digital twin interface and you’ll see where our team’s collective minds are travelling toward.

This is why one of our next moves is incorporating SpacetimeDB, a time-aware database that unlocks ‘timewarp’ capabilities. Users and systems will be able to query what was happening, who was there, and what was seen at any point in the spatial timeline. It’s experiential analytics without the friction—impressions captured passively, insight drawn actively.

On Security, Teamwork, and Realities

In the interest of velocity, we excluded an authentication layer. Not because it’s not important – it is, especially for security and multi-tenant setups – but because the goal of this hackathon wasn’t polish, it was potential. We know auth is a critical next step for any real-world deployment.

Equally critical to the hackathon’s success was our interdisciplinary team. Neon Light’s DNA isn’t just code; it’s artistry, engineering, experience, and storytelling. In this sprint, we saw technical artists collaborate with engineers, ops folks challenge assumptions, and designers stretch the boundaries of what the toolset was originally built for. That shared intent – the idea that collaboration is the actual outcome – was more valuable than any single feature we shipped.

Looking Ahead

As we step back from this experiment, it’s clear we’ve only scratched the surface. The addition of pub/sub queues – using MassTransit via C# and .NET with AWS SQS – enables a fan-out approach to event handling, allowing decoupled services like notifications, AI processes, reporting, and data-lakes to react asynchronously to system activity. This de-centralised approach offers scalable pathways to expand workloads and capabilities without overloading the core systems.

Equally compelling is the opportunity presented by SpacetimeDB’s timewarp feature. It introduces a novel concept in experiential analytics: the ability to revisit specific moments in a shared 3D environment and extract insights without interrupting or distorting the original user experience. Imagine stakeholders being able to explore what was viewed, when, why, and for how long – without intrusive data capture or forced interactions. It’s a subtle but powerful shift: analytics that respect the flow of experience while enabling deep reflection later.

a powerful shift: analytics that respect the flow of experience while enabling deep reflection later.

This prototype, while small in scope, is a key step toward a broader connected ecosystem. While we held off implementing authentication for now – given the short hackathon window – we fully recognise its role in enabling secure and scalable infrastructure for real-world deployment. Similarly, the discussions and cross-domain collaboration that fuelled this build are just as important as the technical outputs. The blending of software engineering and technical artistry created a feedback loop of ideas that shaped not only what we built, but why we built it.

We’re treating this not as a standalone exercise, but as a foundational thread in a broader tapestry – one that will weave into larger platform ambitions. This includes improved interoperability, new collaborative workflows, and real-time digital experiences that extend across disciplines and industries. As we refine these concepts and begin incorporating persistent state layers, we’re opening the door to meaningful partnerships, scalable implementations, and new ways of engaging with the digital world.