← Writing

Density is not a swatch

· 2 min · cad · three.js

A request that sounds trivial: let the customer pick a different stone colour in the 3D viewer. Green onyx instead of black, blue CZ instead of clear. Fifteen minutes of work: add a colour picker, set material.color, done.

It is trivial, and it is also almost worthless done that way, because the interesting question is never "what colour is it". It is "what does that change".

A material is a set of physical properties

A stone is not a hue. It has a density, a refractive index, and an opacity, and those are the things that determine what you can say about the piece afterwards. Swap a diamond for green onyx in the same setting and the carat weight drops by roughly a quarter. The geometry has not changed at all, but the density went from 3.52 to 2.61 g/cm³.

So the catalogue entry carries the physics, and the viewer derives numbers from geometry rather than storing them:

  • volume comes from the model,
  • weight is volume times the chosen material's density,
  • carat is weight divided by 0.2.

Change the metal from 18K yellow gold to platinum and the reported metal weight moves with it, because that is what happens when you replace an alloy at 15.6 g/cm³ with one at 20.0. Nothing about the shape moved. The bore is still the bore.

That is the difference between a recolour and an engineering change, and the interface should not blur it.

One setting, five stones · reported carat identical geometry; only the density changes Black onyx 2.61 0.33 ct Emerald 2.72 0.35 ct Diamond 3.52 0.45 ct Ruby 4.00 0.51 ct Cubic zirconia 5.70 0.72 ct g/cm³ One setting, five stones identical geometry; density changes Black onyx 0.33 ct Emerald 0.35 ct Diamond 0.45 ct Ruby 0.51 ct Cubic zirconia 0.72 ct · 2× onyx
Nothing about the model moved between these five figures. Swapping onyx for cubic zirconia more than doubles the stone weight, which is why the picker has to update the numbers and not only the render.

Where the list comes from

The second half of the problem is which options to offer.

A hardcoded swatch list will, sooner or later, let a customer choose something the factory cannot buy. So the catalogue is not written in the front end at all. It is read from the ERP's own stone and alloy masters on load, and every real type-and-colour combination that is actually stocked is registered as its own entry, inheriting the base stone's density and optical properties.

The consequence is quietly important: a customer can only pick a stone the business can source. The constraint is not enforced by a validation message after the fact; it is enforced by the option simply not existing.

Colourless is a real answer

One detail worth keeping. Once real colour variants exist for a stone type, the bare colourless version usually should not be offered, because nobody means "onyx, no colour". But for genuinely colourless gems, diamond and CZ and moissanite, "no colour" is the correct default rather than a missing value.

Small thing. It is the kind of small thing that decides whether a catalogue feels like it was built by someone who had seen the product.

Keep reading