← Just Build It — the deck · evidence document

Eval — Tripo Image-to-3D (Concept Mesh)

JD item 6 (technical radar). Sourced from code in this repo: src/agents/concept-3d/tripo-provider.js, tripo-view-rules.js, mesh-from-sheet.js, blender-handoff.js, src/workflow/concept-3d-workflow.js.

What we tested

Whether Tripo's multiview-to-model API can turn a consistent 2D concept sheet (not photos of a real shoe) into a mesh good enough for spatial/Direction-Week review and Blender-refine handoff — and where the ceiling is versus production CAD.

Setup

Input: a single-identity six-view sheet (SHEET6_VIEWS = front, back, side, right, top, bottom, one Krea call, 3×2 grid, then Python/Pillow crop — consistent-orthographic-views.js) or an equivalent identity-locked front/side/back/right set under output/sheet6-case/. Independent per-angle generations were explicitly rejected as an input source: "Independent txt2img per angle produces different shoes → bad Tripo meshes" (consistent-orthographic-views.js:4).
View contract enforced in code, not just docs: Tripo's multiview endpoint takes at most 4 images in slot order [front, left, back, right] (TRIPO_MULTIVIEW_SLOTS, tripo-view-rules.js:12). This project requires front + side(=left) + back, right optional but "strongly preferred" (TRIPO_MULTIVIEW_REQUIRED_VIEWS, TRIPO_MULTIVIEW_OPTIONAL_VIEWS, tripo-view-rules.js:18-21). evaluateTripoMultiviewReadiness() throws TRIPO_MULTIVIEW_VIEWS_REQUIRED before ever calling Tripo if front/side/back are missing — the rule is a hard gate, not a suggestion.
Pipeline: resolveMeshViews() crops the sheet or falls back to identity PNGs → buildConceptMeshPackage() → mandatory approve2dViews() human gate → generateConceptMesh() via createTripoMeshProvider (model TRIPO_MODEL default v3.1-20260211) → mandatory 3D approval gate before publish (concept-3d-workflow.js).
Provider swap for offline runs: local-mesh-provider stub when TRIPO_API_KEY is unset — same package shape, no live call.

Findings

View-completeness rule is real and enforced: front+side+back is the hard minimum; a 4th (right) view materially improves lateral coverage but isn't required. Top/bottom are review-only — never sent to Tripo as multiview slots (tripo-view-rules.js:24,30, mesh-from-sheet.js:16 IDENTITY_VIEWS = ["front","side","back","right"]).
Topology is not production-ready. The codebase states this as a constant, not an afterthought: "Concept mesh ≠ production CAD — locks are review annotations only" (src/agents/concept-3d/index.js:55); the Blender handoff note repeats it — "Concept mesh handoff for Blender refine — not Gravity Sketch, not production last, not manufacturable shoe CAD" (blender-handoff.js:53); the workflow doc-comment says the same (concept-3d-workflow.js:63). Rhino/GH handoff for true CAD is explicitly not_implemented (index.js:201, blender-handoff.js:124) — Phase 2, not shipped.
Concept-phase use is the fit: fast spatial sanity check (proportion, silhouette, whether a design idea "reads" from all sides) and a Direction-Week/spatial-review asset (Jump spatial, Three.js/WebXR viewer) — not a manufacturing input.
Human gates bracket every step: 2D views must be explicitly approved (approve2dViews/request2dRevision) before mesh generation runs, and the resulting mesh needs a second approval (approve3dMesh/request3dRevision) before publish — two review checkpoints, not an autogenerate-and-ship path.
Input consistency dominates output quality more than any Tripo-side tuning knob available in this codebase: the one-sheet identity-lock approach exists specifically because independently generated per-angle images produced meshes of different shoes stitched together (consistent-orthographic-views.js:4).

Integrate now vs. wait

Decision	Verdict
Integrate now	As a concept-review and spatial-sanity tool (proportion/silhouette check, Direction-Week asset, WebXR walk-through) gated behind human approval at both 2D and 3D stages — already true today.
Wait	For any manufacturing, tooling, or last-fitting use case. Do not connect concept mesh output to Rhino/GH CAD or last-fit workflows until a dedicated CAD-grade pipeline exists (currently `not_implemented`). Do not remove the front+side+back gate or the dual human-approval gates to "speed up" the flow — both exist because unconstrained inputs silently produce bad geometry.

Risks

Silent quality degradation if the view-consistency step is skipped. Nothing downstream of resolveMeshViews() re-validates that all views are the same shoe — the enforcement is only at the generation-sheet step. A hand-uploaded mismatched front/side/back set would pass the assertTripoMultiviewReady slot check (it only checks which slots are present, not whether they agree) and still produce a broken mesh.
Version drift: TRIPO_MODEL defaults to a pinned string (v3.1-20260211); no automated check that this model version still exists or behaves the same on Tripo's side.
Cost/latency not modeled here — this eval covers geometry fitness, not throughput; no batch cost figures were captured for Tripo (see eval-sam3-parts.md for the SAM3 side, where cost is tracked per call).
Designer-facing risk: a smooth-looking mesh can read as "done" to a non-technical viewer. The written guardrail (≠ production CAD) lives in code comments and internal package notes, not yet as designer-facing UI copy — see docs/plan-designer-scale.md WS-C C3 for the planned fix (engineering-constraint hints in designer language).