I wanted to turn product photos into something you can drag and rotate in a browser. I don't know 3D modeling. I wasn't going to learn Blender for one demo, and I wasn't going to pay for a 3D generation API either.
I found img2threejs and ran it against a Tesla kids balance bike. Reference photos came from the Tesla Shop.
Here's the prompt I used:
/img2threejs
Rebuild the Tesla Kids Balance Bike from these reference images:
- [SIDE_VIEW_IMAGE]
- [FRONT_3_4_IMAGE]
- [REAR_3_4_IMAGE]
Use the side view as the primary reference. Use the other views to understand the width, depth, and hidden parts.
Create a code-only procedural Three.js model. Match the main shape, proportions, colors, and recognizable parts.
Then build a minimal product demo with orbit controls, auto-rotation, spinning wheels, and camera presets.The Usual Problem
Putting 3D on a web page normally means getting a model file first. GLB, FBX, OBJ. You get one by:
- Building it yourself in Blender or C4D
- Hiring someone to build it
- Downloading a pre-made asset
- Generating a mesh through an AI 3D service
Then you load it into Three.js.
Nothing wrong with that approach. It works well for production assets. But if you just want a quick interactive demo on a web page, the 3D asset itself becomes the bottleneck. You either need modeling experience or you need to buy API credits from a 3D generation platform. For someone who just wants a product photo spinning in a browser, both feel like overkill.
What img2threejs Does
It takes a code-first approach:
- Analyzes contours, parts, and materials from the reference image
- Organizes the object into a structured modeling spec
- Builds it stage by stage using Three.js geometry and materials
- Renders it in the browser, compares against the reference
- Fixes proportions, structure, or materials when something looks off
You don't get a downloaded mesh file. You get runnable, editable Three.js code.
Why does the output quality hold up? The pipeline doesn't rely on a single prompt and hope for the best. It plans first, builds in stages, renders comparisons, and corrects mistakes across multiple passes. There are spec gates that block code generation until the plan is detailed enough, checklists that force key features to map to real code components, and staged reviews where each step has to pass before the next one starts. You don't need to understand computer graphics to get a decent result. The process carries you.
Compared to the Traditional Route
GLB files can absolutely be interactive. You can orbit them, animate them, and pull them apart. The difference isn't capability. It's where the asset comes from and how you change it afterward.
Where the asset comes from Traditional: you make or acquire a model file before anything shows up on screen. img2threejs: code rebuilds the object directly. No file needed first.
What gets produced Traditional: a GLB, FBX, or OBJ file. img2threejs: Three.js TypeScript source code.
Relationship to the web page Traditional: the page loads a model file. img2threejs: the page runs code that generates the model.
How you make changes Traditional: go back to the modeling tool to adjust geometry. img2threejs: edit parameters and components in code. A coding agent can keep iterating.
Best fit Traditional: high-fidelity, general-purpose 3D assets. img2threejs: web demos, rapid experiments, interactive showcases.
Think of it this way. The traditional route delivers finished furniture. This route delivers a parts list and assembly instructions you can keep modifying.
When It's Worth Using
Good fit:
- Product landing pages
- Interactive web demos
- Hackathons and proof-of-concepts
- Hard-surface objects: headphones, keyboards, tools, vehicles
- Projects where you want a coding agent to keep adding interaction later
Bad fit: scan-level accuracy, manufacturing tolerances, complex hair or cloth. A single photo can't reveal every hidden surface. The pipeline will infer what it can't see, but it won't pretend to be certain.
A note from testing: The model you run matters. I started with Opus 4.6 and the output was lazy. Sparse geometry, missing parts, minimal effort. Switching to Kimi K3 improved things dramatically. Use the strongest model available. The gap in spatial reasoning and code generation shows up directly in 3D quality.
If your end goal is an interactive Three.js page, you don't necessarily need a traditional model file first. For the right objects, having AI build the 3D in code might be a shorter path, and one that fits an AI coding workflow better.
