camera-to-blender: turn a phone photo into an imported Blender model

What camera-to-blender actually solves

The project targets a narrow gap: getting a real object into Blender without modelling it. The README states the flow plainly: "Take photo → background removed → 3D model generated → auto-imported into Blender." The intended user is someone with a phone, a computer running Blender, and no interest in photogrammetry pipelines. The camera UI is built for phones, but the README notes a laptop webcam works too, so the same flow is usable without a handset. What it is not is a scanner. There is no multi-view reconstruction, no scale calibration, and no way to control the topology of what comes back. You get one mesh per photo, generated by a remote service. If your goal is a clean, game-ready asset, this is the wrong starting point; if your goal is a rough prop placed in a scene in about a minute, it is the whole point.

The relay architecture: FastAPI, WebSocket, and two external APIs

The repository is small enough to read in one sitting. relay_server.py is a FastAPI app that talks to the external APIs and relays models to Blender. webapp/ holds the phone camera app. blender_addon/ holds the add-on source, and ws_import_addon.zip is the packaged version you install. The data flow runs in one direction: the phone posts a photo to the server, the server optionally sends it to Gemini for background removal, then to Tripo3D for generation, and when the model is ready the server pushes it to Blender over a WebSocket. Blender is not polling. It opens a persistent connection to the ngrok URL with the query string /ws?client=blender, and the add-on panel reports Status: Connected when the handshake succeeds. That design is why ngrok is listed as required for phone use: phone cameras need HTTPS, and the same tunnel carries both the web app and the Blender socket. It also explains the most common failure mode. If the tunnel drops, the socket dies silently from the user's point of view and the Send to Blender tap returns "Failed to send to Blender."

Installing camera-to-blender and shooting your first object

Setup is four steps and the README gives them in order. First install the Python dependencies and create your environment file. The requirements.txt pins fastapi, uvicorn[standard], websockets, websocket-client, httpx, python-dotenv, python-multipart and google-generativeai.

pip install -r requirements.txt
cp .env.example .env

Then edit .env. TRIPO_API_KEY is required because it generates the 3D models. GEMINI_API_KEY is optional and only used for background removal; the README says that if it is left empty, background removal is skipped and the original photo is used. PORT defaults to 8000.

TRIPO_API_KEY=your_tripo_api_key_here
GEMINI_API_KEY=your_gemini_api_key_here

Start the server, then open a tunnel in a second terminal. The README uses uvicorn on port 8000 and ngrok http 8000, which returns a URL like https://abc123.ngrok-free.app.

uvicorn relay_server:app --host 0.0.0.0 --port 8000

ngrok http 8000

In Blender, go to Edit, Preferences, Add-ons, Install, pick ws_import_addon.zip and enable it. Press N in the 3D viewport, open the WS Import tab, and paste your ngrok URL with https swapped for wss and /ws?client=blender appended. The README gives this exact shape, and the panel should read Status: Connected.

wss://abc123.ngrok-free.app/ws?client=blender

Now open the ngrok URL on your phone, allow camera access, point at an object, tap the shutter and confirm the photo. The README puts generation at roughly 30 to 60 seconds. When it finishes, tap Send to Blender. To test without a phone, skip ngrok entirely: open http://localhost:8000 and point Blender at ws://localhost:8000/ws?client=blender.

Where camera-to-blender breaks, and what it cannot do

The failure modes are documented, which is a good sign, but they are all environmental rather than cosmetic. The camera will not open on a phone unless you use the https:// ngrok URL; a local IP will not work. "Failed to send to Blender" means the add-on is not connected, and the README tells you to check that the WS Import panel says Connected and that the URL starts with wss:// and ends with ?client=blender. The sharpest limitation is the free ngrok tunnel: the README states that free ngrok URLs change every restart, so you reconnect Blender with the new one each time. That makes the setup unsuitable for anything long-running or unattended. Background removal fails on Gemini quota or key problems, and the fallback is to leave GEMINI_API_KEY empty and use the photo as-is, which means the generator sees the whole scene rather than the isolated object. None of this is a bug in the relay; it is the cost of routing through two hosted APIs and a tunnel. If you need this to work on a plane, in a locked-down network, or without an account on a third-party platform, it will not.

camera-to-blender compared with Blender's own camera import and add-ons

The obvious alternative is not another photo-to-3D service but Blender itself. Blender can import a reference image, and there are add-ons that add a camera object or load footage as a background, which is what most searches about adding a camera to Blender are actually about. Those tools keep you inside Blender and produce a camera or a backdrop, not geometry. camera-to-blender produces a mesh, and it does so by leaving your machine entirely: the photo goes to Gemini and Tripo3D, and the result comes back through a public tunnel. The difference in approach matters more than the feature list. An in-Blender add-on has no API key, no quota, no tunnel and no per-photo cost, but it also cannot turn a photo into a model. If you only need to frame a shot or match a camera angle, the built-in path is the correct one and camera-to-blender adds nothing. If you need an actual object in the scene, the relay is doing work no local add-on does, and you are paying for it in dependencies.

Maintenance, packaging and the MIT licence

The last push to the repository was on 2026-09-05, so the project has recent activity, though there are no releases retrieved and the README does not describe a versioning or rollback scheme. Upgrades are manual: requirements.txt pins exact versions of fastapi, uvicorn, websockets, websocket-client, httpx, python-dotenv, python-multipart and google-generativeai, so a dependency bump means editing that file and reinstalling. The add-on has its own packaging step. If you edit the add-on source, the README says to repackage it before installing:

zip -r ws_import_addon.zip blender_addon -x "*/__pycache__/*" "*.pyc"

That is the whole distribution story: a zip you install by hand in Blender, with no update channel. The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are preserved. That covers the code in this repository. It does not cover Tripo3D output, Gemini output, or ngrok's service terms, and the README says nothing about the licensing of generated models; check those platforms separately before using the results commercially. Nothing here is legal advice.

Editorial conclusion

Adopt camera-to-blender if you want a quick way to get rough 3D props from phone photos into Blender and you already accept a Tripo3D dependency. Skip it if you need offline operation, deterministic geometry, or production mesh quality, since every model comes from a third-party API and the free ngrok URL changes on each restart. Verify first that your Tripo3D key has quota, that your ngrok tunnel is running, and that the add-on reports Status: Connected before you shoot anything.

Frequently asked questions

Official sources

1. ahujasid/camera-to-blender on GitHub
2. Issues
3. License: MIT
4. README