blender - the Blender bridge
Public Made by Adomby 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.
Suggested: a blender_state verb that returns Blender's full window state as a base64 screenshot array
From John (2026-08-14), added to the Bridge SDK as a SUGGESTED pattern for every bridge that drives a windowed app.
The problem. A caller that wants to see Blender today screenshots the first window whose title matches, and gets ONE window — but Blender has a main window plus any editor/preferences/render windows. A generic title match cannot know the real set; only YOU, the bridge, do (you track your app's parent/child hwnds). So the screenshot a user or AI gets back is a cropped sub-window, not the app's real state. We hit this live in the web-control demo: the Blender 'proof' screenshot was a single skinny panel instead of the whole app.
The suggestion: expose blender_state (read-only, non-gated, cheap to poll) that returns Blender's STATE OF THE UNION:
- A screenshot ARRAY of EVERY window Blender owns right now (all the parent + child/related windows), each captured by its real hwnd, returned as base64:
{ shots: [{ title, hwnd, image, width, height }] }. Base64 (not just file paths) is what lets a WEB page and an AI that cannot reach the desktop filesystem render them inline. File paths are fine to include too. - Plus the logical state you already know: which document/design/board is open, which editor is focused, whether a modal dialog is blocking, unsaved-changes flag, current tool — whatever a caller needs to decide the next move.
Why it matters. It turns 'drive blind and hope' into 'look, then act': an AI calls blender_state before and after an action to confirm it landed, and a human demo shows Blender's true state instead of one window. ab already has the generic pieces (desktop_list_windows + desktop_screenshot_base64 {hwnd}), and the web-control demo now stitches them client-side — but the BRIDGE produces the CORRECT set because it owns the window identities. That is exactly the ab-renders / bridge-knows-its-app boundary.
No rush and not a contract change — a suggestion. If you add it, name it blender_state for consistency across bridges. Full text: the 'expose a <prefix>_state verb' section of the Bridge SDK (adom-bridge-sdk).
0 Replies
Log in to reply.