As a student, I spent a lot of time reading about past conflicts and events, but I often found myself frustrated. I could flip between pages of maps covered in multicolored arrows yet still struggle to understand how that felt on the ground. Modern GIS tools are far more powerful, but even a Web Scene is a diagram for conveying information rather than establishing a feeling of presence in time and space. So I set out to build a different kind of digital twin, harnessing a game engine to capture not only a physical place but the sense of being there and of the events that played out there.
This creates a different class of challenge. To establish the workflow, I chose a rugged, non-historical landscape covering 19 × 19 km as my proof of concept.
Defining the Experiment
Esri offers software development kits (SDKs) for the two most popular game engines, Unreal and Unity. I chose Unity as it is generally less taxing to run, easier to learn, and also the leading choice for XR development. As a student without access to a large support team, and designing for users without high-end hardware, those considerations mattered.
I selected the Snowdon massif (Yr Wyddfa) as my test bed in Wales—not only for its striking topography, but because my own backpacking experience there provided a vivid memory to test the simulation against. I set two strict design constraints from the beginning: the project must run entirely offline (for performance and resilience) and must use the British National Grid (EPSG:27700). This avoids the distortion inherent in Web Mercator, prioritizing local spatial accuracy over global streaming.
Figures 1, 2: The study area: The historic Dinorwig Quarry, situated in front of the wider Snowdon massif. The complex, terraced topography provided a rigorous test bed for the ArcGIS Maps SDK, utilizing Unity's lighting and rendering capabilities to create a sense of scale and presence often lost in traditional web scenes.
Lessons Learned Along the Way
The process highlighted several technical hurdles that are worth sharing with other Educators and Students.
The first was the importance of perfect alignment. My 10 meter land cover raster data naturally suffered from 'stair-stepping' at forest borders. At first, I tried smoothing the data, but the real problem turned out to be more fundamental: a subtle mismatch between the clipping boundary and the underlying pixel grid. Standard GUI tools like Raster Domain often leave tiny half-cell gaps. On a traditional map, these are invisible. In a digital twin, they break everything. I ultimately solved this by stepping outside the GUI and using ArcPy to generate a mathematically precise boundary, ensuring that every subsequent clip aligned perfectly.
The second lesson was a classic “garbage in, garbage out” moment. In ArcGIS Pro, setting layers to “On the Ground” visually snaps features to terrain, but this is only a display property. When I exported the data to Unity, trees floated above the surface or sank below it because the elevation was never actually written into the geometry. The fix was to use the Interpolate Shape tool to bake elevation values directly into the features before export.
Figures 3, 4: Precision in practice: A view looking west into Bwlch Llanberis (Llanberis Pass) from Pen-y-Pass. By adhering to the British National Grid (EPSG:27700) rather than Web Mercator, vector features like the road align perfectly with the valley floor without the need for manual adjustment.
Staying GIS-First
Before moving to Unity, I should note another voluntary constraint or scope limitation I took on for this project. I wanted to see how far a GIS professional could go relying only on their existing ArcGIS expertise, minimizing the need to learn game development logic (C#) or proprietary Unity tools–trying out the “low code/no code” approach, essentially.
The ArcGIS Maps SDK consists of two tools. The ArcGIS Map component handles precision location and coordinate rebasing. On its own, it can support workflows where all terrain and layers are manually exported and re-tiled for Unity. However, building a 20 × 20 km digital twin at 1-meter resolution this way would normally mean managing dozens of terrain files, often with third-party tools.
Using the Map Creator instead allowed me to import large areas directly from ArcGIS Pro as single files, with no additional software. For students or small teams working without specialized pipelines, this dramatically changes what is feasible.
Tradeoffs and Constraints
These benefits do come with tradeoffs. Because the ArcGIS Map component enforces real-world coordinate systems and periodically rebases the Unity world origin, many Unity shaders and asset-store tools—which assume a simple Cartesian space—do not work out of the box. Bridging this gap sometimes requires C# scripting, which can feel very different from working with ArcPy. While this wasn’t a hard stop, it did mean resetting expectations about how easily third-party Unity tools could be dropped into an ArcGIS-driven scene.
The Map Creator also imposed the most significant limitation I encountered. My original plan was to import terrain height, apply an imagery basemap, and then “paint” high-resolution materials—grass, rock, dirt—onto the surface using Unity’s terrain tools. This technique, known as splatting, produces highly detailed landscapes with relatively low performance costs.
However, the terrain as delivered by the Maps SDK is a Tile Layer (Tile Layer Package, TPKX), or for online projects, an Image Service. From Unity’s perspective, this is just a texture—not a paintable terrain surface. As a result, close-up views remain limited to the resolution of the imagery, which can look blurry at ground level.
This forced a shift in approach. Since the Map Creator imports terrain as a static texture (TPKX) rather than a paintable surface, I had to rely on vector-derived Scene Layer Packages (SLPKs) for details, as these are paintable. While it would be impractical to cover an entire landscape this way, SLPKs work extremely well for features like roads, buildings, and water bodies. These elements naturally draw the eye, and Unity’s water materials, in particular, add a surprising amount of realism through light reflection.
Figure 5: The visual impact of data types: The raw TPKX texture (top) represents water as a static dark surface. By substituting it with a vector-derived SLPK (bottom), the scene utilizes Unity’s lighting engine to create realistic reflections, even without complex shaders.
Why this Matters
Even while limited as one individual by time and lack of Unity experience, I can't help but get excited at the potential this demonstrates. The lighting alone adds immensely to the sense of place, and the responsiveness of movement and instant resolution of textures and objects creates a presence far beyond what ArcGIS on its own could do in a Web Scene. The fact that everything runs offline also means the experience is persistent and resilient—no network connection required.
For anyone considering a similar path, the “garbage in, garbage out” principle cannot be overstated. Unity’s accessibility is a double-edged sword. It’s easy to create something quickly, but quality still depends entirely on the care taken with data and design. Many critically acclaimed games run on Unity; the engine itself is not the limitation.
So why should game developers have all the fun? GIS professionals already curate and maintain incredibly detailed representations of the real world. We don’t need to invent new worlds—we have one waiting to be explored. With the ArcGIS Maps SDK, the analytical “brain” of ArcGIS finally gains the “hands” needed to build truly immersive digital twins.
As for me, this project is just the beginning. My long-term goal is to create rewindable historical scenes where users can move freely, pause events, jump through time, and observe conflicts from any perspective. For students interested in history, geography, or spatial storytelling, this combination of GIS and game engines opens up an entirely new way of learning—and experiencing—the past.
Figures 6, 7: Fog and mist ("volume" in game engine terms) create a visceral feeling of place. Comparing the digital twin with the real site validates the landscape's scale and atmospheric depth, even as the procedural weather varies from the specific moment in the photo.
I'm happy to exchange ideas on the workflow used for this project or to discuss the broader challenges of creating digital twins in real-time environments. If you are working on similar problems or just want to connect, feel free to reach out!
Esri Community
