assets/LOCAL_3D_ASSET_GEN.md
Status: RESEARCH BRIEF — informs docs/pipeline_review/STACK_FACTS_QUESTIONS.md Q3 ("the 5090-local
3D asset model"). Not canon, not a build order — a decision input for the pipeline-review correction
pass and for the benchmark gate to run when the RTX 5090 workstation lands.
Scope: open-source (self-hostable, weights-available) image/text-to-3D generation for a solo AAA game
replacing Meshy (SaaS) on a single RTX 5090 (32GB VRAM). Training-data cutoff for the assistant that
wrote this is January 2026; every load-bearing claim below was checked against the live web on
2026-07-15 and is tagged VERIFIED (fetched from a primary source — official repo/license file/model
card) or INFERRED (secondary/aggregator source, community report, or my own synthesis/reasoning — not
independently cross-checked against a primary document). Read the tag before trusting a number.
---
No single model wins every category, and the two obvious leaders each carry a real catch:
textured/PBR output path depends on **nvdiffrast + nvdiffrec, which are NVIDIA-licensed
non-commercial-only for third parties** (VERIFIED, quoted in §1.1). This is a real ship-blocker for
the *textured* pipeline, not a hypothetical one.
equivalent renderer trap, but its license caps at 1M MAU, excludes the EU/UK/South Korea, and
requires labeling + a "Powered by Tencent Hunyuan" notice (VERIFIED, §1.2).
Recommended default posture: run both, split by task, not by blind preference —
TRELLIS.2 for geometry/blockout and rapid iteration (its MIT shape path is clean; route texturing
elsewhere or through a swapped renderer), Hunyuan3D-2.1 for finished textured PBR hero assets
(clean production texture path, license caveats are operational, not architectural). Keep **Hi3DGen
(MIT, ByteDance/Stable-X) on the bench as the sharpest-geometry fallback. Do not** depend on
Sparc3D (no confirmed open weights, no stated license — §1.7) or on Rodin/Tripo 3.0/Hunyuan3D 3.x
(closed SaaS/API only, no local weights at all — §1.8). NPCs stay MetaHuman-first (in-engine creator,
UE 5.6+, since the browser MetaHuman Creator sunsets through 2026 — §3.3); generative models don't
compete there and shouldn't try to. Real cultural architecture should NOT be raw-generated at all — the
model class is trained on object-scale data with no urban/structural grounding and no accuracy
guarantee (§1.9, §3.4) — treat it as a §17.1 care-relevant tooling choice, not just a quality one. The
retopology/LOD/UV/collision "game-ready" gap has no mature open AI solution yet — the SOTA answer
(Hunyuan3D Studio's PolyGen/SeamGPT) is a research paper with no released code (§2.1) — so that stage
stays Blender-headless-scripted with human QC (§2.2). Full per-category matrix in §3; the concrete
benchmark protocol to run when the 5090 lands is in §5.2.
---
| Model | Org | License | Commercial use | VRAM (official) | Gen time (rough) | Output |
|---|---|---|---|---|---|---|
| TRELLIS.2 | Microsoft | MIT (code/model) — but PBR-bake deps are NVIDIA non-commercial | Geometry: yes. Textured PBR: blocked as shipped | 24GB min (A100/H100 verified) | 512³ ~3s / 1024³ ~17s / 1536³ ~60s (H100); ~5-10s reported on 4090 (INFERRED) | GLB, mesh+PBR (basecolor/rough/metal/opacity) |
| Hunyuan3D-2.1 | Tencent | Tencent Hunyuan 3D Community License | Yes, capped (1M MAU, EU/UK/South Korea excluded) | 10GB shape / 21GB texture / 29GB combined | ~10-25s per asset on RTX 4090 (INFERRED) | Mesh + production PBR |
| Hunyuan3D 2.0 | Tencent | Same license family, same MAU cap | Yes, capped | 24GB+ (INFERRED) | — | Mesh + texture |
| Hunyuan3D 2.5 / PolyGen | Tencent | Not open-sourced — tech report only | N/A (no weights) | N/A | N/A | N/A |
| Hunyuan3D 3.0 / 3.1 | Tencent | Cloud/API only (ComfyUI Partner Node) | SaaS terms apply, not a local-weights question | N/A (cloud) | N/A | N/A |
| TripoSG | VAST-AI-Research | MIT | Yes, unrestricted | 8GB min | Not published | GLB, adjustable face count |
| TripoSF | VAST-AI-Research | VAE+inference code open; full model reserved for closed Tripo 3.0 | Partial — the open slice only | Not published | Not published | — |
| Stable Fast 3D (SF3D) | Stability AI | Stability AI Community License | Free under $1M annual revenue; enterprise license required above | ~6-7GB | <1s (0.5s @ 7GB) | UV-unwrapped mesh + PBR, delighted |
| SPAR3D | Stability AI | Same Stability Community License | Free under $1M annual revenue; enterprise license required above | Not published | Real-time-class (fast) | Mesh + point-cloud-completed structure |
| Hi3DGen | ByteDance / Stable-X | MIT | Yes, unrestricted | Not published | Not published | Mesh (best-in-class geometry per community consensus, INFERRED) |
| InstantMesh | TencentARC | Apache 2.0 | Yes, unrestricted | 16GB recommended (8GB+ reported workable) | ~10s | Mesh from single or sparse multi-view images |
| Sparc3D | independent (lizhihao6) | No LICENSE file found in repo; no confirmed pretrained weights | Do not rely on | ~8GB claimed (single source, INFERRED) | — | Watertight/manifold mesh, claimed |
| Step1X-3D | StepFun | Open (weights + training code + 2M dataset released) | Reported commercial-friendly (verify license file before shipping — not independently fetched) | Not published | — | Geometry + texture, two-stage |
| Rodin (Gen-1.5/Gen-2) | Deemos/Hyper3D | Proprietary SaaS — no open weights at all | N/A locally | N/A | N/A | Reference/quality bar only |
spatial downsampling. (VERIFIED, repo README)
code. (VERIFIED)
(https://github.com/NVlabs/nvdiffrast/blob/main/LICENSE.txt, fetched directly):
> "The Work and any derivative works thereof only may be used or intended for use
> non-commercially. The Work or derivative works thereof may be used or intended for use by Nvidia
> or its affiliates commercially or non-commercially." Non-commercial is defined as "for research or
> evaluation purposes only and not for any direct or indirect monetary gain."
nvdiffrast renders the generated asset; nvdiffrec implements the split-sum PBR renderer that bakes
base-color/roughness/metallic/opacity onto the mesh (VERIFIED, repo README). That bake step is
exactly the "fully textured PBR in 3s" headline feature — so the part of TRELLIS.2 most useful for a
shippable game asset is the part sitting on a non-commercial NVIDIA license. An open GitHub issue
(https://github.com/microsoft/TRELLIS.2/issues/22) raises this with no maintainer resolution as of
research date. **This is not a hypothetical legal nitpick — it is the literal license text of a
hard dependency, verified directly.**
kg-git-dev/trellis-refactored(https://github.com/kg-git-dev/trellis-refactored), replaces nvdiffrast/nvdiffrec with gsplat +
PyTorch3D (Meta, BSD-3-Clause — genuinely commercial-safe, verified at
https://github.com/facebookresearch/pytorch3d/blob/main/LICENSE). This proves the fix is
mechanically straightforward. However the fork is archived/inactive since November 2025,
built as a university course-project artifact, with documented CUDA/Pydantic/torchvision
version-mismatch bugs and no maintenance going forward (VERIFIED, repo README). Treat it as a
proof-of-concept to redo properly, not a drop-in production fix.
and either (a) route PBR texturing through Hunyuan3D-2.1's paint model or a separate open texture
tool (§1.10, §3.5) instead of TRELLIS.2's own bake step, or (b) invest in properly maintaining a
PyTorch3D-swapped fork before relying on TRELLIS.2's textured output in a shipped build. Re-check
this issue thread at benchmark-gate time — Microsoft may resolve it upstream before the 5090
lands.
single RTX 4090 (24GB) exist but describe it as tight/slow (GitHub issue #93, "why did I get stuck
here for so long using the 4090 24g GPU?" — INFERRED, unresolved complaint not a benchmark). Separate
community efforts (ComfyUI quantized paths, off-by-some/TRELLIS-BOX FP16/Docker build) claim
6-8GB / "half the VRAM" — INFERRED, unverified against the official benchmark.
material); 1024³ ≈17s (10s+7s); 1536³ ≈60s (35s+25s). RTX 4090 community reports cluster around
5-10s for comparable settings (INFERRED — no official consumer-GPU benchmark published).
**5090 fit: the 32GB card clears the 24GB floor with real headroom (8GB) that a 4090 does not have
— meaningful for running TRELLIS.2 alongside other services (a ComfyUI queue, a texture pass, an
orchestrating agent) without OOM contention.**
separately trained multi-view model) and multiple GitHub issues (#10, #77, #103) report multi-image
input quality as worse than single-image in practice (VERIFIED — issues exist and describe this;
INFERRED as a general rule since results vary by input). Do not plan a multi-view-first pipeline
around TRELLIS.2.
2.6.0, Python 3.8+); Windows access is via community ComfyUI wrappers only (VERIFIED for Linux-only
claim; INFERRED for Windows-via-ComfyUI as a practical workaround).
all INFERRED/vendor-adjacent, not independent lab benchmarks) as producing the cleanest raw
image-to-3D geometry in the open-source field, and per the Pixazo 2026 leaderboard "Hunyuan3D-2.5 and
TRELLIS are stronger on raw geometry quality" while "Meshy 5 and Tripo 2.5 Pro produce the cleanest
production-ready meshes" — i.e., TRELLIS wins geometry fidelity, loses a bit on out-of-the-box
production cleanliness versus the closed SaaS leaders (INFERRED, single leaderboard source:
https://www.pixazo.ai/models/leaderboard/ai-3d-model-generation).
"production-ready PBR material" (albedo + metallic-roughness) (VERIFIED for the PBR claim and
two-stage architecture from the repo; the exact param counts are INFERRED from secondary sources,
not pinned to the primary README text I fetched).
21GB for texture generation and 29GB for shape and texture generation in total." **This is the
single most important VRAM number in this brief for the 5090 decision: 29GB fits inside 32GB with
~3GB headroom, but does NOT fit a 24GB 4090 running shape+texture in one process.** The 5090 is
effectively the first mainstream consumer card that can run this pipeline's full combined mode
without offloading tricks.
https://github.com/Tencent-Hunyuan/Hunyuan3D-2/blob/main/LICENSE (VERIFIED — fetched primary
source; note this is the 2.0 license text, 2.1 uses the same Community License Agreement template
per the repo's own naming):
month, You must request a license from Tencent, which Tencent may grant in its sole discretion."
license grant entirely.** For a solo dev who may eventually sell into those markets, this needs a
dedicated legal read before ship — it is unclear from the license summary alone whether the
exclusion blocks the developer (if EU/UK/KR-based) from using the model at all, or blocks
*distributing outputs to end users* in those territories, or both. Flag this explicitly for
a real license read (not just this brief) before committing content generated with this model to
a build that will sell in those regions.
generated/distributed content must be labeled as AI-generated. "Powered by Tencent Hunyuan" is
encouraged, not mandatory.
and content harming minors — all easily compatible with this project, just noting they exist.
RTX 4090, turbo mode under 10s (INFERRED — no single authoritative primary benchmark table found;
multiple secondary sources converge on this range).
Hunyuan3D" is open):**
June 23, 2025" across sources — the exact date is INFERRED/inconsistent across secondary sources),
but no model weights have been released. A GitHub issue directly asking Tencent
(https://github.com/Tencent-Hunyuan/Hunyuan3D-2.1/issues/111, opened July 17 2025: "are there
plans to open-source 2.5 and PolyGen models, code, and weights?") remains open with **no official
Tencent response** as of research date (VERIFIED — fetched the issue directly). One third-party
SEO/content site (hunyuan3d.cc) claims 2.5 is open with weights; this directly contradicts the
primary-source GitHub issue evidence, so treat that claim as unreliable and trust the GitHub issue.
(https://docs.comfy.org/tutorials/partner-nodes/hunyuan3d/hunyuan3d-3-0) state the integration
"natively integrated the corresponding Hunyuan 3D API" and requires being "logged in properly and
using a permitted network environment" — i.e., it calls Tencent's hosted service, there are no
local weights (VERIFIED).
(Apache 2.0, open-sourced July 6 2026) and HunyuanImage-3.0 (an image generation model). These
share Tencent's "Hunyuan" branding but are not 3D mesh models — a naming collision that is easy to
conflate in searches and worth flagging so nobody on the team mistakes the open LLM release for an
open 3D-model release (VERIFIED they are distinct products).
generation (VERIFIED to exist; not deeply benchmarked here) — worth a look for rapid iteration/
blockout if 2.1's 29GB combined VRAM is ever a contention problem.
TripoSG-scribble variant accepts a sketch + text prompt (VERIFIED).--faces argument (VERIFIED, e.g. 5000-face example in therepo). No official generation-time benchmark was published in the repo as fetched.
both TRELLIS.2's renderer issue and Hunyuan3D's geo/MAU caps are unacceptable for a given asset.
a new representation called SparseFlex; VAST states they are open-sourcing the pretrained VAE and
inference code, while reserving "the full version" for the closed, paid Tripo 3.0 product.
a building block, not a competitive end-to-end generator on its own. Don't plan around it as a
primary tool; it may be useful as a component if we ever build custom pipeline stages.
https://huggingface.co/stabilityai/stable-fast-3d
https://github.com/Stability-AI/stable-fast-3d/blob/main/LICENSE.md and the HF page) — free for
research, non-commercial, **and commercial use for orgs/individuals with ≤$1,000,000 annual revenue
(any currency, regardless of revenue source)**. Above that threshold, a paid enterprise license from
Stability AI is required before any commercial use of SF3D, derivatives, or outputs.
This is a genuine "flag loudly" case per the mission brief — a solo dev today is almost certainly
under the cap, but a successful shipped game could cross $1M revenue, at which point continued
commercial use of SF3D-touched assets requires a new license Stability grants at its own discretion.
Track this as a standing risk, not a one-time check.
GPU with 7GB VRAM" (VERIFIED, community-summarized from the repo but consistent across sources).
explicit "delighting" post-process step to strip baked-in lighting before the game engine sees it
(VERIFIED, model card language).
true representations of people or events" — intended for artistic/design use, not documentary
accuracy. Reinforces: not the tool for real cultural architecture (§3.4).
hero-asset finishing quality.
non-commercial use" under the same ≤$1M annual revenue threshold; enterprise license required above
it, same standing risk as SF3D.
reconstruction of occluded/unseen geometry than SF3D (INFERRED, from Stability's own announcement
blog — a vendor claim, not independently benchmarked here). No VRAM figure was found in the sources
checked — treat as a gap to fill at benchmark-gate time.
geometry guided by those normals, rather than predicting geometry directly (VERIFIED, paper/repo
description).
precision/sharpest edges among open-source models (INFERRED — consistent across multiple secondary
sources, but no independently-run head-to-head benchmark was located).
Stable-X/ComfyUI-Hi3DGen, VERIFIED to exist).unusable for a specific asset, and raw geometric sharpness matters more than texture (e.g., a hero
weapon blade silhouette, a creature's anatomical correctness before hand-sculpting).
fidelity* tier ("film-grade fidelity for hero assets" per aggregators) — but **there is no open-weight
release of any kind**. It is exclusively a hosted SaaS/API product at hyper3d.ai and via aggregators
like fal.ai (VERIFIED — no GitHub weights repo exists; multiple sources confirm proprietary-only
distribution). Relevant here only as a quality benchmark reference point, not as a candidate for the
local pipeline. If Josh ever wants a closed-SaaS quality ceiling to compare local output against, this
(or Meshy itself) is that ceiling.
releases) is similarly closed/API-only, reported as the speed champion of the closed tier (under 30s)
— same "reference point, not a candidate" status (INFERRED from aggregator positioning).
here" — VERIFIED), and the README does not state a license and does not clearly confirm
pretrained-weight availability (VERIFIED — no LICENSE mentioned, no explicit weights table found in
the fetched content). This sits alongside a documented "Sparc3D controversy"
(https://www.vset3d.com/the-sparc3d-controversy-from-open-source-promise-to-paid-hitem3d-platform/,
INFERRED/secondary but detailed) describing an open-source-first launch (May 2025) that pivoted to a
paid closed platform (Hitem3D, June 2025), with community complaints that the OSS repo is
"open-source in name only" — lacking checkpoints, requiring training from scratch, with free HF demos
since taken down.
approach has (1024³ watertight/manifold meshes is a genuinely useful property), the actual repo as it
exists today does not give you a runnable, licensed, weighted model. If curious, verify directly
against the live repo before spending any engineering time on it — do not trust the aggregator
articles that describe it as a normal open-source option.
own materials state weights, training code, and a curated 2M-asset dataset (from a 5M-asset curation
pipeline) were released (VERIFIED as a vendor claim from the repo/blog descriptions). I did not
independently fetch and quote its LICENSE file the way I did for TRELLIS.2/Hunyuan3D/Stability — treat
its commercial-use status as unverified until someone reads the actual license file before
depending on it.
multi-view sparse-input support) — a solid, unrestricted Apache-2.0 fallback, weaker geometry than
TRELLIS.2/Hi3DGen per aggregator consensus (INFERRED) but zero license friction.
artist-style-mesh retopologizer that converts dense/raw 3D output into lower-poly, better-edge-flow
meshes (max ~1600 faces in V2). This is the one genuinely open, MIT-licensed research component that
overlaps with the "game-readiness gap" (§2) rather than raw generation — worth prototyping as a
pre-Blender cleanup pass.
Repo: https://github.com/buaacyw/MeshAnything (VERIFIED to exist and be MIT-licensed).
QuadGPT, PolyFlow, QuadLink, MeshFIM (all arxiv papers found alongside MeshAnything) are the same
research direction (autoregressive quad/artist-mesh generation) — none confirmed to have a released,
usable open implementation as thorough as MeshAnything; noted for awareness, not recommended yet.
diffusion/latent approaches; output point clouds or implicit functions that need extra conversion
work to become a standard mesh. Not competitive for this project; mentioned only for completeness.
arxiv, dated Sept 2025-Dec 2025) explore next-generation ideas (test-time spatial control,
multi-image fusion, unified geometry-appearance latents) but **none had a confirmed public code/weight
release** as of this research pass — worth a re-check at benchmark-gate time in case one has shipped
by then, but not actionable today.
---
The clearest statement of the problem is a 2025 research paper, **"Hunyuan3D Studio: End-to-End AI
Pipeline for Game-Ready 3D Asset Generation"** (arxiv 2509.12815,
https://arxiv.org/html/2509.12815v1). Directly quoted: the field "continues to struggle with
integrating these advances into assets that simultaneously meet the dual demands of high visual
fidelity and technical readiness for real-time rendering in game engines," and existing tools mostly
"address only isolated pipeline stages, leaving artists with the challenging task of integrating and
refining these outputs into a usable, performant asset."
Their proposed (research-only) pipeline is instructive because it names the actual missing pieces:
1. Controllable image generation (style/pose standardization)
2. High-fidelity geometry generation
3. Part-level decomposition (semantic separation of an object into functional components)
4. PolyGen — an autoregressive model that retopologizes into "low-polygon assets with low vertex
counts and well-structured, deformation-aware edge flow" (i.e., automated game-ready retopology)
5. SeamGPT — semantic/context-aware UV unwrapping via "artist-style cutting seams"
6. PBR texture synthesis
7. Skeleton rigging/skinning
Critical finding: this is a research paper with no released code or weights (VERIFIED — no GitHub
repo, no HuggingFace model found for PolyGen/SeamGPT as standalone tools; recall from §1.2 that even
Hunyuan3D-2.5/PolyGen's weights were explicitly asked about by the community and never released). **LODs
and collision generation are not addressed even in this research-only pipeline.** This tells us
definitively: **there is no mature, released, open AI system that automates retopology + UVs + LODs +
collision end-to-end today.** The gap is real and current, not just under-documented.
Given no end-to-end AI solution exists, the practical path is scripted Blender + human QC:
blender.exe --background --python <script> gives full access toBlender's Python API for retopology (Decimate modifier / remesh), UV unwrapping, texture baking, and
export, callable from any external process including an agent pipeline (VERIFIED, standard Blender
CLI behavior).
exporting each LOD as a separate FBX or packing them into one FBX using Unreal's recognized
_LOD0/_LOD1/... suffix convention, which UE's import pipeline auto-detects (VERIFIED, standard UE
import behavior referenced across multiple sources).
cleanup, and polygon reduction, with a companion free UE5 "mesh conditioning" plugin (VERIFIED to
exist; pricing/license not independently checked here).
prototyping as an automated first pass before Quadify/manual cleanup, capped around 1600 faces in V2,
so best suited to props/hero objects rather than high-density environment meshes.
blender_execute_script, blender_import_model, blender_export_model, etc.) as callable tools, with 13,700+ GitHub stars
(VERIFIED to exist and be popular per https://snyk.io/articles/top-claude-skills-3d-modeling-game-dev-shader-programming/).
This is the natural integration point for an agent-driven pipeline: an agent (Claude Code or
otherwise) can drive "import generated mesh → decimate to N LOD levels → bake AO/normal → export
UE-named FBX" as a scripted, repeatable tool-call sequence rather than a manual DCC session.
with auto-generated LODs, plus a documented Python API for headless export and custom naming
(VERIFIED to exist per multiple 2026 dev-blog sources; treat specifics as INFERRED/community-sourced
since I did not fetch its own docs directly).
LODs on static geometry by ingesting much denser meshes directly; UE5.8 also integrates Nanite with
the new Mesh Terrain toolset "to preserve real-time performance when rendering very large textured
meshes" (VERIFIED quote from CG Channel's UE5.8 feature coverage). This matters for props/environment
set-dressing (less LOD-chain engineering needed for static, non-deforming meshes) but does not
help with UV/collision/retopology needs for skinned or gameplay-interactive meshes, and Nanite has its
own constraints (no skeletal mesh support in the general case as of this research pass — verify
current UE5.8 Nanite-skeletal-mesh status directly before assuming it covers creatures/NPCs).
impostors, material merging, occlusion culling, UV unwrapping, texture baking all automated; InstaLOD
2026 shipped February 2026 with a reworked Quad Remesh system, VERIFIED to exist and be actively
developed per CG Channel/InstaLOD's own release notes). Useful as the quality bar to compare open
tooling against, and worth a licensing-cost look if the Blender-scripted path proves too slow/manual
at volume — but it is explicitly not open source, so it sits outside this brief's scope except as
a reference point.
Bottom line for §2: budget real engineering time for a Blender-headless "finishing pipeline"
(decimate/retopo pass, optional MeshAnything pre-pass, UV unwrap, LOD chain export, collision hull
generation via Blender's convex-hull tools) as a first-class deliverable, not an afterthought — because
no open AI tool does this end-to-end yet, and the one research system that attempted it (Hunyuan3D
Studio) never shipped code.
---
The task brief named five explicit classes plus texture generation; the sibling doc
docs/pipeline_review/STACK_FACTS_QUESTIONS.md (Q3) names seven ("weapons, creatures, familiars, NPCs,
vril sites, architecture, special-asset-class"). This section covers the five explicit ones in depth and
folds familiars/special-asset-class in briefly at the end — this is my own synthesis applying the
verified model facts above to the project's needs (ANALYSIS, not an external verified fact).
Best fit of any category for current open image-to-3D models — these are exactly the object-scale,
single-item, well-lit-reference inputs these models were trained on. Recommended approach: generate
candidates from both TRELLIS.2 (geometry) and Hunyuan3D-2.1 (if texture matters immediately) per hero
weapon, pick the cleaner result, always finish with a manual retopology/UV pass regardless of source
(§2) since 72 is a small enough count to afford hand-finishing every one. Hi3DGen as a sharper-geometry
fallback for blades/mechanically precise silhouettes.
Good geometric fit (single-subject, clear silhouette), but rigging is a **separate, unsolved-by-these-
models step** — none of the generators in §1 produce a rig or skin weights. For non-humanoid rigging,
open/free options found: Blender Rigify (built into Blender, free, humanoid-biased but extensible),
MakeHuman (free/open, humanoid-focused, less useful for true creature anatomy). Commercial
point-solutions worth knowing about even though they're SaaS not open-source: Tripo AI's "universal rig"
(explicitly advertised as working across humanoid-to-creature ranges) and Reallusion AccuRIG 2 (has a
free tier), plus a newer entrant "Sorceress" advertising real-time IK-driven procedural walk cycles for
non-biped creatures (spiders, quadrupeds, dragons) — none of these are open-source, flagged here only
because 132 creatures is enough volume that a paid-but-cheap per-asset rigging tool may be worth it even
inside an otherwise "open-source only" pipeline. Recommend: generate geometry locally (free), rig via
whichever of these point-solutions tests best at benchmark-gate time (cost is per-asset-cheap relative
to 132 creatures' total budget, unlike the SaaS-generation cost this whole effort is trying to escape).
Generative image/text-to-3D is the wrong tool for human NPCs. MetaHuman remains the correct base:
fully rigged, facial blend shapes, animation-ready skeletons, and (per Epic's own 2026 roadmap) an
explicit MetaHuman Crowd system landing to handle large-scale NPC populations efficiently
(experimental, targeted for the UE 5.8 cycle per CG Channel's coverage — VERIFIED as announced,
INFERRED on exact ship timing). **Time-sensitive operational note, independent of the 3D-gen question
but directly relevant to any NPC pipeline planning:** Epic is discontinuing the standalone browser-based
MetaHuman Creator web app on a staged 2026 timeline — UE 4.27-5.1 support already dropped (April 5,
2026), UE 5.2-5.4 support drops June 5 2026, and the whole web app shuts down November 5, 2026, with a
90-day asset-retrieval window after that before deletion (VERIFIED via multiple 2026 dev-community
sources, cross-referenced against each other — no single Epic press release was directly fetched, so
mark the exact dates INFERRED-but-corroborated). Character creation moves fully in-Unreal-Engine
(native since UE 5.6). **Action item independent of this brief's core mission: make sure any existing
or planned MetaHumans are built/migrated via the in-engine creator (UE 5.6+), not the sunsetting web
app, before November 2026.** Generative 3D models' role for NPCs is limited to non-MetaHuman-fitting
cases: stylized non-photoreal NPCs, or props/gear the NPCs carry (which then falls under the
weapons/props case, §3.1).
Weakest fit, and this is a §17.1 care-relevant tooling choice, not just a quality one. Verified
research consensus (from an architecture-focused generative-AI literature search, §1 sources): these
models are trained on object-scale datasets (Objaverse-class — confirmed for SF3D specifically), "AI
models suited for simple and easily categorizable everyday objects cannot be directly applied to
architectural generation," buildings get rendered "in an empty scene which does not occur in the real
world," and no dedicated high-quality 3D building-asset corpus exists at scale (INFERRED synthesis from
multiple architecture-generation papers found in research, not a single authoritative source — treat
the general conclusion as well-supported, the specific phrasing as illustrative). Stability's own SF3D
model card explicitly disclaims factual/documentary accuracy. Combine that with the project's own care
doctrine (CVD §17.1: represent-with-care for living peoples/cultures, including their built heritage)
and the case against raw-generating real cultural buildings is both a quality argument and a care
argument: a hallucinated diffusion-model guess at a real temple's structure risks getting real, living
cultural heritage wrong in a way that a hand-modeled or photogrammetry-referenced asset would not. **This
is a recommendation, not a canon ruling** — flagging it here because it touches §17.1, but the actual
call on production method for real-world cultural architecture belongs with whoever owns the art
pipeline decision, informed by this research. Recommended default: use generative models at most for
rough blockout/massing exploration, source the finished asset from reference-photo-grounded modeling,
photogrammetry, or licensed kit assets, never ship a raw-generated real sacred/cultural building.
Best-case category alongside weapons — no real-world accuracy constraint means the models' tendency to
interpolate/hallucinate creatively is a feature, not a risk. TRELLIS.2 and Hunyuan3D-2.1 both suit this
well; this is exactly where to spend the "creative freedom" budget of these generators.
armory3d/armorlab) — open-source AI-assisted PBR texture authoring, runs fully local, free to
compile from source under a permissive license (compiled binaries cost $19 to fund the project, but
the source is free and open per its LICENSE.md — VERIFIED via direct fetch of the repo/license page).
Part of the Armory3D open game-engine ecosystem.
estimation from text/image inputs, debuted at SIGGRAPH Asia 2025
(https://www.ubisoft.com/en-us/studio/laforge/news/1i3YOvQX2iArLlScBPqBZs/ — VERIFIED to exist as
announced; maturity/completeness of the actual released code not independently verified here).
output (§1.2) — likely the most production-ready "free" texture source given it's already in the
pipeline for textured hero assets.
generator) were both found as free/open options for supplementary texture work (VERIFIED to exist;
not deeply evaluated here).
Hunyuan3D-2.1's built-in paint stage plus ArmorLab for hand-authored touch-ups — this is a "good
enough, don't over-invest" area relative to the mesh-generation question.
Not separately researched in depth — familiars (22 slots per project numerical canon) read as a subset
of the creature pipeline (§3.2) at smaller scale, likely simpler/more stylized, same tooling applies.
"Special-asset-class" is too undefined in the source material to research specifically; treat it as
inheriting whichever of weapons/props (§3.1) or creatures (§3.2) it resembles case-by-case at build
time.
---
Three real layers exist today, in increasing order of "already built for us":
1. Bare Python / official repo scripts — every model in §1 that has released weights ships (or has
a community-built) a direct inference entry point: TRELLIS.2 and TripoSG both ship official
gradio_app.py demos; Hunyuan3D-2/2.1 ships an official gradio_app.py
(https://github.com/Tencent-Hunyuan/Hunyuan3D-2/blob/main/gradio_app.py) and a documented
api_server.py + batch pattern — a community script,
smysnk/Hunyuan3D-2-batch (https://github.com/smysnk/Hunyuan3D-2-batch), runs the official API
server and drives it with a generate_glb.py that takes an input folder of images and batch-produces
GLBs with configurable octree resolution/inference steps/face count/guidance scale (VERIFIED, repo
exists with this described workflow). This is the most direct "agent calls a local REST-ish endpoint"
pattern available today, and the cleanest to wire an agent pipeline into without adopting a heavier
dependency.
2. ComfyUI — the de facto local aggregator for these models. ComfyUI-3D-Pack
(https://github.com/MrForExample/ComfyUI-3D-Pack) is a broad node suite covering TRELLIS, Hunyuan3D,
and TripoSG in one place (VERIFIED to exist and cover these models); dedicated wrappers also exist
(visualbruno/ComfyUI-Trellis2, Stable-X/ComfyUI-Hi3DGen, Tencent's own Hunyuan3D ComfyUI
integration). ComfyUI workflows are themselves JSON graphs runnable via ComfyUI's own server API, so
an agent can POST a saved workflow and poll for the output file — a solid middle ground between raw
scripts and a full custom service, and valuable because it also lets image-generation (SDXL/Flux) →
3D-generation → texture-bake chain inside one tool without gluing three separate CLIs together
(VERIFIED as a described/common pattern across multiple 2026 ComfyUI-3D guides).
3. Blender MCP (§2.2) — the natural place for the *post-generation* half of the pipeline
(import → decimate/retopo → UV → LOD export → collision), already built as an MCP server an
agent (including this kind of Claude Code session) can call directly as tools, with 13,700+ GitHub
stars indicating real community maturity (VERIFIED to exist and be popular).
Recommended shape: an agent pipeline calls a Hunyuan3D-2.1 (or TRELLIS.2) local API-server process
for generation (pattern 1, simplest to keep stable and debuggable), or a ComfyUI workflow if the
image-gen → 3D → texture chain needs to be one call (pattern 2), then hands the raw GLB/FBX to a
Blender-headless script or Blender MCP session for the game-readiness finishing pass (§2). None of this
requires proprietary aggregators (fal.ai/Replicate) which exist but reintroduce the SaaS-cost problem
this whole effort is meant to escape — they're mentioned in the research only as comparison points, not
recommended.
---
Every generation-time and VRAM number in §1 that isn't marked VERIFIED-from-official-repo is a
secondary/community report, often on different hardware, different settings, and sometimes internally
inconsistent (e.g., Hunyuan3D-2.5 both "released" and "not released" depending on the source, §1.2). The
license landscape can also shift between now and hardware arrival (Microsoft could patch the
nvdiffrast/nvdiffrec dependency; Tencent could open 2.5). **Treat §0's verdict as the default to start
benchmarking from, not the final answer** — exactly the posture already recommended in
STACK_FACTS_QUESTIONS.md Q3 ("pick-at-build-time with a benchmark gate").
1. Re-check licenses/releases first (cheap, do before any GPU time): re-fetch
microsoft/TRELLIS.2 issue #22, Tencent-Hunyuan/Hunyuan3D-2.1 issue #111, and check whether
Hunyuan3D 2.5/3.x or a maintained TRELLIS.2-PyTorch3D fork has shipped open weights since this
brief was written (2026-07-15).
2. Fixed test set, 2 assets per class minimum: 2 hero weapons (one organic-curve, one
hard-surface/mechanical), 2 creatures (one quadruped, one non-standard anatomy), 1 vril-site
structure, 1 real-world architecture test **specifically to confirm the "don't use gen for real
buildings" call rather than to greenlight it**, 2 texture-only tests (one material-from-photo, one
text-to-material).
3. Run through TRELLIS.2, Hunyuan3D-2.1, and Hi3DGen at minimum (the three MIT/production-PBR-
capable leaders), TripoSG as the no-asterisks baseline, SF3D/SPAR3D if sub-second blockout speed
matters for a given class.
4. Score each on: wall-clock generation time on the actual 5090 (not the H100/4090 numbers in this
brief), peak VRAM observed, raw topology quality (subjective 1-5 + "minutes of manual retopology
needed to reach game-ready"), UV quality out of the box, PBR channel accuracy vs the reference photo/
concept art, and — critically — whether the license actually clears for the specific asset's
intended commercial use (re-run the MAU/revenue-threshold math, not just at day one but projected).
5. Output of the gate: a per-category default (this may land exactly on §0's split, or may not —
that's the point of gating empirically rather than trusting this desk review alone), plus a measured
"time to game-ready" number per category that feeds real production scheduling, not just a
generation-speed number.
---
https://www.3daistudio.com/state-of-ai-3d-generation-2026 ·
https://www.pixazo.ai/blog/best-open-source-3d-model-generation-apis ·
https://www.pixazo.ai/models/leaderboard/ai-3d-model-generation ·
https://www.vset3d.com/the-sparc3d-controversy-from-open-source-promise-to-paid-hitem3d-platform/ ·
https://hunyuan3d.cc/hunyuan3d-versions/ (contradicted by primary-source GitHub issue evidence on 2.5 —
kept only to show the conflict) · https://www.tripo3d.ai/blog/vast-open-source-month ·
https://www.strayspark.studio/blog/metahuman-2026-web-app-shutdown-migration-guide (403'd on direct
fetch; corroborated via multiple independent secondary sources instead) ·
various 2026 dev-blog/SEO-content sites on Blender-to-Unreal pipelines, Mixamo alternatives, and RTX
5090 benchmarks, none individually load-bearing on their own — cross-checked against at least one other
source before inclusion above.