img2threejs: The Code-First Path from a Single Image to a 110k-Triangle, 27-Animation 3D Model in the Browser

What img2threejs Actually Produces

When you ask img2threejs to reconstruct a monster from a single 2D image, it hands you back a TypeScript factory function and a sculpt specification, not a .glb file. The factory returns a THREE.Group — a fully constructed scene graph with hierarchical transforms, procedural geometry, custom materials, and animation hooks already wired in. There are no binary assets, no UV texture maps, no external mesh payloads. The entire 3D model compiles with your application bundle, which means the "asset" is a few kilobytes of human-readable source code and it lives directly in git.

What does that mean in practice? The Abyss Monster exhibit — a single 2D reference image transformed into a demonic creature running live in a browser — carries 110,745 triangles and 27 distinct animation states. Every one of those triangles is generated at runtime by executing mathematical expressions: parametric curves, lathe profiles, CSG booleans, and subdivided primitives. The code defines not just the geometry but the hierarchy—root transform, torso, limbs, appendages—each articulated with explicit pivot points so the model can bend, sway, and attack without needing separate bone-skinning passes.

The sculpt specification is the contract that drives production: it lists parts, joints, materials, and a target triangle budget. The factory turns that specification into a live THREE.Group whose every parameter—vertex position, shader line, animation timing—is mutable code you can edit and review like any other source file.

A crucial consequence: there is no black box to deconstruct when something looks wrong. If a tentacle clips through the chest during an attack animation, you don't open Blender to retopologize. You find the offending rotation math in the TypeScript and correct it in a pull request. If a material isn't reading correctly across GPUs, you adjust the shader and re-run the generation loop. This is a fundamentally different relationship with your 3D asset than the binary pipelines offer.

sequenceDiagram
    participant User as Developer
    participant Agent as AI Agent
    participant Factory as TypeScript Factory
    participant Runtime as Browser Runtime

    User->>Agent: Provide 2D image input
    Agent->>Agent: Validate image & generate sculpt contract
    Agent->>Factory: Execute staged procedural construction
    Factory->>Factory: Build scene graph & pivot tree
    Factory->>Runtime: Generate 110,745 triangles procedurally
    Factory->>Runtime: Configure 27 animation states
    Runtime->>Runtime: Render live 3D monster in browser
    Agent->>Factory: Render synthetic multi-angle views
    Agent->>Factory: Compare renders vs reference image
    Agent->>Factory: Refine code parameters iteratively
    Factory->>User: Return final TypeScript factory module

The output is a deterministic, git-trackable artifact. Every vertex, pivot, and shader is inspectable, testable, and deployable. That alone distinguishes it from any pipeline that emits opaque binary meshes. But it also means the model's fidelity is bounded by what mathematical primitives can express — a tradeoff I'll dig into later.

The Multi-Pass Agentic Workflow: From Pixels to Procedural Parameters

img2threejs doesn't generate a model in a single forward pass like a neural mesh generator does. It runs as a multi-pass agentic loop—what I'd call a vision-guided iterative sculptor. Each pass produces structured code that the next pass builds upon, and at the end of each cycle, the agent renders synthetic views and inspects them against the original reference image. The loop closes when the renders converge on the target.

Pass 1: Input Analysis and Contract Generation. The agent validates the input image and establishes the sculpt/quality contract. This is not a vague prompt—it's a structured document listing every part of the model (torso, arms, wings, teeth), the joints that will articulate, the materials to apply, and a triangle budget. For the Abyss Monster, that contract includes ~110,745 triangles as the target ceiling. This contract becomes the source of truth for all subsequent passes. Any ambiguity here—missing limb, unclear joint placement—propagates downstream as hallucinated geometry.

Pass 2: Blockout. The agent builds hierarchical bounding volumes and establishes the bone/pivot tree. This stage is structural, not visual. It places each body part in space: root at the base, spine extending upward, limbs branching outward. Each pivot point gets an explicit position and rotation axis. This is where the model's skeleton emerges—not as SkinnedMesh weights, but as a parented Group hierarchy where each joint is a transform node. Getting pivot placement right here is critical; later animation states depend entirely on it. Misaligned pivots produce jittery rotations at runtime, which is the professional failure mode I'd flag for ad hoc reconstructions.

