Source confidence: high

Hunyuan3D-2 — Tencent's Open Image-to-3D Mesh Generator

In short: Run Tencent's Hunyuan3D-2 locally as a reproducible image-to-3D pipeline: reference image in, cleaned and textured GLB out, measured for VRAM, time, mesh validity, and fidelity to the input, then extended to the text-to-image-to-mesh chain and a Blender import.

Key fact Detail
What it covers 3D, art, design, image generation
Tools Hunyuan3D, Hunyuan3D-2, Tencent
Posts covered 1 post (1 S-tier) · top: Hunyuan3D-2 — Tencent's free image-to-3D model…
Creators @nick_saraev
Sources dated Apr 2025
Prompt system Run-it-yourself prompts
Last verified 2026-10-22

GitHub: https://github.com/Tencent-Hunyuan/Hunyuan3D-2 Latest: Hunyuan3D-2.1 (PBR, production-ready materials) — https://github.com/Tencent-Hunyuan/Hunyuan3D-2.1 License: Tencent Hunyuan Community License (open weights, some commercial restrictions for very large companies) Size: the code is small (a few hundred MB) but model weights are 50 GB+ and are best pulled on demand from Hugging Face (tencent/Hunyuan3D-2 and tencent/Hunyuan3D-2.1). Clone only when you're ready to run it.

What it is

