app

Adom Desktop - Blender Bridge

Public Made by Adom

by adom

Drive Blender from a cloud AI on the user's real machine — auto-install a portable Blender, open the GUI, run Python scripts, import/export meshes (GLB/FBX/OBJ/STL), and render thumbnails.

bridgeblender3dadom-desktop
Overview Files Discover Packages Releases Dependencies Issues7 Breadcrumbs Pull Requests Activity
Open general

AD v1.9.78: host-app gate GENERIC — declare `detect` for Blender presence

John Lauer · 18d ago

AD v1.9.78 — host-app detection is now fully GENERIC (driven by your bridge.json detect block). Please declare detect for Blender.

Context: AD used to bake app-specific host-app detection into AD core (a Fusion tasklist/install-path probe). v1.9.78 deletes it and routes ALL host-app detection through ONE generic resolver that reads each bridge's bridge.json detect block. Blender is a user-installed host app, so declare a detect block and AD's read-only bridge_readiness probe will report whether the user has Blender — with NO spawn and NO install:

"detect": {
  "hostApp": "Blender",
  "paths": {
    "windows": ["%ProgramFiles%\\Blender Foundation\\*\\blender.exe"],
    "linux":   ["/usr/bin/blender", "/usr/local/bin/blender", "/snap/bin/blender"],
    "macos":   ["/Applications/Blender.app"]
  },
  "installVerb": "<your install verb if you ship one — AD offers it in the not-installed hint>",
  "hostAppOptionalVerbs": ["readiness", "describe", "status"]
}

paths is env-expanded with a single * matching one directory level (a version dir); on Windows you can also add "appPathsExe": "blender.exe" if Blender registers an App Paths key.

Two rules to know:

  1. AD detects INSTALLED only — you own RUNNING. Whether Blender is actually launched/connected is YOUR bridge's authority (report it via readiness/get_app_state/status). AD will forward verbs when Blender is installed and let your bridge answer if it isn't actually running — so make sure a modeling verb returns a clean, fast "not running / launch it" response rather than hanging.
  2. errorCode is generic: a not-installed host app → errorCode:"host_app_not_installed" (+ hostApp field). AD→caller only.

If you DON'T declare detect, AD has no built-in Blender fallback (only KiCad/Fusion have the legacy fallback), so bridge_readiness would report no host-app info for Blender — declaring it is how the user's Blender presence shows up.

1 Reply

John Lauer · 18d ago

For Blender: blender_render can run minutes — WITHOUT a timeouts block AD cuts it at 60s (Blender has no built-in fallback, unlike fusion/kicad). Declare e.g. render→600 + statusVerb.

Follow-up — AD v1.9.79: per-verb HTTP timeouts are now a GENERIC bridge.json contract.

Same "AD stays generic" push as the host-app gate above: AD moved per-verb timeout budgets out of AD core into YOUR bridge.json. Before v1.9.79, AD hard-capped every bridge verb at 60s (fusion/kicad had a built-in table a third-party bridge could not touch). Now you declare budgets and AD honors them with ZERO AD change:

"timeouts": {
  "default": 60,
  "verbs": { "<slow_verb>": 600 },              // exact BARE verb names (no prefix)
  "prefixes": [ { "prefix": "export_", "seconds": 120 } ]  // fallback rules, first match wins
},
"statusVerb": "<your_poll_verb>"
  • Resolution: exact verbs → first matching prefixes → default → AD's global 60s.
  • A timeout is NON-terminal: AD returns {stillRunning:true, statusVerb, timeoutSeconds} and the caller polls your statusVerb — so declare statusVerb too.
  • Bump version + republish; users auto-update on the next 4h poll.

Full updated contract (the timeouts block in the bridge.json schema + the Self-audit checklist): the Bridge SDK billboard → https://wiki.adom.inc/adom/adom-desktop-bridges. Re-run your SDK self-audit against it.

Log in to reply.