Make wearables way more awesome

[madjin]

Metadata is currently centralized

{
  "name": "GoldenSword",
  "image": "https://wearables.sfo2.digitaloceanspaces.com/1d83521d-e9c2-4d9f-bc69-862ac82b588a-goldensword.gif",
  "description": "One of the first swords minted for cryptovoxels!",
  "attributes": [
    {
      "trait_type": "vox",
      "value": "https://www.voxels.com/w/abd4effa1479f0a8f0072da0f22928e9fb1bad42/vox"
    },
    {
      "trait_type": "author",
      "value": "Bullauge"
    },
    {
      "trait_type": "issues",
      "value": 8
    },
    {
      "trait_type": "rarity",
      "value": "legendary"
    },
    {
      "trait_type": "suppressed",
      "value": false
    }
  ],
  "external_url": "https://www.voxels.com/collections/eth/0xa58b5224e2fd94020cb2837231b2b0e4247301a6/1",
  "background_color": "f3f3f3"
}

All the vox files are about 133MB total which is very affordable to store on arweave or IPFS

Make better previews

The preview image gifs average around 1.2 MB and the magicavoxel format .VOX is not a standard file format so it does not preview properly on Opensea.

Some ideas:

1. Convert each wearable to glb so that the preview can be a 3D model and the wearables can work in more places

• https://svox.glitch.me/ - smooth voxels 1.2.0 main website
  • https://svox.glitch.me/playground.html - demo
• https://github.com/jel-app/smoothvoxels - faster / more optimized version

2. Export and mint WebXR site

Smoothvoxels supports many types of export options, the A-Frame javascript export options in the playground support all material types unlike the gltf / glb export (see beginning of documentation): https://svox.glitch.me/

[madjin]

Some wearables were saved with different versions of magicavoxel, this could be an issue later on

2609.vox is an example that didn't upload in smoothvoxels

[SamuelVanEgmond]

Hi Madjin,

you mentioned problems in your mail as well, but 2609.vox is actually a corrupt file (0 bytes).
Do you have other examples?

Just for my understanding (I'm not versed into CryptoVoxels), am I correct in assuming you just want to use Smooth Voxels to preview the .vox files in all their voxely splendure and not actually smoothing them like so?

Samuel (Original Smooth Voxels author)

[madjin]

That looks beautiful.... 💯

I wanna convert all the vox files into smooth vox and export HTML previews, batch process everything basically.
Got tons of example files here: https://github.com/madjin/Cryptovoxels-VR/tree/master/wearables/vox

Didn't know some files were corrupt, I wonder if there's a way to scan through all of them and check

[SamuelVanEgmond]

Batch processing to export is the difficult part, that will automatically also tell you which files are corrupt.

I can imagine something like https://github.com/gftruj/electro-aframe (haven't used it myself) combined with some code from the svox playground for the MagicaVoxel conversion and the svox library itself should get you a long way to generating the preview. But I'm not sure if you can then actually batch save all the output files.

A live preview would be easier (and way cooler), but I'm assuming you want to show a list and I'm not sure how many live previews on one page would start breaking peoples browsers.

[madjin]

Oh wow just realized I have 633 0 byte vox files in this dataset, thanks for noticing gunna look into that first

[SamuelVanEgmond]

Alternative to serverside rendering: Create a client side application using the svox MagicaVoxel conversion that loops over all vox files, converts them, show them in A-Frame, get the base 64 image data (convert the A-frame screenshot component to get the data instead of saving the file) and then post all images as base 64 to a server to store. That circumvents the whole server side rendering part.

[gfodor]

Yep I was thinking vox2svox and svox2gltf (and maybe svox2vox) would be great standalone binaries to create. (With switches for compression, and if to add deform by default, etc) You’ll need to get it running in node but probably not too hard. I’m working on carving out the parts of the playground that seem generally useful (vox/gltf/generate) into core in my fork, so will let you know if I get node working. I’d like to make it so you can run these operations in a cloudflare worker in addition to command line, but not sure if I’ll get that far.

fyi this can be used to make an executable:
https://www.npmjs.com/package/pkg

[SamuelVanEgmond]

Ah yes, extracting the reusable parts of the playground, another thing on my todo list I never got around to :-)

I also wanted to do the svox2vox, but never found a library that did svox writing and I didn't want to spend my time there.

[gfodor]

Yep, makes sense. I've never written VOX export either, just import.

[gfodor]

wrt vox2svox was thinking interface like:

vox2svox [-c <on|off|auto>] [-f] [-a [ao settings]] [-d <deform settings>] [-s <shape>] [-l <smooth|both|flat>] in.vox [out.svox]

Converts a the specified vox file to an svox

-c Compression mode (on = always compress, auto = compress if output is > 16k bytes (?)) (default: auto)
-d Apply deform to all materials
-l Apply lighting model to all materials
-f Apply fade to all materials
-s Apply shape to model
-a Apply AO (default settings X X)

Unless output file is specified, svox goes to stdout

Could also add additional switches obv but these seem the most important

[SamuelVanEgmond]

That would be a node application, right?

Even though I always write them under each other, the model settings can also be comma separated like so:
model size = 5 32 9, scale = 0.03, origin = -y, ao = 2 1

So you could perhaps do something like this for maximum flexibility:

vox2svox [-c <on|off|auto>]  in.vox [out.svox] [-mod <model setup>] [-mat <material setup>]

where <model setup> is scale, aosamples, aosides, origin, shape, etc. (only size should not be allowed)
and <material setup> is type, roughness, metalness, ao, warp scatter, etc.

[gfodor]

oh I forgot it will be a single material. yeah an open-ended format like that is probably smarter. especially because it can just pass it through making it so there's no work to be done to upgrade it to new features.

[gfodor]

and yes it would be nodejs

[gfodor]

I’ve got this mostly working - should have it released tonight hopefully

[gfodor]

OK! This is released: https://github.com/jel-app/svox-tools

[karpatic]

I experimented with opensea's metadata using wearables. Use whatever you'd like:

Opensea page:
https://opensea.io/assets/matic/0xc930d370c971f4679e03106d3714eef4100d8fbe/4

Uses this metadata:
https://www.charleskarpati.com/api/feelsgoodgoods/4.json

Which visualizes the wearable using threeJs using this client-side code:
https://www.charleskarpati.com/api/feelsgoodgoods/4_duck.html

1. When the A-Frame is exported from the svox application, is the model Vox or SVox?
2. Making better opensea previews for wearables requires updating the wearables contract to have it's metadata pointing to your new serviceable endpoint. Does anyone here have the authority to do that for this collection?
3. There is no need for anything beyond a simple file server w/ the example above. But IDK what the intentions of the group are so apologies for coming in hot.

[SamuelVanEgmond]

Answer on question 1.: When you export to A-Frame from the svox playground you get a piece of javascript code, which is an A-Frame component with the complete mesh of the model (i.e. arrays with vertices, normals, colors, etc.).
So the answer is: 'Neither Vox nor SVox, only A-Frame'. (But the code can be stripped to be used in Threejs as well).