Hunyuan3D-2 is Tencent's open-source two-stage 3D asset generator. Feed it a single image and it returns a watertight 3D mesh with a textured (optionally PBR) surface, ready to drop into Blender, Unity, Unreal, or any standard DCC pipeline. It is the largest and most capable openly released image-to-3D model as of this writing, and it's the missing piece that has a companion: HY-Motion (Tencent's text-to-motion model), available at ./repos/HY-Motion-1.0/. Together they form a near-complete text → 3D character → animation pipeline (more on this below).

The release is actually a family of models, not a single checkpoint. There's a shape generator that hallucinates geometry from the image, a texture generator that paints the bare mesh, "Turbo" and "Fast" distilled variants for speed, a 600M "mini" variant for low-VRAM setups, and a multiview variant that takes 2–4 views of the same object for much better back/side reconstruction. Version 2.1 adds a full PBR texture stack (albedo / metallic-roughness / normal) so the outputs drop straight into a modern render engine without manual material fixup.

It is important to note: Hunyuan3D-2 is image-to-3D only. It does not natively read text prompts. The text-to-3D workflow everyone uses is "text → SDXL/Flux image → Hunyuan3D-2 mesh," which is what Tencent's own demos do internally. If you want single-call text-to-3D with open weights, this is not that tool — use Trellis or Tripo's hosted API for that (see guides/blender-mcp-tripo-pipeline.md).

How it works under the hood

Stage 1 — Shape generation (Hunyuan3D-DiT). A diffusion transformer operating in a latent 3D representation. The input image is encoded by a DINOv2-style vision encoder; the DiT denoises a latent volume conditioned on those features; a VAE decoder reconstructs an SDF (signed distance field) which is marched to a triangle mesh. The model was trained on tens of millions of 3D assets with rendered multiview supervision.

Stage 2 — Texture generation (Hunyuan3D-Paint). A multi-view diffusion model that paints the bare mesh. It renders the mesh from 6+ canonical viewpoints, diffuses textures on each view jointly (with cross-view attention for consistency), then bakes them back into a UV atlas. v2.1's Paint model outputs a full PBR set.

Output is always a trimesh.Trimesh object, which you can export as GLB, OBJ, PLY, STL, FBX — anything trimesh supports. GLB is the recommended default since it embeds textures and PBR materials in one file.

System requirements

Be honest with yourself about VRAM. This is a big model.

Hunyuan3D-2.0:

Hunyuan3D-2.1 (PBR):

Disk: model weights are ~50 GB across shape + texture for v2.1. Keep them on an NVMe — loading is I/O bound.

Software: Python 3.10+, PyTorch 2.1+ with CUDA 11.8 or 12.1, a C++ toolchain for the custom rasterizer/renderer. Linux is the happy path; Windows works via WSL2 or YanWenKun's WinPortable build (https://github.com/YanWenKun/Hunyuan3D-2-WinPortable). macOS works for shape only via MPS — texture gen is effectively CPU-bound and unbearably slow. There's also a GPU-poor fork at https://github.com/deepbeepmeep/Hunyuan3D-2GP that offloads aggressively for 8 GB cards.

Quick start

# clone code (small)
cd ./repos/
git clone https://github.com/Tencent-Hunyuan/Hunyuan3D-2.git
cd Hunyuan3D-2

# python env
python -m venv .venv && source .venv/bin/activate
pip install torch==2.3.0 torchvision --index-url https://download.pytorch.org/whl/cu121
pip install -r requirements.txt
pip install -e .

# build the custom rasterizer + renderer (required for texture gen)
cd hy3dgen/texgen/custom_rasterizer && python setup.py install && cd ../../..
cd hy3dgen/texgen/differentiable_renderer && python setup.py install && cd ../../..

# weights auto-download from HF on first run; or preload:
huggingface-cli download tencent/Hunyuan3D-2 --local-dir ./weights

Minimal image-to-mesh script:

from hy3dgen.shapegen import Hunyuan3DDiTFlowMatchingPipeline
from hy3dgen.texgen import Hunyuan3DPaintPipeline
from PIL import Image

img = Image.open("reference.png")

shape_pipe = Hunyuan3DDiTFlowMatchingPipeline.from_pretrained("tencent/Hunyuan3D-2")
mesh = shape_pipe(image=img)[0]          # trimesh.Trimesh
mesh.export("bare.glb")

paint_pipe = Hunyuan3DPaintPipeline.from_pretrained("tencent/Hunyuan3D-2")
textured = paint_pipe(mesh, image=img)
textured.export("final.glb")

For the Turbo variants, swap the pretrained name to tencent/Hunyuan3D-2/hunyuan3d-dit-v2-0-turbo and drop inference steps to 6. For v2.1 with PBR, use tencent/Hunyuan3D-2.1.

There is also a Gradio app (python app.py), an API server (python api_server.py), and a ComfyUI integration documented at https://docs.comfy.org/tutorials/3d/hunyuan3D-2 — ComfyUI is the path of least resistance if you already use it for SDXL/Flux work.

How image-to-mesh differs from text-to-mesh

Text-to-3D tools (Shap-E, Point-E, early DreamFusion) hallucinate geometry from a text prompt alone. They're fast but vague — "a red sports car" gives you something car-shaped but generic and blurry. Image-to-3D is the dominant paradigm now because it cleanly separates concerns: let a mature 2D generator (SDXL, Flux, Midjourney) handle creative ideation and composition, then let a specialist 3D model do what it's good at — recovering geometry from pixels it can see.

Concretely with Hunyuan3D-2:

Integration with HY-Motion — the full pipeline

If you have HY-Motion cloned at ./repos/HY-Motion-1.0/. HY-Motion generates SMPL-X skeletal motion from text ("a character doing a backflip"). Hunyuan3D-2 generates a static character mesh from an image. Chained, you get:

  1. Text prompt → Flux/SDXL → character reference image
  2. Character image → Hunyuan3D-2 (mv variant for quality) → textured GLB
  3. Auto-rig → Mixamo auto-rigger, Blender's Rigify, or Meshy's auto-rig endpoint
  4. Motion prompt → HY-Motion → SMPL-X animation
  5. Retarget → Blender (use the Rokoko or Auto-Rig Pro retargeter) → final animated character
  6. Render → Blender Eevee/Cycles, or export FBX to Unity/Unreal

The weak link in this chain is step 3 (auto-rigging). Hunyuan3D-2 doesn't output rigs. Mixamo works for humanoid bipeds, breaks on anything else. For non-humanoid creatures you'll need manual rigging or a tool like AnythingWorld.

This is a genuinely powerful pipeline for indie game devs, VTuber creators, and previs artists. No existing commercial product bundles it this way.

What we could build with it

Sources

Prompt system — run this yourself

Everything below is pasteable into Claude Code, Claude, or any agent. Use the one-shot when you want the whole result in one run; use the step prompts when you want to steer. Every step carries its own audit, and the gap audit at the end makes the agent find and fill what it missed.

Mission. Run Tencent's Hunyuan3D-2 locally as a reproducible image-to-3D pipeline: reference image in, cleaned and textured GLB out, measured for VRAM, time, mesh validity, and fidelity to the input, then extended to the text-to-image-to-mesh chain and a Blender import. Done means a scripted batch run on 10-20 of your own reference images with a results table (variant, steps, seconds, peak VRAM, watertight, face count, glTF validator errors, silhouette IoU), a license check for your intended use, and a clear verdict on which variant (Turbo, mini, mv, 2.1 PBR) fits your GPU and quality bar.

1 · Deeper, not bigger

Before running anything, make the task deeper rather than larger. Ask: what would a top professional do here that I am not asking for; what is the rawest material; which methods and tools; what, other than the model or me, proves it right. Then ask for exactly that.

Rewritten prompt — ask for exactly that:

Act as a technical artist and 3D ML engineer setting up Tencent Hunyuan3D-2 on my machine (GPU: report from nvidia-smi). First read the Hunyuan3D 2.0 technical report, the repo README for Hunyuan3D-2 and 2.1, the Hugging Face model cards for tencent/Hunyuan3D-2 and tencent/Hunyuan3D-2.1, and the LICENSE; summarize variants, VRAM claims, and any territory or user-count restrictions. Clone the repo, create a Python 3.10 venv, install the CUDA-matched PyTorch, build custom_rasterizer and differentiable_renderer, and download pinned weight revisions. Write run_batch.py that, for each image in refs/: removes the background with hy3dgen.rembg, centers and pads it, generates shape with the chosen variant and seed, cleans it with FloaterRemover, DegenerateFaceRemover and FaceReducer, paints it if VRAM allows, exports GLB, and logs seconds per stage, peak VRAM, face count, watertightness, and silhouette IoU against the input mask. Run Turbo, standard, and mini (and 2.1 if it fits) on 10-20 of my images with fixed seeds. Validate every GLB with Khronos gltf_validator and a headless Blender import plus 4-view turntable render. Test the multiview variant on three objects with 2-4 views versus single view and compare back-side renders. Return results.csv, the turntable contact sheet, a variant recommendation for my GPU, the license verdict for my use, and a list of guide claims that did not hold.

2 · One-shot prompt

ROLE AND STANCE
You are a technical artist and 3D ML engineer turning Tencent's Hunyuan3D-2 into a measured, reproducible image-to-3D asset pipeline on this machine. You benchmark instead of eyeballing, you pin every version, and you validate every mesh with tools other than the model that produced it.

CONTEXT
- Code: github.com/Tencent-Hunyuan/Hunyuan3D-2 and github.com/Tencent-Hunyuan/Hunyuan3D-2.1. Weights: Hugging Face tencent/Hunyuan3D-2 and tencent/Hunyuan3D-2.1 (~50 GB for 2.1).
- Two stages: shape (Hunyuan3D-DiT, flow-matching DiT over a 3D latent, VAE decodes an SDF, marched to a mesh) and texture (Hunyuan3D-Paint, multiview diffusion baked to UV; 2.1 adds albedo, metallic-roughness, normal).
- Variants from the guide: DiT-v2-0 (1.1B), -Fast (guidance-distilled), -Turbo (step-distilled, 6-8 steps vs 50), v2-mini (0.6B), v2-mv (2-4 views), v2-1 (3.0B); Paint-v2-0 (1.3B), -Turbo, 2.1 Paint PBR.
- API: Hunyuan3DDiTFlowMatchingPipeline.from_pretrained('tencent/Hunyuan3D-2'); Hunyuan3DPaintPipeline.from_pretrained('tencent/Hunyuan3D-2'); outputs trimesh.Trimesh; export GLB.
- Claims to TEST: VRAM 6 GB shape-only mini, ~10 GB DiT-v2-0, 16 GB shape+texture for 2.0; 10 / 21 / 29 GB for 2.1 shape / texture / both; ~30 s per Flux image to mesh on a 4090; outputs 'watertight'; multiview is 'the single biggest quality unlock'; macOS texture is effectively unusable; Turbo at 6 steps is close to standard quality.
- Downstream chain from the guide: text -> Flux/SDXL image -> Hunyuan3D-2 -> auto-rig (Mixamo, Rigify) -> HY-Motion SMPL-X motion -> Blender retarget -> render. Auto-rigging is the weak link; Hunyuan3D outputs no rig.

HARD CONSTRAINTS
- Read the LICENSE first and state whether the user's territory and intended use are permitted. If not, stop before generating assets for that use.
- Pin the repo commit, the weight revisions, PyTorch and CUDA versions in env.lock.md.
- Fixed seeds; same preprocessed image for every variant comparison.
- Do not exceed available VRAM by guesswork: measure with torch, and use the mini or GP fork if the full pipeline OOMs.
- Store weights on fast local disk; do not commit weights or generated assets to git.

ORDERED DELIVERABLES
1. ground-truth.md: GPU and driver, variant table from model cards, VRAM claims, license verdict with quoted clauses, the report's evaluation metrics and datasets.
2. env.lock.md and a working venv with custom_rasterizer and differentiable_renderer built; minimal_demo.py runs.
3. run_batch.py with preprocessing (BackgroundRemover, center, pad to square), per-variant shape generation, cleanup (FloaterRemover, DegenerateFaceRemover, FaceReducer to a target face count), optional paint, GLB export, and per-stage logging of seconds and peak VRAM.
4. metrics.py: trimesh is_watertight, face/vertex counts, euler number, bounding box; silhouette IoU between the input alpha mask and a front orthographic render; gltf_validator error and warning counts.
5. blender_check.py run via `blender -b --python`: import each GLB, confirm materials and images resolve, render a 4-view turntable to PNG.
6. results.csv over 10-20 reference images x variants that fit; contact_sheet.png of turntables.
7. mv_test/: three objects with single-view versus 2-4 view runs, back-side renders, and a blind preference record.
8. chain_demo/: one text prompt -> image (any local or API image model) -> mesh -> Rigify or Mixamo attempt, documenting where it breaks.

BUILT-IN GAP ANALYSIS
Before finishing, write gaps.md: variants you could not run and why (VRAM, build failure); VRAM claims that did not match your measurements; meshes that failed validation and the failure type; whether 'watertight' held before and after cleanup; textures with seams or baked lighting; anything in the chain demo that needed manual work. Fix what is fixable now (for example tune FaceReducer targets, retry with better background removal), and leave the rest documented.

SELF-QUESTIONS BEFORE FINISHING
- Did I read the license's territory and scale clauses, and does the user's use fit?
- Are all variant comparisons using the same seed and the same preprocessed image?
- Did I measure peak VRAM with the torch counters reset before each stage?
- Is the silhouette IoU computed from a camera that matches the input framing?
- Did cleanup remove real geometry along with floaters on thin parts?
- Do textured GLBs load in Blender with images embedded, not linked to temp paths?
- Is the multiview comparison blind, and does it include the back side?

STOP CONDITIONS
Stop and ask if the license excludes the user's territory or use, if the CUDA toolchain cannot build the rasterizer after two attempts with exact errors, or if no variant fits VRAM even with the GP fork. Otherwise stop when results.csv, contact sheet, mv_test, and gaps.md exist.

RETURN FORMAT
One message: GPU and env summary; license verdict; results table aggregated per variant (mean seconds, peak VRAM, watertight rate, mean IoU, validator errors); multiview verdict; recommended variant; gaps.md contents; paths to all outputs.

3 · Step-by-step prompts

Step 1 — Ground truth: report, model cards, license, hardware

Goal: Know exactly what the model family claims, what this machine can run, and what the license allows.

Run `nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv` and `nvcc --version`; record both. Read the Hunyuan3D 2.0 technical report on arXiv (find it from the repo README) and note: architecture of the shape DiT and Paint model, evaluation metrics and datasets, and any numbers for speed and VRAM. Read the README of github.com/Tencent-Hunyuan/Hunyuan3D-2 and Hunyuan3D-2.1 and list every variant with parameter count and Hugging Face subfolder by browsing the file listings of tencent/Hunyuan3D-2 and tencent/Hunyuan3D-2.1. Copy the guide's VRAM table and mark each value 'claimed'. Read the LICENSE file and quote the clauses on territory, monthly-active-user thresholds, and output use; state whether the user's location and intended use are covered. Write ground-truth.md with sections: Hardware, Variants, Claimed VRAM and speed, License verdict, Evaluation metrics from the report.

Expect: ground-truth.md of one to two pages with a variant table, quoted license clauses, and a yes/no/unclear license verdict.

Audit before moving on: Every variant must map to an actual Hugging Face path you saw; drop or flag any the guide lists that do not exist. If the license verdict is 'no' or 'unclear' for the user's use, stop and report before downloading weights.

Step 2 — Build a pinned, working environment

Goal: Get minimal_demo.py running with locked versions and compiled renderers.

Clone github.com/Tencent-Hunyuan/Hunyuan3D-2 into repos/ and record the commit hash. Create a Python 3.10 venv. Install the PyTorch build whose CUDA version matches the driver from step 1 (choose the index URL accordingly rather than copying the guide's cu121 blindly). `pip install -r requirements.txt && pip install -e .`. Build hy3dgen/texgen/custom_rasterizer and hy3dgen/texgen/differentiable_renderer with `python setup.py install`; capture full logs. Download weights with `huggingface-cli download tencent/Hunyuan3D-2 --revision <commit>` for the shape and paint subfolders you will test, onto NVMe; record revisions and disk size. Run the repo's minimal demo on its sample image and save the GLB. Also run `python -c 'import torch;print(torch.cuda.is_available(), torch.version.cuda)'` to confirm the GPU is visible. Write env.lock.md with Python, torch, CUDA, repo commit, weight revisions, and build outcomes.

Expect: env.lock.md, a demo GLB, and build logs; python -c 'import custom_rasterizer' succeeds.

Audit before moving on: If either extension fails to build, read the error, fix toolchain mismatches (gcc version, CUDA_HOME, TORCH_CUDA_ARCH_LIST) and retry once; on a second failure, record the exact error and continue shape-only. Confirm the demo GLB opens with trimesh and has more than 1,000 faces.

Step 3 — Write the batch runner with preprocessing and cleanup

Goal: One script turns a folder of references into cleaned GLBs with timing and VRAM logs.

Write run_batch.py --refs refs/ --variant {standard,turbo,fast,mini,mv,v21} --seed 1234 --paint {none,v20,v20turbo,v21} --out out/. For each image: remove background with hy3dgen.rembg.BackgroundRemover if no alpha exists; crop to the alpha bounding box, pad to square with 10 percent margin, resize to the size the pipeline expects; save the preprocessed image and its mask. Load the shape pipeline once per variant (subfolder per the variant table) and set steps per model card (Turbo around 5-8, standard per default). Before each stage call torch.cuda.reset_peak_memory_stats(); after it record torch.cuda.max_memory_allocated() and wall seconds. Clean the mesh with FloaterRemover, DegenerateFaceRemover, then FaceReducer to a configurable target (default 40,000 faces); keep both raw and cleaned GLBs. If painting, run the paint pipeline on the cleaned mesh with the same image. Append a row per image and variant to results.csv: image, variant, paint, seed, shape_s, paint_s, shape_peak_gb, paint_peak_gb, faces_raw, faces_clean. Catch CUDA OOM per item, log it, and continue.

Expect: run_batch.py under 250 lines; a smoke run on 2 images producing 4 GLBs and a 2-row results.csv.

Audit before moving on: Re-run the smoke test with the same seed and confirm identical face counts (determinism). Check that peak VRAM is non-zero and below total VRAM. If cleanup reduces faces by more than 80 percent on a simple object, inspect for removed real geometry.

Step 4 — Add independent quality metrics and Blender validation

Goal: Score every GLB with tools other than the generator.

Write metrics.py that, for each cleaned GLB, loads it with trimesh and records is_watertight, euler_number, face and vertex counts, and bounding-box aspect ratios; renders a front orthographic silhouette with pyrender or Blender at the same framing as the preprocessed input, then computes IoU against the saved input mask; and runs the Khronos `gltf_validator` CLI, recording error and warning counts. Write blender_check.py for `blender -b --python blender_check.py -- <glb> <outdir>`: clear the scene, import the GLB, assert every material's image textures have pixel data, normalize scale, add a three-point light and camera, render front, right, back, and top at 512 px with Eevee, and write a JSON status. Run both over all outputs and merge columns into results.csv: watertight, iou, gltf_errors, gltf_warnings, blender_ok. Build contact_sheet.png from the turntables with Pillow, one row per image and variant.

Expect: Extended results.csv, a contact sheet, and a JSON status per GLB.

Audit before moving on: Validate metrics.py on a known-good mesh (a Blender default cube exported to GLB): IoU near 1.0 for a matching mask, watertight true, zero validator errors. If the known-good case fails, the metric is wrong; fix it before trusting any score.

Step 5 — Run the variant benchmark on your references

Goal: Produce the numbers that decide which variant to use on this GPU.

Assemble refs/ with 10-20 of your own images spanning: hard-surface objects (mug, tool), organic (plant, animal), a stylized character, thin structures (chair, bicycle), and a flat object (coin, leaf). Run run_batch.py for every variant that fits VRAM per step 1: standard, turbo, fast, mini, and v21 if 24 GB or more; paint with v20 and v20turbo, and v21 PBR if VRAM allows. Then run metrics.py and blender_check.py. Aggregate per variant: mean and p90 shape seconds, mean paint seconds, max peak VRAM, watertight rate, mean IoU, GLBs with validator errors, Blender failures. Compare measured VRAM and time against the guide's table and note each difference. Pick the five worst outputs by IoU and describe the failure type from the turntables (thin parts lost, back hallucinated, texture seams, baked lighting).

Expect: results.csv with all rows, an aggregate table per variant, and a five-item failure gallery with descriptions.

Audit before moving on: Confirm every image ran under every fitting variant with the same seed; missing rows must be explained (OOM or error logged). If the guide's VRAM number is exceeded by more than 20 percent, re-measure once with nothing else on the GPU before recording.

Step 6 — Test the multiview claim and the text-to-character chain

Goal: Check the 'biggest quality unlock' claim and find where the full pipeline breaks.

For three objects, capture or generate 2-4 orthogonal views (front, left, back, right) with consistent lighting and scale. Run the mv variant with all views and the standard variant with the front view only, same seed. Render back views of both with blender_check.py. Shuffle the pairs and ask the user or a grader subagent shown only the four reference photos and two unlabelled back renders which is closer; record preferences and the IoU of side views against the side photos. Next, run the chain once: a text prompt to an image model available to you (local Flux or SDXL via ComfyUI, or an API), producing a front-facing A-pose character on a plain background; mesh it with the best variant; import into Blender and try Rigify's auto-generation or upload to Mixamo; if HY-Motion is cloned at ./repos/HY-Motion-1.0/, generate one motion and attempt a retarget. Log each handoff and what required manual fixes.

Expect: mv_test/ with renders and a preference table; chain_demo/ with the image, GLB, rig attempt, and a handoff log.

Audit before moving on: If the grader could tell which render came from mv by filename or order, redo the shuffle. For the chain, a step that silently produced an unusable result (rig with inverted bones, motion on the wrong skeleton) counts as a break, not a pass.

Step 7 — Validate against oracles and write the gap report

Goal: Lock the recommendation with external checks and document every remaining gap.

Confirm the oracle set: all recommended-variant GLBs pass gltf_validator with zero errors; Blender headless import succeeds for each; watertight rate after cleanup; mean IoU above the threshold you set in advance (default 0.85); measured VRAM versus the guide. Write recommendation.md: the variant and paint model for this GPU with the evidence rows, expected seconds per asset, and the preprocessing settings to use. Write gaps.md with: guide claims and verdicts (VRAM table, 30 s on 4090, watertight, multiview unlock, Turbo quality), variants not run and why, failure categories with counts, chain breakpoints, license constraints on outputs. Fix the top fixable item now (for example raise padding if thin parts are clipped) and re-run the affected images. Record the final env.lock.md and the exact command that reproduces the recommended run.

Expect: recommendation.md, gaps.md, and a final results.csv; every claim has a verdict.

Audit before moving on: Every recommendation sentence must point to rows in results.csv or mv_test. If the threshold for IoU was changed after seeing results, say so explicitly. Re-run one recommended-variant item from a fresh shell to confirm reproducibility.

4 · Gap analysis and audit

Run this after the build. It makes the agent enumerate its own claims, mark what is verified, rank the gaps and fix the top ones.

You are auditing a Hunyuan3D-2 pipeline and benchmark built by someone else: run_batch.py, metrics.py, blender_check.py, results.csv, mv_test/, chain_demo/, recommendation.md, gaps.md. Do not trust recommendation.md. (1) List every claim: variant speeds and VRAM, watertight rates, IoU scores, multiview preference, license verdict, reproducibility. (2) Verify each by re-running three random items from a fresh shell with the recorded seed and comparing face counts, peak VRAM, and IoU; re-running gltf_validator and Blender import on five GLBs; re-reading the license clauses quoted. Mark verified, unverified, or false. (3) Check the metrics themselves: does the IoU render match the input framing; does the known-good cube test exist and pass; are watertight checks done on cleaned or raw meshes and is that stated. (4) Look for silent failures: OOM items missing from results.csv without a log line, textures that reference temp paths, Blender renders that show empty scenes. (5) Check the multiview test for blinding and sample size. (6) Rank gaps by impact (license risk, unusable assets, wrong recommendation, slow runs), fix the top three now, and report the rest with the reproduction command.

Questions the agent must ask itself before it says done:

5 · What proves it right

6 · Failure modes

7 · Agent direction (unattended runs)

Start with nvidia-smi, the license, and the model cards; do not download 50 GB of weights until the license verdict is yes and the GPU fits at least one variant. Cache weights on NVMe and record revisions; never re-download. Load each pipeline once per variant and loop over images to avoid reload cost. Spawn a subagent for blind grading in the multiview test only, giving it unlabelled renders. Run Blender headless, never interactively. Stop and ask on a license 'no' or 'unclear', on two failed extension builds, or if no variant fits VRAM. Keep generated assets out of git. Return in chat the license verdict, per-variant aggregate table, multiview verdict, recommendation, and gaps; files: ground-truth.md, env.lock.md, run_batch.py, metrics.py, blender_check.py, results.csv, contact_sheet.png, mv_test/, chain_demo/, recommendation.md, gaps.md.

Prompt system updated 2026-10-22 · all prompt systems · JSON