Polycubes as potential candidates for Universal Primitives of interoperable virtual objects
When you’re finished here, make sure to check out the rest of the articles from: The Universal Asset Framework Series.
What are polycubes?
Polycubes are the result of joining cubes — usually of the same size — face to face with one another. They’re like 3D versions of Tetris pieces. As we have been discussing in this series, we want to create a small amount of standardized blueprints (what we’ve been calling Universal Primitives (UPs)) for virtual objects that can represent as many potential interoperable objects as we want. I believe polycubes could be very helpful in this endeavor.
How objects in videogames work
People that are familiarized with how videogames work will likely know that items like weapons and armor usually come with something called a hitbox, usually a simple geometric shape surrounding an object (a character, a weapon, etc.) used to detect collisions between objects inside these virtual worlds, by detecting collisions between these hitboxes.
In fact the game itself only cares about this hitbox not what the actual asset looks like, all of the behavior of the asset is defined by a series of abstract properties and some physical properties of the hitbox (size, shape, etc.). We can use this to our advantage for creating universally interoperable assets, we can view the visual aspects of any interoperable object as merely a sort of virtual skin, that’s there for players, but which the game doesn’t care about. If these “skins” were invisible or absent the game would function just as well without them. It’s only players who care about them.
Therefore we can eliminate a lot of complexity in trying to figure out whether two different looking objects should have a different Universal Primitive (UP) by disregarding a lot of their visual characteristics. Most of the details of the object don’t matter, only its rough general size and shape, and when we say rough we mean rough, like what someone with heavy blurry vision impairment would see if they took off their glasses and started looking at things. The key question is, how rough we want it?
In essence what we’re trying to do is create a series of standardized boxes, and try to fit any potential future or present assets we want to be interoperable into one of these boxes. The more boxes we have, the better fit there will be between any given item and its box (less rough), but this hurts interoperability, since given how we’ve set this framework world-builders need to integrate these boxes ahead of time when building worlds, and its likely that having to integrate thousands of different boxes wouldn’t be practical, meaning most worlds would only allow you to import a very reduced amount of interoperable objects from other worlds into them, which would go against what we’re trying to achieve, maximizing interoperability of assets. Too little boxes however, and all items seem to behave in the same way, killing the nuance between them.
Just like goldilocks, we want the right amount of boxes, as small a number we can get away with for any desired type of asset, but with an enough amount to account for differences and some nuance. For example, we wouldn’t want a small knife to share the same Universal Primitive (UP) and therefore properties and behavior with a two-handed greatsword. So we need a way to determine how many boxes per type of asset we want to have.
Polycubes to the rescue
Polycubes have very nice geometric properties, they’re simple, symmetric, and most importantly composable. We can build new shapes out of these cubes by gluing them together. Depending on the size and number of cubes we glue together, we can get very intricate or simple shapes. Given that we’re trying to simulate something that looks roughly like what typical hitboxes of items in videogames do, we will want only a few big bulky cubes glued together. Probably 5–15 cubes at most, each of a size roughly of that of a fist, or a human head. Something within that range, not much more bigger or smaller than that.
Now instead of worrying about the visual aspects of an object, we simply make these simple polycubes be their Universal Primitives (UPs), that is to say, any interoperable object must be represented by a particular polycube, in other words, whenever we want to create an interoperable asset, our first step is to choose the UP of that asset and therefore the corresponding polycube associated to that UP.
Only later we import the 3D file of the asset. This is why we make a separation between the terms Universal Primitive (UP) and Universal Asset (UA). A UP is simply a polycube with some additional properties and no visual representation or skin. A Universal Asset (UA) is the resulting asset of combing the 3D file of an object with a suitable UP. These polycubes do impose some restrictions on the associated 3D files we associate to them (the visual representation of these assets), but these are mild constraints, such as their size (must fit inside the volume of the polycube) and orientation (for example, where the handle to grab the item might go). We don’t say anything more about how they must look.
This gives great flexibility to creators, they can create an asset as complicated, intricate, or beautiful as they want, all we ask of them is that they fit nicely inside one of these standardized polycubes/ boxes. The visual aspect of any interoperable object — for the most part — need not be limited in order to maintain interoperability. Of course, it’s to be expected that a separated standard for how to render 3d files of objects inside virtual worlds will form in due time, but this has nothing to do with our framework and our primitives, it affects what the 3d file we associate with an interoperable object can be when creating a UA, but as mentioned previously that’s not relevant for the functionality of the asset (the UP).
For weapons it’s easy to see how polycubes might work. For more complicated items such as armor, we might need to resort to more complicated geometric shapes, but the philosophy remains unchanged. Now the real question becomes, how granular do we want to be? How many UPs do we want to have for a given type of virtual object? Nonetheless, we now only need to work with much simpler things like polycubes, instead of trying to figure out if we need 50 different boxes for 50 slightly different-looking Katanas.
We need to create potential sets or families of polycubes. And then check the effects in practice of putting any interoperable virtual object into these boxes, how they affect actual gameplay, and reassessing whether we need more boxes per class of item to increase fidelity, or if we can get away with even fewer. This is just one potential avenue, but it helps to see how we might achieve the seemingly daunting task of taxonomizing every potential interoperable virtual object we want to create, into a much smaller amount of simple boxes.
This however remains a very flexible system, with time we can always decide to create and support a bigger amount of UPs, as technology advances and supporting hundreds or thousands of UPs per world becomes viable. But we probably only need to start with a few dozen.
Final remarks
Another way to view these UPs made of polycubes is as a sort of digital skeleton for 3D files. In principle we should expect any in-game asset to have their own digital skeleton. In this other article you can read more about why we need such digital skeletons to achieve true Metaverse interoperability: Digital skeletons, as a solution to the Metaverse interoperability problem.
