In a previous post, we looked at how NFTs are not ready for the 3D Metaverse. The main reason - we do not have a standard path for the 3D asset to be defined, as we do with PNG or JPG-based NFTs.
An NFT itself is a small record on the blockchain. As we broke down in another post, information about the media stored in the NFT is held in its metadata.
For a PNG or JPG, we store the path to the actual file under the image property in the NFT’s metadata. 3D assets also need an image rendition, along with one or multiple 3D file type renditions. Where to put them?
The official ERC-721 spec defines an optional metadata section but does not go beyond name, image, and description for suggested values.
Here’s what OpenSea suggests for metadata:
It looks like animation_url is the leftover grab bag for a huge variety of file types, which includes 3D file types along with entire HTML web pages. This variety makes it impossible for a Metaverse to know what to expect when it reads an NFT’s metadata, or how to guarantee it can find the 3D file.
METAVERSE_URL
With the options lacking, it seems we need a new property for the 3D Metaverse. The word Metaverse is overplayed already, but it has a beautiful origin in Snow Crash, and we should keep things easy and stick as closely as possible to its original definition. A Metaverse is a 3D virtual world.
metaverse_url - A URL to the asset that an NFT should be represented as in a Metaverse.
This property can be either a string value or a dictionary. As a dictionary, we can store any file type renditions of that 3D asset - glTF, glb, FBX, OBJ, USD. The 3D world is messy, but a strongly typed list of supported types will let applications know what they are getting and where to look for it.
Example as a string:
metaverse_url: "https://spatializes.com/myavatar.glb"Example as a dictionary:
metaverse_url: {
glb: "https://spatializes.com/myavatar.glb",
gltf: "https://spatializes.com/myavatar.gltf",
fbx: "https://spatializes.com/myavatar.fbx",
obj: "https://spatializes.com/myavatar.obj",
usdz: "https://spatializes.com/myavatar.usdz",
usd: "https://spatializes.com/myavatar.usd",
}Preference should be glb (the binary version of glTF), for faster loading over the network and of its buffers into memory.
ANIMATION
When a Metaverse imports a 3D model, each model may have its own animation data set up internally. If not, we won’t be able to do things like walk, run, or attack! Static models are much less fun.
Following the standards set up by templates in VoxEdit seems like the best path forward at this point. VoxEdit is currently the easiest way to model and animate 3D assets that I’ve found so far. Compatibility with the Sandbox will help interoperability.
Assets should have at least the following animation channels to allow for a base set of interactivity:
Idle
Walk
Run
Jump
Climb
Attack
Die
With just this small set of animation channels, Metaverses can implement a wide range of functionality. As a Metaverse, on import, we can scan for animation channels that contain these strings. These might be humanoids, creatures, or even more static objects like turrets or buildings (which might also have the ability to attack or die).
This list should continue to expand as we find greater use cases for assets in the Metaverse, but a short simple list to start will be helpful.
Projects adopting this new metadata and model structure will give us a much greater chance of building an open, interoperable, and standardized Metaverse.