Generating Stone Jewelry Designs
Given a jewelry outline (container shape) and a palette of stones (shapes/sizes), generate a design:
- Pick candidate stones via DP such that placing them won't strand unfillable negative space later.
- Rank candidates with design-principle rules (size similarity to running mean, radial orientation symmetry, position fit).
- Place the top-ranked candidate; repeat until the container is filled.
- Score the finished design with a trained Gradient Boosted Trees pruning model; keep it only if predicted "liked."
- Render: wrap each stone in a bezel, apply stone texture.
Progress:
- Define container (jewelry outline) and stone inventory (shapes × sizes × stone types)
- Implement candidate generation (DP-based feasibility filter)
- Implement ranking rules tied to design principles (balance, harmony, proportion, unity, emphasis)
- Greedily place highest-ranked candidate; loop until container full or no valid candidates remain
- Compute design-level features (Table 1 analogs) for the finished layout
- Run pruning classifier; discard/flag low-scoring designs
- Render final design with bezels + textures
- Validate against held-out human ratings; tune ranking weights
Step 1 — Candidate Generation (Feasibility)
Use dynamic programming over remaining free space to shortlist stones whose placement won't create unfillable gaps later (avoid greedy dead-ends). This is a sub-problem of 2D packing/knapsack — reuse known DP formulations rather than re-deriving from scratch.
Step 2 — Ranking Candidates
Score each feasible candidate using rules derived from design principles:
- Size continuity: prefer stones whose size is close to the mean size of already-placed stones.
- Orientation harmony: prefer radially inward/outward orientation relative to the stone directly opposite.
- Positional fit: favor placements that keep balance (centroid proximity) and unity (even adjacent spacing).
Rank is a weighted combination — start with equal weights, tune via A/B testing against human likeability scores.
Step 3 — Placement Loop
Place the single top-ranked candidate, update occupied space, repeat Step 1–3 until container is filled or no valid candidate exists.
Step 4 — Pruning Model
Extract whole-design features (see table below) and score with Gradient Boosted Trees trained on human-annotated likeability labels (aggregate across multiple judges — individual taste is noisy, judge the set not single votes).
| Feature | Definition |
|---|---|
| Balance | Distance between container centroid and mean of all stone centroids |
| Emphasis | (Area of biggest stone − mean area of rest) × stddev of rest's areas |
| Harmony of Shape | Stddev of per-shape occurrence counts |
| Harmony of Orientation | Stddev of stone orientations |
| Proportion | Stddev of stone areas |
| Unity | Stddev of mean-adjacent-space across stones |
Step 5 — Render
Apply bezel outline per stone, fill with realistic stone texture, export for downstream production/manufacturing review.
Example 1: Input: Oval pendant outline, inventory of 40 Amethyst/Garnet stones in 7 shapes, 20 sizes. Output: A filled pendant design where stone sizes taper smoothly from center to edge (proportion), orientations mirror across the horizontal axis (harmony), and no large empty gaps remain (balance/unity) — passes pruning model with high likeability score.
Example 2: Input: Same inventory, but ranking rules disabled (pure DP feasibility, random tie-break). Output: Densely packed but visually incoherent design — large stone adjacent to tiny ones with clashing orientations; pruning model flags it as low-likeability (this is the "bad design" failure mode).
- Treat packing/feasibility (DP) and aesthetic ranking (rules) as separate stages — don't conflate density optimization with visual appeal; they optimize for different objectives.
- Always evaluate generated sets in aggregate (e.g., "% of designs liked by % of annotators") rather than per-design consensus — individual aesthetic judgment is highly variable.
- Use multiple annotators (10+) per design when building ground truth for the pruning model; 3 annotators is a minimum viable bootstrap, not a target.
- Keep design-principle features interpretable (balance, harmony, proportion, unity, emphasis) so the pruning model's decisions can be traced back to known aesthetic rules.
- Validate end-to-end against real production constraints (bezel feasibility, stone availability) before treating a design as final.
- Don't optimize purely for packing density/minimal empty space — this produces technically valid but aesthetically poor layouts (the classic failure mode in Figure 1c equivalents).
- Don't skip the feasibility/DP pre-filter and rank all stones greedily — this creates dead-end placements and unfillable negative space late in the process.
- Don't train the pruning model on raw pixel/geometry data when interpretable design-principle features are available and sufficient — simpler features generalize better here and are easier to debug.
- Don't rely on single-annotator labels for "likeability" — aesthetic preference is inherently multi-rater; aggregate before training.
- Don't assume one set of ranking weights transfers across radically different jewelry shapes (rings vs. earrings vs. pendants) without re-validation.