Most web configurators fake a diamond with a reflection map or a generic glass material. Ring Facet ray-traces the real facet geometry of the stone in your CAD file, in a browser tab, on a phone.
What makes a diamond read as a diamond is total internal reflection between flat facets — light entering the table, bouncing several times off the pavilion, and leaving through the crown split into colour. A cube map cannot do that: it samples the environment once and stops. A standard transmission material does refraction, but against a triangle mesh, which is slow and noisy on the melee stones that make up a pavé halo.
At load time the engine reads the stone out of the model file and fits its facets as a set of half-space planes — the mathematical description of a cut. The shader then traces rays against that convex solid directly. There is no baked data, no per-stone authoring step, and no shader recompile: a cut the engine has never seen before works the first time it is loaded, which is what makes uploading your own CAD viable at all.
Measured across the entire shipping catalogue — 39 model files, 364 individual stones — 95% fit cleanly enough to trace analytically. The remaining 5% are genuinely non-convex centre stones in the pear, heart, and marquise cuts, which fall back to a bounding-volume-hierarchy tracer automatically. The fit is tight: on melee stones the convexity error is around two parts in a thousand of the stone's radius.
Exporters merge every melee stone in a pavé band into a single mesh. Fitted naively that produces one 2,779-plane object with a convexity error six hundred times too large — a grey smear where a row of diamonds should be. The engine welds vertices by quantised position and separates the stones by connectivity before fitting, so twelve stones in a halo are traced as twelve stones.
Rendering happens in linear high-dynamic-range space, with a thresholded bloom pass, ACES tone mapping, and an sRGB output transform at the end. Highlights on a facet edge can exceed display white and still resolve as a spark instead of clipping to a flat white blob.
Diamonds and metal want different light. The stones are lit by a dedicated high-contrast HDR environment built for gem fire — roughly fifteen times the bright-to-dark ratio of a standard studio map — while the metal keeps a soft studio environment that does not blow out a polished shank.
Multisampling barely helps a gem: the shader is high-frequency enough that shifting a ray by half a pixel changes which facet it enters. The engine supersamples with a deterministic jitter sequence and accumulates, which is what stops a stationary stone from flickering.
It is WebGL in a normal page. No app, no browser extension, no native viewer, no plugin. A shopper on a phone taps a product page and the ring is turning.
Models ship as Draco-compressed GLB. A typical setting is under a megabyte; the heaviest pavé halo in the catalogue is 4.3MB, and only the parts a shopper has actually selected are ever fetched — not the whole catalogue.
The engine that does all of the above is a 171KB script. It is the configurator, not a download that precedes it.
Selecting a different setting swaps one model. Changing metal, karat, finish, colour grade, or gem colour fetches nothing at all — those are shader parameters, so they apply in the same frame.
The same stone appears in the storefront embed, the merchant dashboard, the model editor, the demo viewer, and the internal builder — five separate runtimes that cannot import each other. Each build hashes the shader source in all five and fails if any one has drifted. The same discipline covers money: the pricing model is implemented in four runtimes (the embed, the quote service, the Shopify cart function, and the Shopify theme widget) and a fixture matrix is replayed through every one on each build, because a shopper shown one number and charged another is the one bug a screenshot never catches.
Every claim on this page shows up in the first ten seconds of the demo, on whatever device you are reading this on.