Digital facets.
Forever enduring,
fully on‑chain.

Step 1
In the rough

My initial exploration began with a read-through of the glTF 2.0 Specification. After getting an understanding of the basics, I started writing glTF files by hand, leveraging the fact that glTF files are JSON documents, which are human-readable and straightforward to author manually.

The first manual shape I made as a handwritten glTF file

After discovering that OpenSea uses Google Model Viewer to handle the display of glTF data, I wrote a small web application to display the results of my experimentation. This allowed for the rapid iteration of ideas and verification of rendering without requiring any contract to be deployed to a testnet.

A tetrahedron constructed via code instead of handwritten .gltf

Phase 2
Cutting teeth

After gaining some confidence in my ability to generate and display glTF data, I began experimenting with physically-based rendering (PBR) materials. The metallic-roughness PBR material is the only material directly supported by the glTF standard. But after experimenting with various parameters I wasn't fully satisfied with the appearance of the gems.

Demo gem shapes and the initial PBR material seen here – PBR materials have an RGB color, metallic, and roughness parameters

More digging revealed a wealth of glTF Extensions, many of which are supported by three.js – the underlying rendering engine that powers Google Model Viewer. babylon.js is another popular renderer that also supports many glTF extensions.

Implementing a subset of these extensions drastically improved the fidelity of the gem materials and brought them in line with my vision for the collection.

The webapp was updated with some dynamic controls, and proper transmission is now occuring through the gem surface

Separate interior & exterior materials complete the transmission effect. Exploring attenuation and iridescence parameters.

Once I had settled on some promising material design, my focus shifted to creating harmonious and well-proportioned gem shapes. My inspiration was a mix of classic geometry, table top role playing, and gamer culture.

These schematics helped me visualize the appearance of gems in 3D space, and also define the spacial relationship between vertices

Translating the vertices to 3D space definitely took time, but seeing the early results was incredibly motivating.

An early version of the Classic cut in the web app

Phase 3
Shine in the sky

As I continued to model and examine various gem shapes, I repeatedly encountered a frustrating issue: quads. Many of the shapes I envisioned naturally included non-triangular faces.

To save space and keep the contract bytecode small, I used mesh quantization, describing vertex positions with 1-byte integers per axis instead of the default 4-byte floating-point values. This limited the values to whole numbers ranging from -128 to +127. Unfortunately, a side-effect of this quantization was that visually-distracting “seams” could appear in the model without very careful attention and design.

Seams in the quad faces were not visually pleasing

To eliminate this issue, I had to rework all of my gem designs from the ground up. Problematic quads were everywhere! Their vertex positions were “close enough” to planar when snapped to integer locations but needed to be perfect to avoid artifacts. So instead of constructing gem shapes in three-dimensional space and then truncating their vertices to the nearest integer positions, I had to reimagine their construction as being edge- or face-based.

I created very short unit-like vectors to dictate the directions of edges in the model, which could then be combined in integer multiples so that non-triangular surfaces could still be described without rounding errors. It was a very careful and arduous process to rework each shape, but I believe the pleasing visual results were worth the effort.

Revised gem geometry took ages to complete, but looks clean and refined

Phase 4
Solidly polished

With both the geometry and materials finalized, I began implementing the logic in Solidity. Despite being a more experienced Solidity/Yul developer since completing the PURE JPEG project, porting the generative logic to Solidity was still fraught with challenges.

Compressing the gem shapes, material properties, traits, pseudorandom behaviors, and SVG output into a single contract required immense effort. I packed everything imaginable into byte arrays to ensure the highest possible compression and to avoid exceeding the EVM stack depth limits.

In one case, I resorted to using one byte as a bitfield to control several parameters related to axis reflections to save space. Every byte counted, so it was a seemingly endless battle to drop the contract bytecode size below the EIP-170 limit of 0x6000 (24,576 bytes). Even with compiler optimizer settings focused entirely on reducing contract size, the Genuine contract weighs in at 99.9% of the allowable bytecode size.

Q: Is the NFT on-chain?

A: Yes – the NFT metadata, glTF model, and SVG image are all generatively produced by the contract with no external dependencies.

Q: Can the gems be rendered outside of the EVM?

A: Yes! glTF stands for Graphics Library Transmission Format and is a widely supported, interoperable format designed to be the “JPEG of 3D”. It is a straightforward process to pipe the glTF output of a Genuine gem model directly into web browsers, game engines, 3D rendering pipelines, and so on.

Q: Why can gems look slightly different on OpenSea?

A: The careful observer may notice that some gems do not look 100% identical when comparing this site to OpenSea. The reason is that gems with the “Magic” trait make use of a very recent glTF extension called KHR_materials_dispersion. Both three.js and babylon.js support this extension, but the latest version of Google Model Viewer defaults to an older release of three.js that did not support it. The next release of Google Model Viewer will include it, and OpenSea will correctly show it thereafter. This site simply overrides the three.js library underlying Google Model Viewer in order to render the dispersion effect as it will eventually be seen everywhere.