A single photo can become a game asset, a printable relief or a measured scan, but not all three at once. Here are the four goals, the method each one needs, and the cleanup each one costs.
Turning a 2D image into a 3D model is at least four jobs that share one input file: producing a game or AR asset from a photo, building a printable object, measuring something that exists in the real world, and faking parallax for a website hero. The route you pick decides the tool, the format and how much cleanup you owe afterwards.
This tutorial separates those goals, walks through the method each one needs, and gives the numbers that matter: typical triangle ranges, input sizes, print tolerances and the repair steps still manual in 2026. Limits are stated as plainly as capabilities.
The same photograph leads to four products, and mixing them up is why people conclude that image-to-3D does not work. An asset for Unity or a WebGL viewer only has to look right from the angles a player sees. A printable object has to be a closed solid with real thickness, because a slicer cannot reason about an open surface. A measurement needs several calibrated photographs, since one image does not contain depth. A website hero image needs a depth map and a displacement shader.
| Route | Input | Typical output | Cleanup still required |
|---|---|---|---|
| Single-image AI | One photo, 1024 px or larger | 20k–200k triangles, baked albedo | Guessed back faces, decimation, texture touch-up |
| Multiview AI | Three to six consistent views | Denser mesh, one stitched texture | Calibration, holes on the unseen base |
| Photogrammetry | 30–200 overlapping photos | Millions of triangles plus a camera solve | Decimation, retopology, scale check |
| Depth-map relief | One photo plus a depth estimate | Watertight relief, 50k–500k triangles | Height exaggeration, backing plate, wall thickness |
| Blender displacement | Image used as a heightmap | Surface at your chosen resolution | Manual modelling, manual UVs, manual thickness |
A photograph stores colour per pixel and nothing else. Most systems work in two stages. A network trained on image and depth pairs predicts a depth map or an implicit field: estimators such as MiDaS and Depth Anything V2 return relative depth, accurate in ordering and rough in absolute distance. A second stage lifts that estimate into a three-dimensional representation, a radiance field, a set of Gaussians or a signed-distance field, and extracts a surface with a differentiable isosurface method such as marching cubes, DMTet or FlexiCubes.
The practical consequence is that geometry is inferred, not observed. Parts the camera saw are usually faithful within a few percent; behind the silhouette are smooth guesses, and thin straps, fingers or chair legs fuse into blobs because the depth estimator cannot separate them. The mesh also arrives without units: a vase and a bus come out the same size, so every export needs an explicit scale step.
If the object exists in front of you, take more pictures rather than a better one. Multiview engines such as TRELLIS 2 and Hunyuan3D 2.x, and hosted services such as Meshy, Tripo and Rodin, accept three to six views and reconstruct a consistent object. When the goal is a true measurement, photogrammetry remains the reference: COLMAP or Meshroom solves camera positions from thirty to two hundred overlapping photographs and rebuilds the surface. It is slower and needs surface texture, but it measures instead of inventing, and only it yields real-world scale from the images.
Generated meshes arrive with three recurring defects. Inverted normals make a model render black in Unity and mislead some slicers. Small holes at the base or between limbs break the manifold condition that FDM and resin slicers require. Zero-thickness walls look solid on screen and print as a single perimeter. Blender's 3D-Print Toolbox flags non-manifold edges, self-intersections and thin walls in one pass, Meshmixer's Analysis tools give a similar readout, and trimesh or MeshLab script the checks. Recalculate normals, fill holes, then add thickness with a solidify modifier or a boolean union.
When the target is a flat picture turned into a printable object, a depth map plus a heightmap often beats a generated mesh. A lithophane is the clearest case: convert to greyscale, invert so dark areas become thick, and let the slicer resolve the heights. For a relief plaque, estimate depth with Depth Anything V2, export a 16-bit PNG, then displace a dense plane in Blender. From a 1920 px image, a 150 mm wide relief at 0.1 mm layers resolves roughly 0.4 mm detail, the practical limit of a 0.4 mm nozzle.
Both failure modes are boring and extremely common. Generated meshes come normalised, so a model that should be 180 mm tall exports at 1 unit and slices to nothing. One Blender unit is conventionally one metre, while STL and 3MF carry no unit field, so readers assume millimetres. Measure with the ruler overlay, then scale explicitly. The second problem is axis: Blender is Z-up, most engines and glTF are Y-up, and a model imported without conversion stands on its face. Fix both axes at export.
| Format | Use it for |
|---|---|
| GLB / glTF | Game engines, AR viewers and the web: one file, embedded textures, Y-up by default. |
| OBJ | A DCC tool or render farm that expects loose files: mesh plus a separate MTL and PNG set. |
| STL | Single-colour printing, accepting that it has no units, colour or material data. |
| 3MF | Millimetre units, multiple parts and print settings carried into Bambu Studio, OrcaSlicer, Cura or PrusaSlicer. |
| PLY | Point clouds and scan data, and pipelines that expect vertex colours. |
Plan for a second pass on roughly half of single-image jobs. Long thin features, transparent or mirror-like surfaces, and anything whose identity lives on the hidden side, such as a chair back or a car's far flank, are the reliable failure cases. Text and fine engraving come back smeared, because the depth estimate is smoother than the original. Repetitive structure, chain link or mesh fabric, is the hardest case. The fixes are unglamorous: shoot a three-quarter view, add a second view, model the occluded part by hand, or use photogrammetry when the object is real.
Open3DAI sits in this landscape as a browser workspace, not a replacement for a desktop modeller. It generates from text, from a single image and from several views, applies AI texturing, compares the same prompt or image across the available engines before export, and exports GLB, glTF, OBJ, STL, PLY and 3MF, with a REST API and 48 format converters. It does not do photogrammetry, rigging, animation, automatic retopology, UV unwrapping or CAD-quality parametric solids, and it does not guarantee watertight or print-ready output. Keep Blender, Meshmixer or a parametric tool such as FreeCAD or OpenSCAD for those steps.
Engine availability, credit pricing and third-party terms change between releases; verify them on the vendor page before committing a budget or building a workflow around one engine.
Yes, if the hidden side is predictable. Bottles, mugs, simple creatures and stylised props come out usable; chairs, capes and thin machinery do not, because half the shape was never in the picture. Expect a cleanup pass on roughly half of single-image jobs.
On a hosted endpoint a single generation usually returns in about 20 to 90 seconds depending on the engine and resolution. A local Hunyuan3D 2.x or TRELLIS 2 graph in ComfyUI typically takes a few minutes per asset on a consumer GPU. Photogrammetry is a different scale entirely: tens of minutes to hours for a full reconstruction.
Generated meshes are normalised, usually to about a unit cube, and STL and 3MF carry no unit field, so readers assume millimetres. Measure the model with a ruler tool and scale it explicitly before exporting.
For hosted services, no: the browser does the upload and the engine runs remotely. For a local ComfyUI graph such as Hunyuan3D 2.x or TRELLIS 2, plan on a discrete GPU with roughly 8 to 24 GB of video memory, depending on the model and the resolution you target.
They answer different questions. Photogrammetry measures a real object from thirty or more overlapping photos and gives you true scale and true surface detail; AI reconstruction works from as little as one image but invents whatever the camera missed. Use photogrammetry when the object exists and accuracy matters, use AI when only a picture exists.
Often, after repair. Make the mesh watertight, give it real wall thickness, cut a flat base and check the slicer preview for floating shells. Reliefs and lithophanes built from a depth map are the easiest printable result because a backing plate makes them solid almost by construction.
It depends on the destination. A mobile game prop is usually comfortable at 2k to 15k triangles, a PC hero asset at 30k to 100k, and a printable object can carry as many as the slicer tolerates, since a 3MF with a few million triangles still slices. Decimate before you unwrap, then re-bake the texture if it turns muddy.
Sharp, evenly lit, one object, subject filling roughly 70 to 90 percent of the frame, on a clean or transparent background, at 1024 px or larger on the short side. Engines resize internally, so detail lost in a small or blurred crop never comes back.
GLB or glTF for Unity, Unreal, Godot, web viewers and AR, because textures travel inside the file and the axis convention is Y-up. STL for a simple single-colour print, and 3MF when you want millimetre units and print settings carried into Bambu Studio, OrcaSlicer, Cura or PrusaSlicer.
Send the same prompt or image to several engines, compare the meshes side by side, then export GLB, glTF, OBJ, STL, PLY or 3MF. Creating an account grants free credits and needs no card.
Image-to-3D predicts the geometry the camera never saw. Here is how to prepare the photo, choose between single-view and multiview engines, judge the mesh in the first minute, and export it at the right scale.
Silhouette extrusion, lithophane height maps and AI image-to-3D all end in the same file extension and almost nothing else. Here is what each route controls, which photos survive it, and the checks that happen before the first layer.
Texturing is four decisions taken in order: whether the model needs UVs, how the UV islands are laid out, which PBR maps you author, and where the pixels come from. Each decision is explained here with the numbers that make it.