Improving Accuracy of AI-Generated Jewelry Models in RhinoCommon

Hi everyone :waving_hand:

I’m based in India and currently working on a project that I believe could be a game changer for jewelry design:

Multiple images of a piece of jewelry → AI → editable Rhino .3dm model

The goal is to generate an editable 3D model that is as close as possible to the original jewelry piece shown in the reference images.

What I’m currently trying

I’m taking a programmatic approach using AI + C# + RhinoCommon.

My current workflow is roughly:

Reference images

LLM analyzes the images and creates a detailed construction plan

Another LLM call receives the images + construction plan + RhinoCommon knowledge

LLM generates a complete C# RhinoCommon script

My execution plugin runs the C# script

Editable .3dm file

For the RhinoCommon knowledge, I’ve been building my own knowledge base from the official RhinoCommon API documentation and providing relevant information to the model, including:

  • Classes

  • Class descriptions

  • Methods / properties / constructors

  • Member descriptions

  • Syntax

The problem

The pipeline itself is working, but the geometric accuracy is currently the biggest challenge.

At the moment, the generated model is only around 10–20% accurate compared with the original/reference design in many cases.

My target is to get the result as close as realistically possible to the original geometry, not just visually approximate it.

I’m relatively new to Rhino and RhinoCommon, so I may be missing some important geometry/construction techniques or a better overall approach.

I’d really appreciate advice from Rhino experts

If you have strong experience with:

  • RhinoCommon / Rhino.Geometry

  • Procedural or parametric jewelry modeling

  • Brep / surface / curve construction

  • Reverse engineering jewelry geometry

  • Comparing or validating Rhino geometry

  • Or alternative approaches for going from images → accurate editable .3dm

I would really appreciate any suggestions, ideas, or references.

Even a small suggestion about how you would approach the geometry reconstruction problem differently could be very valuable to me.

BNA0925_RingScript_3.cs (24.9 KB)

I’m also happy to share a small reproducible example, including a reference model and the generated model, if that helps with the discussion.

And if anyone is interested in the project and would like to discuss it in more detail, I’d be very happy to connect privately.

Thanks in advance to everyone who takes the time to read this and share their knowledge. :folded_hands:

Regards,
Sanket

Hi @SanketBhimani,

Why don’t you ask your AI agent to fix?

The comments say the constants were measured directly from BNA0925.3dm — angles, girdle radii, ring size. So this isn’t really testing the image-to-model step; the model was handed the dimensions and still didn’t match.

And it doesn’t match the numbers it had. Your tech sheet says the shank is 1.50 × 2.00 mm and flat; the script uses SHANK_THICK = 2.58 with a round-crowned profile. That’s most of what you’re seeing in the viewport.

My suggestion: don’t have the LLM write geometry code. Build the parametric components yourself — shank profiles, prong and basket settings — validate them once, and let the LLM only fill in parameter values. You go from generating unbounded code to fitting about twenty numbers.

Also worth fixing: set the document to millimeters at 0.001 tolerance. Your booleans retry at 0.10 mm on prongs of 0.20 mm radius, which yields geometry that passes IsSolid but isn’t right.

— Dale

Thank you, @dale , for taking the time to review this and for the detailed suggestions.

I’d like to clarify the C# script I attached. I accidentally attached the wrong version.

The BNA0925_RingScript_3.cs file was not the original C# generated by the LLM. The original LLM-generated script failed during execution, so I used an AI agent to rewrite/fix the code using the original BNA0925.3dm as a reference.

BNA0925_RingScript_2.cs (60.5 KB)

I provided the actual C# script generated directly by the LLM so you can see what the model produced before any AI-based fixing or modification.

Your suggestion is very helpful. I’ll investigate that direction as well.

Thanks again for your guidance.

Hi @dale,
I think this is the right direction, but I want to be honest about the challenge I’m facing with it.

My actual order catalog includes many different ring families with fundamentally different construction topology — not just the same geometry with different numbers. So I’d need a separate validated builder per component type and ring family, which is a significant upfront investment.

The main thing blocking me is that I have essentially zero background in RhinoCommon. I don’t have a map of which operations are appropriate for which jewelry geometry, or how to correctly sequence them so they don’t fail at jewelry-scale tolerances. Without that foundation, I can’t write builders I trust.

For handling ring types that fall outside my library, I’ll work out a fallback strategy on my own side.

Would you be able to point me to any RhinoCommon examples or documentation that covers jewelry-specific geometry patterns, or any other suggestion from your side? Even a starting point for the shank and prong basket would help me build the library correctly from the ground up.

— Sanket

Hi @SanketBhimani,

Useful links:

https://github.com/mcneel/rhino-developer-samples

– Dale