3d model NFTs

nft-models.md

3d model nft proposals

Core parts:

token json

Should include a link to the low resolution and high resolution models.

low resolution vox model

The 3d model should include a low resolution .vox model standin that can be used when rendering the nft from far away. A gallery or store may have dozens of NFTs in them, and so we need a way to render a representation of the NFT as high speed with a single draw call. .vox models, which can be freely loaded in most engines, and are rendered using no textures, but using simple vertex shading, are a good opportunity to render a stand-in for the model. I recommend adopting a maximum size of 32x32x32 in this .vox model

gltf high definition model

The nft may have a high definition model in gltf. This model should be able to be displayed on a medium spec android phone. I'm not sure what the limits should be, maybe around 10k faces, 50 draw calls (so limited number of materials). It won't have any shaders but use PBR materials. A game that is displaying the model should switch from the low res .vox model to the HD gltf model when the user leaves their mouse focussed over the model for a few seconds.

interaction with models

When a user interacts with the model, games should display a summary of the information in the token json. This includes rarity, description, information about the collection the model is in etc. Scripting / animation of the models is beyond the scope of this gist.

For LOD, Microsoft published a GLTF extension: https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/MSFT_lod

I'd be wary of baking too much Microsoft cruft into any new standards (MSFT_lod relies on MSFT_screencoverage).

I strongly agree that specifying as little as possible is good. Treat the tokens as media containers, MPEG-style, and let different platforms support different model formats as needed.

Alongside that, CryptoVoxels can document a well-defined standard for voxel models in .gltf that can be converted on the fly to .vox for use in CryptoVoxels or rendered as-is elsewhere.

+1, the MSFT_ extensions (and, similarly, some GOOGLE_ extensions we haven't published) are used internally at our companies but not particularly meant for wider implementation. I would recommend treating a single glTF as a single LOD, and any LOD-switching logic can be handled at a higher level of abstraction.

Also — a quick plug — we're considering an (official) extension to glTF for GPU instancing, which might be relevant to voxel-based scenes. Feedback on KhronosGroup/glTF#1691 would be welcome.