The Problem

Turning a physical object into a 3D model for Blender normally means photogrammetry software, multiple export/import steps, and manual cleanup. This repo collapses that to: take a phone photo, wait under a minute, and the model lands in an open Blender scene automatically.

What This Does

relay_server.py is a FastAPI server (run via uvicorn) that serves the phone camera UI from webapp/, calls two external APIs to turn a photo into a mesh, and pushes that mesh to Blender over a WebSocket. The blender_addon/__init__.py source, packaged as ws_import_addon.zip, is the Blender-side listener that imports the incoming model.

Background removal is optional and handled by Gemini; mesh generation is mandatory and handled by Tripo3D. Both keys live in .env.

How It Is Wired

Execution starts at webapp/index.html on the phone. webapp/app.js captures the photo and posts it to the server. From there relay_server.py handles everything: it calls the Gemini API to strip the background (skipped if GEMINI_API_KEY is empty), calls the Tripo3D API to generate the mesh, and relays the result over a WebSocket to the Blender add-on at /ws?client=blender.

The dependency graph is a hub-and-spoke layout with relay_server.py as the hub. Every external effect — the two API calls, the WebSocket push, serving the webapp — passes through that one file. The add-on (blender_addon/__init__.py) is the only consumer of the WebSocket feed. The cost of the hub design: any change to the relay protocol or API orchestration touches one file, but that file also carries the widest blast radius since a bug there breaks the entire pipeline. The internal call graph beyond the entry points has not been mapped for this repo; the description above is traced from the README and file structure, not a static analysis of function calls.

webapp/point-cloud-loader.js exists but its role in the pipeline is not documented in the README — verify before assuming it participates in the main flow.

How To Use It

pip install -r requirements.txt
cp .env.example .env
# edit .env: TRIPO_API_KEY required, GEMINI_API_KEY optional
uvicorn relay_server:app --host 0.0.0.0 --port 8000
# second terminal, for phone use:
ngrok http 8000

Install ws_import_addon.zip in Blender (Edit → Preferences → Add-ons), open the WS Import tab, and connect to wss://<ngrok-url>/ws?client=blender. Without a phone, skip ngrok and use http://localhost:8000 with ws://localhost:8000/ws?client=blender.

Real-World Use

A product designer photographs a prototype part on a phone, the model appears in Blender, and they drop it into an assembly scene to check fitment — no file transfer, no photogrammetry cleanup. The same flow works with a laptop webcam for desk-bound capture.

Code Health & Issues

Static analysis found the following, quoted from the measured report:

  • Medium/SDLC — No test files detected, untested code paths, repository-wide.
  • Medium/SDLC — No CI/CD pipeline detected, no automated build/test gate, .github/ or CI config.
  • Low/Risk — Dependencies declared without a lockfile, non-reproducible builds, requirements.txt.

Beyond those: the heuristic flagged Express as a framework, but the README's uvicorn relay_server:app indicates FastAPI/Starlette — treat the framework detection as unreliable. The repo ships a prebuilt ws_import_addon.zip alongside the source, which risks the binary drifting from blender_addon/ if edits aren't repackaged.

The Bottom Line

A functional, minimal pipeline that does one thing well: photo to Blender mesh in under a minute, with a clean phone-first UX and clear troubleshooting docs. It depends on two paid external APIs and has no tests or CI, so it's a solid prototype or internal tool — not something to extend without adding test coverage around relay_server.py first.