Pass 3: Structure and Form. This is the meat of the generation. The agent builds actual geometry using parametric curves, extrusions, lathe operations, CSG booleans, and subdivided primitives. For a monster with organic tentacles, it might use a lathe profile swept along a curve; for the jagged rock-like carapace, it might boolean-subtract primitives from a subdivided sphere. The goal is to reach high triangle counts—100,000+ for complex models—without exceeding the contract budget or producing non-manifold geometry. This pass is iterative: the agent generates geometry, renders it, sees a self-intersection, adjusts the curve, re-renders. The feedback loop is what makes procedural generation converge on something visually coherent.

Pass 4: Materials and Lighting. The agent configures PBR materials, sets up custom vertex/fragment shader hooks, and applies normal or displacement setups. For the Abyss Monster, this might include procedural noise for skin roughness, emissive windows for eyes, and custom shaders for the glinting scales. Multi-angle inspection is especially important here because shader artifacts—flickering normals, incorrect lighting falloff—often appear only from certain angles.

Pass 5: Rigging and Animation. With the geometry and pivots in place, the agent writes the procedural kinematics: parameter-driven morphs and discrete animation states. The Abyss Monster's 27 states likely include idle cycles, walk loops, attack strikes, hit reactions, and death sequences. Each state is a set of rotation/position values applied to the pivot tree. Interrupting one state mid-blend requires exponential interpolation logic to mix into the next. This is where the absence of a standard Animation Mixer becomes apparent—the agent must implement its own blending or the transitions snap.

Final Pass: Vision Verification. The agent renders synthetic views from multiple camera angles—front, side, back, and three-quarter—and inspects them against the reference image using a multimodal model. It then refines code parameters: adjusting a curve control point to fix a silhouette mismatch, tweaking a pivot angle to correct an elbow bend, modifying a shader value to match the reference's material tone. This loop is what sets img2threejs apart from a single-shot code generation script. It's also the most expensive part of the pipeline, consuming thousands of output tokens and multiple high-resolution vision API calls per refinement cycle.

flowchart TD
    A[Input Image] --> B[Contract Generation<br/>parts, joints, materials, triangle budget]
    B --> C[Blockout<br/>bounding volumes, pivot tree]
    C --> D[Structure & Form<br/>parametric curves, extrusion, lathe, CSG, subdivision]
    D --> E[Materials & Lighting<br/>PBR, shader hooks]
    E --> F[Rigging & Animation<br/>procedural kinematics, animation states]
    F --> G[Vision Verification<br/>multi-angle renders vs reference]
    G --> H{Converged?}
    H -->|No| C
    H -->|Yes| I[Final TypeScript Factory]

The loop closes when the rendered views match the reference within acceptable tolerance. The cost is real, though—generation takes minutes, not seconds—and small visual discrepancies can trigger regression loops where fixing one angle breaks another. That's the price of code-only outputs with total runtime mutability.

Why Not a Neural Mesh Generator? The Four Paradigms Compared

img2threejs operates in the single-view 2D-to-3D space, but its architectural philosophy diverges sharply from mainstream solutions. To understand where it fits, I'll compare it against the three dominant paradigms: neural feedforward mesh generation, neural radiance/splatting, and displacement/relief approaches—plus the generic agentic code loop it belongs to.

