Add a DCC or art application
UI library · Modules and languages · Bridge architecture
Adding an application is progressive. You can make its documentation and local tools searchable before you build a live bridge. The UI should label that stage docs-aware / launchable; it must not imply that Tech Connector can read or change the application's scene.
1. Make the application discoverable
Record a stable host ID, display name, executable path, and an official API or SDK reference. Add any studio scripts as an extra project folder with Project > Project Directories.... Refresh the index, then confirm a known function in Search / Symbols. This establishes source lookup only.
The progressive provider manifest is defined in
tech_connector/services/dcc/three_d_app_provider_manifest.py. Its minimum
fields allow Tech Connector to know the app exists and draft host-aware setup;
optional fields unlock connected and viewport states. The
bridge architecture lists the
manifest's optional capabilities.
2. Decide how commands will run
Choose the host's supported automation API: Python inside Maya or Blender, C# Editor code in Unity, UXP JavaScript in Photoshop, or another documented SDK. A reference page and a callable name are not enough; the host needs a trusted in-app adapter or plugin and a Tech Connector bridge.
For a direct Python host bridge, the common shape is in
tech_connector/bridges/host_bridge.py. Implement the host-specific parts of
find_port(), execute(code), get_selection_code(),
get_current_file_code(), and get_scene_objects_code(). Use the host's main
thread rules for scene edits. Optional call_function, get_logs, save, and
other verbs can come later. Keep host-specific code in its bridge or adapter.
The current authorization boundary uses a short-lived capability from an unlocked desktop session. Do not copy a bridge token into scripts, a project file, or documentation.
3. Register capabilities accurately
Add bridge metadata in tech_connector/plugins/plugin_registry.json or an
integration package. The registry describes how the host is reached; it does
not create a running bridge. Register concrete operations and their required
inputs only after the adapter handles them. Add host-specific menu actions
through the provider manifest and keep generic verbs such as selection and
current-file reads consistent with existing hosts.
If you add Python utility functions, put them in a host package that the
project indexes, then refresh the function catalog. A source function may
appear in search before it is safe or possible to run through the bridge.
For the official vendor API, use the native reference guide:
website names are lookup links, while native_catalog asks a connected
Python host what it actually exposes.
4. Validate in increasing steps
- Docs-aware: app path and official docs resolve; a known local function appears in search. No scene claim.
- Connected: start the host and adapter; capability status reports the right host, version, and session. Read selection/current file without edits.
- Operations: run a harmless query, then a controlled edit on a disposable scene. Check the changed scene or exported file in the host.
- Viewport: add snapshot, camera, and geometry methods only if the host supports them. A bounds fallback is not a rendered mesh preview.
- Distribution: package the adapter, document installation and removal, and test clean installs and bridge recovery. Host SDK and license terms remain the developer's responsibility.
No one-device smoke test proves production support across host versions. Keep the host's status as experimental until its installation, lifecycle, permissions, file changes, and failure recovery have evidence.
Existing examples and deeper references
- Bridge architecture: contract, registry, and progressive manifest fields.
- Plugin architecture: built-in bridge layouts.
- DCC smart operations: typed operation routes.
- Customization guide: reasoning and tool adapters when you need domain behavior beyond a host bridge.