Meta Layers in Spatial Computing

TexasGreenTea
6 min readJul 29, 2020

You’ve heard the term “Metaverse”. You’ve heard people say “that’s so meta”. Philosophy has used the term “metaphysical” for generations. Before we start sorting through definitions, I want to stress that my goal here is to create clarity, but I fear everything I’m about to write is destined to do the opposite. Oh well. Down the rabbit hole we go.

In spatial computing, we have a concept called a transform. It defines spatial context for a single object. It almost always defines position, rotation, and scale, and sometimes a few other things like volume or surface area. Basically, everything you need to know about how this object exists in space… is the purview of the transform component.

When you have access to transforms, you have the ability to put everything in space. You have suddenly achieved spatial context in a digital world. We’ve been doing this in video games and film graphics for decades, but we’ve only recently begun doing it for all other applications. When my team did it for Spotify last year, we ran into a lot of interesting challenges, but making everything spatial is actually quite addictive, and here’s why:

You can’t help but begin thinking about everything that exists in the digital world as having a spatial context, once you’re given that capability. Since everything you’ve touched, seen, and heard in the real world has a spatial context, you naturally hunger for the same to be true for all digital content. This is why we find ourselves wanting to attach components to these transforms.

In a game engine, everyone does this with all of their objects. In fact, it’s difficult not to. Game engines are built to encourage you to do this all the time:

Not that this should change. It’s fine most of the time. But transforms are the basic unit that defines space. They’re like powerful magnets for the rest of your code. Once they exist, we want to hook everything to them, to ground everything in space. Every variable, every function, and every object ends up claiming some association with a transform. We want all the data to not just exist, but to exist “somewhere”. It’s no longer enough for it to be located in some memory address we’ll never see with our own eyes. We want to use our built-in human senses to access the location of all the digital things.

In a game engine, when data and behaviors exist, but they don’t claim any space, we’re confused. We shy away. This comes from our experience in the real world. Many people believe in metaphysical things like spirits and Gods, but these things often cause us confusion because we can’t pinpoint where they are, how big they are, or how much energy they can produce. The mystery of it inspires both awe and fear.

But in a digital world, we’re the ones in control. We get to say whether the things are in-space or not-in-space. We usually opt to put them in-space because it comforts us. It’s actually much less performance-optimized to do so in many cases, but it makes the objects feel more real and that has “better” written all over it, according to our subconscious instincts.

That said, we know that it is not only feasible, but sometimes much easier, to define data and behaviors without needing to associate them with space. In game engines, we do this merely by refusing to connect a class to any given transform. If it doesn’t claim a transform, it is by definition a non-spatial object.

It’s fun to consider the entire history of computing this way, because almost all apps and programs written in the 20th century are non-spatial, so they’re like the spirits of the digital world, floating around before objects had bodies in space. Is that meta enough? I’m just getting started.

If the digital world has a spatial layer, then any classes that don’t claim association with a transform would be in a layer beyond that by default. They don’t take up space, but they exist. Therefore, they are metaspatial.

But hold on. If you consider a digital world that has space, it’s already meta, isn’t it? It’s not physical. That’s why we call it the Metaverse.

True enough, but there’s a layer to the Metaverse that we haven’t named yet, as far as I know, and it’s already becoming a wrench in the gears of spatial devs. Maybe university professors are already subdividing this concept into dozens of layers none of us have heard yet, but I don’t want to talk theory.

I’m interested in practical application. I build spatial computing applications for a living, and I’m always on the lookout for terms that accurately convey the meaning of common structures. It feels as though we’re approaching a moment where industry needs a name for at least two layers of the Metaverse:

  • a layer that has spatial objects
  • a layer that has non-spatial objects

For lack of knowledge of any such existing distinction, I’m calling those layers spatial and metaspatial respectively.

Let’s hop back up out of the rabbit hole and track how many metas we’re dealing with here. In the Metaverse, there are objects that take up space and objects that don’t. We’re already one meta deep, one layer removed from the physical world. And now we’re talking about subdividing that using the prefix “meta” again, a second tier of meta-ness. The objects that take up space in the Metaverse are spatial. That term is already widely accepted in industry. But there’s no term yet for those objects that don’t. I like the term metaspatial for those, but I’m open to suggestions.

This may not seem relevant if you don’t work in spatial, but every project I’ve been in for the past few years has struggled to draw a clear line between spatial and metaspatial objects, sometimes needing both but not realizing it. In fact, some developers will recommend that you NEVER use metaspatial objects in a game engine. This usually comes in one of these forms:

  • “NEVER USE STATIC CLASSES”
  • “NEVER USE SINGLETONS”

These are two common examples of how to create metaspatial objects in code. For you programmers out there, you may find it odd that I’m calling static classes and singletons metaspatial, but that’s often what they are. These structures CAN exist in space, but they often don’t need to and are often intended not to. They can be quite powerful and quite dangerous in a game engine, the same way spirits and Gods can be quite powerful and dangerous (if you believe in them) in the real world.

I believe we’re approaching a time when our spatial computing architecture will need to clarify the relationship between digital objects that have space and those that don’t. It will be difficult to navigate those waters if we don’t have a name for each of the layers. So what do you think about the terms spatial object versus metaspatial object? Got a better name for it? Let me know!

--

--

TexasGreenTea

Prototyping Engineer/coder/UX designer, former Magic Leap & Technicolor — prior work: lead dev on Spotify launch on ML1 — now working on spatial text entry