Neural feedforward mesh generators (Trellis from Microsoft Research, Rodin/Deemos, Meshy AI, Tripo3D, Common Sense Machines, Meta's SAM3D) use Large Reconstruction Models or 3D diffusion to infer geometry and texture from an image in a single forward pass. They emit standard binary mesh files—.glb, .gltf, .obj—with pre-baked UV texture maps and explicit vertex buffers. This is the fastest path from image to 3D: 5–60 seconds of inference, high photorealism, exact UV maps. But the output is opaque. You cannot inspect or edit a .glb without DCC tools like Blender. Rigging requires a separate auto-rigging post-pass, and the mesh is static until you add skeletal deformation.

Neural radiance fields and Gaussian splats (Luma Genie, Splatfacto/nerfstudio) represent the scene as continuous volumetric fields or millions of colored Gaussian ellipsoids. Luma and Splatfacto support real-time WebGL/WebGPU rendering, but the output formats—.ply, .splat—require specialized custom rasterizers. Photorealism is found at its peak here, particularly view-dependent effects like specular highlights. Yet payloads are heavy: 15–100MB+ for a single model. Rigging for animation is non-trivial to impossible without deformation fields or cage bindings, and there's no vertex-level editability. This is a visualization tool, not an animation platform.

Displacement/relief approaches (Picto3D, Map33.js, standard Three.js displacementMap with monocular depth estimation) project 2D depth estimations onto subdivided plane grids or lathe geometries. They're cheap (<1 second generation, 1–5MB payload) but produce static 2.5D reliefs—frontal-only projections with no meaningful backside or volume. They work well for parallax effects in web design, but they aren't real 3D models.

img2threejs and its peer class—generic AI-agent loops prompting Claude or GPT-4o to write raw Three.js code—take the fourth path. They decompose shapes into mathematical primitives, parametric sweeps, CSG operations, custom GLSL shaders, and programmatic animation loops, all expressed as human-readable TypeScript. img2threejs distinguishes itself by making this a structured, multi-pass process with a visual feedback loop, rather than a single-shot prompt. The output is a code-only factory that compiles with the application bundle.

In a broad sense, what the comparison exposes is not better-or-worse but a different tradeoff axis. Neural generators trade control and mutability for speed and photorealism. img2threejs trades generation speed and organic fidelity for total runtime inspectability and native animation. The table below captures the tradeoffs.

Feature / Tradeoff	img2threejs	Neural Mesh Gen (Trellis, Rodin, Meshy, Tripo3D)	Neural Splatting (Luma, Splatfacto)	Displacement/Relief (Picto3D, Map33.js)
Output Deliverable	TypeScript factory (THREE.Group)	Binary mesh (.glb, .gltf, .obj)	Point-cloud/Splat data (.ply, .splat)	Subdivided plane + texture map
Asset Size / Payload	Ultra-low (KB of code)	Moderate to Heavy (10–60MB+)	Heavy (15–100MB+)	Low to Moderate (1–5MB)
Rigging & Kinematics	Native, code-parametric (pivots, joint hierarchy, logic hooks)	Requires auto-rigging post-pass (Mixamo, AccuRig) or static	Non-trivial (deformation fields / cage bindings)	N/A (static relief only)
Organic Visual Fidelity	Stylized / Mathematically approximate	High / Photorealistic	Ultra-high photorealism	Low (frontal 2.5D projection)
Generation Time & Cost	High (multi-turn agent passes, minutes of LLM inference)	Low / Fast (single-pass neural inference: 5–60 sec)	Fast to Moderate (10–90 sec)	Instant (<1 sec)
Runtime Mutability & Inspectability	Complete (every vertex, parameter, shader line, pivot modifiable in git)	Opaque / black-box (requires Blender or Maya to alter)	Opaque (difficult to isolate or edit geometry)	Partial (shader parameters only)

The tradeoff matrix tells the story plainly: img2threejs is the only approach that gives you complete runtime mutability and native animation, and the only one where the entire asset lives in your git repository. But it's also the only one that bounds visual fidelity by what mathematical primitives can approximate. For the Abyss Monster—a stylized, monstrous creature well-suited to procedural geometry—that constraint is acceptable. For a photorealistic human face, it isn't.

Where I'd reach for img2threejs: interactive web experiences, game assets with tight bundle budgets, anything requiring deterministic, reviewable 3D in a browser. Where I wouldn't: film-grade VFX, production pipelines needing photorealistic output, or any scenario where human faces must be reconstructed faithfully from a single view.

Where the Procedure Breaks: Organic Geometry, Occlusion, and Animation Drift

The first place I'd expect img2threejs to stumble is the organic mesh gap. Procedural geometry is fundamentally a language of mathematical primitives—lathe profiles, parametric sweeps, CSG booleans, subdivided spheres. These are excellent at expressing mechanical hard-surface forms: armor plates, crystalline carapaces, angular spikes, stylized creature silhouettes. They're terrible at expressing the micro-detail that makes something feel organic. Wrinkles along a knuckle, the flow of fur across a shoulder, asymmetric cloth folds, the irregular ridges of a human face—none of these decompose cleanly into curves and booleans. When you push a parametric system toward that territory, you get what I'd call mathematical hallucination: the model produces a plausible-looking approximation that reads as wrong the moment you inspect it closely. The Abyss Monster works because it's a stylized demonic creature, not a photoreal face.

There's a second-order problem lurking in the triangle budget. High triangle counts don't buy fidelity if the geometry is unhealthy. Pushing toward 110,000+ triangles via subdivision or repeated boolean operations frequently produces non-manifold edges, duplicate coplanar vertices, inverted normals, and self-intersecting hulls. In a traditional DCC pipeline, Blender's remesh and cleanup tools handle this in seconds. In img2threejs, those pathologies live in the generated TypeScript—they compile fine, render fine from hero angles, and then explode when you orbit to inspect a seam. You've traded a cleanup pass in Blender for debug cycles in code.

The next failure mode is single-view occlusion. A 2D input gives you exactly one side of the creature. Everything behind the torso, inside the mouth, under the wings is a guess. The agent reasons about symmetry and expected anatomy, but the backside frequently comes out hollow, oversimplified, or geometrically mismatched when inspected from non-hero angles. Intertwined limbs and ambiguous foreshortening compound this: when limbs overlap in the reference, bounding-box extraction and joint-graph construction struggle to disambiguate which appendage belongs to which pivot. The result is a broken hierarchy that shows up as limbs rotating around the wrong origin.

The animation story is where I'd be most cautious. img2threejs rigs via parented Group hierarchies and programmatic rotation math rather than bone-weighted vertex skinning. That's fine for stylized creatures with segmented anatomy. It's brittle for smooth deformation. Extreme rotations cause mesh tearing or creasing at articulation seams—elbows, knees, tentacle bases—because vertices aren't blended across joints. And with 27 animation states defined procedurally, blending between them without a standard state machine or Animation Mixer invites jerky transitions, foot-sliding, and kinematic drift. Interrupting an attack mid-swing requires interpolation logic the agent must implement itself; if it does that poorly, the model slides through the floor.

The root issue is that animation quality depends on discipline the procedural pipeline doesn't enforce. Pivots get placed correctly, animations get written, but the blending between states is left to ad-hoc math. That's a production risk.

Client-Side Runtime Costs: The Main-Thread Freeze and Cross-GPU Shader Divergence

Here's the tradeoff that stings: img2threejs shifts the payload cost from network bandwidth to the client's CPU. A binary .glb parses directly into GPU memory through fast ArrayBuffers. The procedural factory executes thousands of lines of TypeScript on the browser's main thread to compute vertices, normals, UV unwrap math, and CSG booleans. For the Abyss Monster at 110,745 triangles, that's not a trivial computation. On a modern desktop it's noticeable; on mobile or lower-end devices it's a visible freeze during mount. The user watches a white screen while the monster assembles itself from math.

The fix is straightforward but requires engineering intent: offload mesh generation to a Web Worker and initialize geometry asynchronously before adding the factory's output to the active Three.js scene. Alternatively, precompute the geometry at build time and serialize the resulting buffers to a cached structure the factory loads at runtime. Either approach converts a first-render stall into a non-event. The agentic pipeline doesn't do this by default, which means it's your responsibility as the integrating team.

Shader divergence is subtler. Custom vertex/fragment shaders, procedural noise functions, and screen-space effects depend on floating-point precision and WebGL capability tiers that vary across GPU vendors. Apple Silicon's Metal/ANGLE stack, Qualcomm's Adreno, and desktop Nvidia/AMD parts all treat certain operations differently. A noise function that renders beautifully on a MacBook might alias or flicker on an Adreno-based Android device. Normal mapping with high-frequency procedural displacement is especially vulnerable. I'd establish a device-fidelity test matrix early rather than discovering the problem in user reports.

Draw calls are the third trap. If the factory generates separate geometry and unique material instances for each limb, appendage, or tooth, the draw-call count scales linearly with the model's component count. A monster built from hundreds of articulated parts can easily push mobile frame rates off a cliff. Batching static sub-geometries via BufferGeometryUtils.mergeGeometries, instancing repeated elements, and deduplicating shared materials are all necessary post-processing steps before the model goes anywhere near production. None of these come free with the procedural pipeline.

The Agentic Generation Cost: Token Burn and Feedback Loop Saturation

The generation path for img2threejs is expensive in a way neural generators aren't. A single forward pass through Trellis or Meshy takes 5–60 seconds of inference. img2threejs runs a multi-turn agent loop: contract generation, five structured construction passes, then multiple vision-verification cycles where the agent renders synthetic multi-angle views and feeds them back into a multimodal model for inspection. Each refinement cycle consumes thousands of output tokens and multiple high-resolution vision API calls. The result is generation measured in minutes, not seconds, and a token footprint that makes one-off experimentation costly.

The feedback loop has a saturation problem that I'd watch carefully. The vision verification step flags small discrepancies—a silhouette mismatch, an incorrect elbow bend, a material tone shift. The agent fixes one by modifying a parameter. But parametric systems are tightly coupled. Adjusting a curve control point to fix the front silhouette can break the three-quarter view. Correcting a pivot angle for one limb can shift the balance point for an adjacent appendage. The agent then tries to fix that regression, which cascades into another. Left unchecked, the loop oscillates: fixing one angle breaks another, and the agent burns tokens converging on a solution that never quite stabilizes.

This is the practical ceiling on procedural reconstruction from a single view. Neural generators are also constrained by the input, but their failure modes are bounded—they produce a static mesh with whatever artifacts the model has, and you pay once. The agentic loop's failure mode is unbounded iteration. It will keep trying to fix that backside guess, generating more passes, more tokens, more latency, until you cut the budget and ship the version from three refinements ago.

For production integration, I'd cap the refinement passes explicitly. Define a maximum vision-verification cycle count, accept the best render at that point, and move on. The marginal improvement after two or three cycles tends to be minimal, and the token cost compounds.

For tying this back to the broader ecosystem landscape, the nearest entry I'd reference is the work on Ponytail and the Source Priority Ladder, which directly addresses agent anti-bloat mechanisms—a relevant lens for considering when img2threejs's architectural discipline translates into production value versus cost. Similarly, Canvas UI frames the GPU-accelerated rendering considerations that become critical here given the runtime costs I've outlined.

From Prototype to Production: Packaging, Performance, and Quality Gates

The raw output of img2threejs is TypeScript, not .gltf or .usd. That's the central integration challenge for any team that wants to ship this in a real product. If your target is a browser-based experience built on Three.js, the factory slots directly in—you just execute it and add the resulting THREE.Group to your scene. But if your target is Unity or Unreal, or if you need the model to pass through standard 3D pipelines for any reason, you need a baking step. I'd run the TypeScript factory in headless Puppeteer, render the complete model with all animation states, and export a standard .glb with animation clips. That gives you the best of both worlds: the agentic generation loop produces the code, and the export converts it into something the rest of your tooling already understands.

The runtime performance work is non-negotiable. As I noted earlier, the main-thread freeze during procedural generation compounds as models scale to 100,000+ triangles. Wrapping the generation logic in a Web Worker with OffscreenCanvas offloads the math from the UI thread and keeps the experience responsive while the model assembles itself. This isn't a theoretical optimization; it's the difference between a polished product and a janky one. You should also post-process whatever the factory produces: merge static sub-geometries with BufferGeometryUtils.mergeGeometries, index vertices to reduce memory footprint, and deduplicate shared materials to control draw call counts. A monster built from hundreds of articulated parts will otherwise fragment draw calls badly on mobile GPUs.

Quality gates are where you build trust in a pipeline that generates code at generation time. I'd implement automated multi-view screenshot regression tests: render the model from front, side, back, and three-quarter angles, compare against a canonical set of approved renders, and fail the build if any view drifts beyond tolerance. Add triangle count caps to enforce the contract budget, manifold checks to catch non-manifold edges before they render at production, and pivot-limit constraints to prevent the agent from generating rotation axes that break the hierarchy. These gates catch the pathologies I've flagged—self-intersecting hulls, broken backside geometry, wrong joint origins—before they reach users.

The animation layer requires an FSM. With 27 procedurally defined states, you cannot rely on the factory's ad-hoc blending. Build a finite state machine around the factory's output, define transitions between idle, walk, attack, and hit states, and blend using spherical linear interpolation (slerp) to avoid the kinematic drift and foot-sliding that raw rotation math produces. The FSM gives you deterministic interrupt behavior—you control what happens when an attack is cancelled mid-swing, rather than hoping the procedural interpolation handles it gracefully.

For concrete inspiration: imagine a web game studio building an Image-to-Animated-Character Pipeline. A designer uploads 2D concept art for a monster, the agent loop generates the TypeScript factory with idle, walk, and attack animations, and the pipeline exports to Babylon.js via the headless baking step. Web Workers handle async geometry generation so the character appears in-scene the moment the level loads. The watch point: organic detail loss on concept art with subtle textures—the vision loop can overfit to the front view and produce a cardboard-flat backside. The FSM catches foot-sliding before it ships.

Or an e-commerce team building a Procedural Asset Generator: product images of shoes or furniture become interactive 3D models for online catalogs. The service uses img2threejs to generate parametric models, enforces symmetric base geometry to mitigate backside occlusion, and caches generated code in a layer to avoid re-running expensive agent loops per user session. Reflections and textures are hard to replicate procedurally—I'd blend in displacement maps for surface detail and test across mobile GPUs for draw call performance.

When to Reach for img2threejs (and When Not To)

My decision criteria are concrete. Reach for img2threejs when your asset is stylized, mechanical, or hard-surface: armor plates, crystalline structures, angular monsters, procedural plant life, weapons, vehicles. These forms decompose cleanly into parametric curves, lathes, and CSG booleans, and the fidelity loss versus a photorealistic pipeline is acceptable or even desirable for the aesthetic you're targeting. Reach for it when runtime mutability is a core requirement—when you want to tweak a parameter, adjust a shader, or change an animation state without rebuilding a binary asset. And reach for it when network payload is your primary constraint: a few kilobytes of TypeScript versus 10–100MB of binary mesh files is a decisive advantage for mobile-first experiences with tight bundle budgets. For games with a low-poly or stylized aesthetic, interactive configurators where users adjust parameters live, or environments where the model can be tuned at runtime, this is the pipeline I'd choose.

Avoid it when you need photorealistic organic surfaces—human faces, fur, skin with micro-detail, realistic cloth. That's neural feedforward territory, whether via Trellis, Rodin, or Meshy. Avoid it when you need rapid generation of diverse assets at volume: the multi-pass agent loop takes minutes per model and burns tokens per refinement cycle, so generating 50 unique creatures in an hour costs more in agent compute than any neural pipeline. And avoid it when you have zero tolerance for self-intersecting geometry or non-manifold topology in the output—the procedural pipeline produces these pathologies regularly, and you'll own the cleanup in code.

My honest judgment: this is a tool for practitioners who value inspectability and control over turnkey photorealism. It's not the default choice for most production 3D workflows, but it's the right choice for a specific class of problems where the asset must live in git, be tunable at runtime, and stay tiny on the wire.

Open Questions and Future Development

The biggest unresolved issue is skinning. Procedural articulation via parented Group hierarchies and rotation math works well for segmented, stylized anatomy. It breaks for organic deformation—smooth bending at knees, elbows, tentacle bases. The question is whether the pipeline can evolve to generate proper bone-weighted SkinnedMesh rigs with smooth vertex bindings, and whether that evolution is even desirable given the added complexity. I suspect the answer is a layered approach: hierarchical pivots for the coarse skeletal motion, plus maybe a thin skinning layer passed over the mesh for smooth joints. The current architecture doesn't provide that, and closing the gap would significantly expand the range of credible organic animation.

The vision feedback loop needs to move beyond hero-angle regression. Fixing a front-view mismatch breaks the three-quarter view; the agent burns tokens oscillating between camera angles. I'd like to see the loop enforce simultaneous multi-view constraints—render all four angles in a single verification cycle, flag all discrepancies, and require the agent to propose a single parameter change that improves them collectively, rather than patching one at a time. That would dramatically reduce the saturation problem. Alternatively, deterministic regression circles where the agent rewinds to the last version passing all checks after each change would prevent unbounded iteration.

Client-side geometry generation overhead is solvable with a precompute step. Running the factory at build time and serializing the resulting buffers to a cached structure—rather than regenerating 110,000 triangles on page load—would convert the main-thread stall into a non-event. The agentic pipeline could emit both the code and a precompiled artifact, giving you the inspectability of code with the runtime performance of precomputed geometry.

LOD generation is an open question. Can the agent produce a hierarchy of detail levels—a 5,000-triangle version for distant rendering, a 110,000-triangle version for close-up inspection—from the same parametric definitions? Procedural geometry is well-suited to this: lower subdivisions, fewer curve segments, simplified materials. But the pipeline doesn't currently generate them, and I'd want to see that before relying on it for large scenes.

The pipeline is agent-agnostic by design, and that's its most future-proof feature. As frontier LLMs improve, the multi-pass loop integrates with whatever model is strongest at code generation and visual reasoning at the time. The skill definition, sculpt contract, and verification loop are model-independent, so the ceiling on output quality tracks the broader agentic frontier rather than being locked to a single model's capabilities. That makes it a more durable investment than a pipeline tied to a specific neural architecture.

Resources

• img2threejs — Live Demo Gallery
• GitHub - img2threejs/img2threejs: Rebuild the object in a reference image as a code-only, procedural, quality-gated, animation-ready Three.js model. Token-efficient image-to-3D. · GitHub
• GitHub - img2threejs/img2threejs-showcase: Live demo gallery for img2threejs: procedural Three.js models rebuilt from a single reference image. · GitHub