---
title: "From a production CAD file to a render ready ring"
description: "Sorts a ring's production file into metal, prongs, stones, supports and cutters, shows the designer a dry run, then cleans the metal and saves a separate render file the way each manufacturer's profile asks."
url: /work/jewelprep
markdown: /work/jewelprep.md
case_study: true
updated: 2026-10-13
---

# From a production CAD file to a render ready ring

AMG Dynamics · Jul 2026 to now

> I built JewelPrep, a Rhino plugin that turns a manufacturer's production file into a render ready model. On a real production ring the full run takes about 35 seconds. By hand the job takes hours.

| Fact sheet | |
| --- | --- |
| Client | AMG Dynamics, India |
| Role | Built it |
| When | Jul 2026 to now |
| Who else | The test files came from two manufacturers, unnamed here. |
| Stack | Rhino 8, Python, RhinoCommon, Cython |

## Headline numbers

- **about 35 seconds** for the full run on one production ring
- **0.021 mm** mean distance from the first manufacturer's own render file

## The problem

A ring's production file is built for the workshop, and it carries parts a render doesn't need. On the first manufacturer's file I worked from, the metal was 67 separate solids, there were 26 prongs on their own layer, 6 support rods and 39 hidden cutters for the stone seats.

That manufacturer's render file needed one clean metal body with the prongs merged in and the construction parts gone. A designer does that by hand, ring by ring, and it takes hours.

## Constraints

- It runs inside Rhino, where the files already open.
- Files come from different manufacturers and different CAD packages, and they don't follow the same rules.
- It must never delete a real part of the ring by mistake.
- The output has to match what each manufacturer's own renderer expects.

## Decisions

1. **Keep anything that only looks like a support as metal unless the designer confirms it**, over deleting every shape guess, because on the first manufacturer's production file those shapes were the connector between head and shank, and its own render file keeps them.
2. **A profile per manufacturer**, over one output style for everyone, because the first manufacturer's render files turned out to be triangle meshes, so its profile smooths and then triangulates, while another profile keeps the quad output.
3. **Merging the metal is a switch, never a fixed stage**, over always merging into one mesh, because the second manufacturer's render files weren't consistent: most were one merged mesh and the rest were loose pieces.
4. **Reuse the file's own materials**, over replacing them, because the second manufacturer's renderer binds materials by name, so a renamed material breaks the file.
5. **A dry run that classifies and selects before anything is deleted**, over deleting in one pass, because deleting by layer name can destroy a real part of the ring, so the designer checks the selection before anything is gone.

## How it works

JewelPrep sorts every object in the file into metal, prongs, stones, supports and cutters. Then it drops the supports and cutters, scales the prongs, unites the metal into one body when the manufacturer's profile asks for it, remeshes and smooths it, and saves a separate render file without its own working layers.

Release builds are compiled, every run writes its own log, and beta builds expire. An optional AI advisor runs on the designer's own key, which lives in their own settings and never in a ring file.

## What the second manufacturer taught it

Everything I first built came from the first manufacturer's files. Then the second manufacturer sent 7 files from a different CAD package. They overturned four assumptions: merging isn't universal, their files have no cutters or supports, their stones stay as blocks, and their renderer binds materials by name. In 5 of their render files the metal was one merged mesh, and in the rest it was loose pieces.

## Sorted first, then cleaned

How JewelPrep turns a production file into a render file. No manufacturer's file is shown.

- Production file (from the manufacturer) → Classify (metal, prongs, stones, supports, cutters)
- Classify (metal, prongs, stones, supports, cutters) → Dry run (the designer sees what goes)
- Dry run (the designer sees what goes) → Clean and unite (one metal body, where the profile asks): confirmed
- Manufacturer profile (mesh style, merge switch, materials) → Clean and unite (one metal body, where the profile asks)
- Clean and unite (one metal body, where the profile asks) → Render file (saved separately)

## Results

- Checked against 99 hand labelled parts of that file, it sorted every metal piece, prong and support correctly, with no false positives.
- With the first manufacturer's profile, the output sits a mean 0.021 mm from that manufacturer's own render file.
- A designer beta went out in October 2026.

_AMG Dynamics' tool, shown with its approval. No manufacturer's file is shown._

## Contact

- Email: hi@namanbuilt.com
- LinkedIn: https://www.linkedin.com/in/naman-jain-hub

Horizon Beam is taking on new projects.