Skip to main content
Glama

Create blob reactive

create_blob_reactive

Creates a blob-tracking network in TouchDesigner that outputs normalized per-blob positions (x, y, size) for driving parameters from multiple objects or hands in a camera feed.

Instructions

Build a blob-position-tracking chain that drives parameters from the POSITIONS of multiple objects/hands in a camera (or a TOP) — the per-blob counterpart to create_motion_reactive's single aggregate motion value. Creates a container under parent_path with a Video Device In TOP (or a Select TOP pulling an existing TOP), a Monochrome + Threshold TOP to isolate bright blobs, a Blob Track operator assigning each blob a persistent slot, and a Script CHOP that normalizes the tracker's per-blob output into a deterministic 'blobs' Null CHOP with channels blob0_x, blob0_y, blob0_size, blob1_x, … Bind any parameter to op('…/blob_reactive/blobs')['blob0_x'] (or pass targets to bind by expression as value*scale+offset). Camera source may prompt for (and briefly hang on) a macOS camera-permission dialog. The Blob Track operator is a palette/CV op whose optype and channel naming vary by TD build — the chain is built fail-forward and warns (rather than failing) if it is unavailable, and the Script CHOP normalizes whatever channels the tracker emits. Returns a summary plus a JSON block with the container path, the blobs CHOP path, the tracked output TOP, the tracker type used, channel names, bound targets, and warnings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
parent_pathNoParent network where the blob-reactive container is created (default '/project1')./project1
nameNoBase name for the container COMP that holds the chain.blob_reactive
sourceNoBlob source. 'camera' = live webcam/capture device (the real-world default; creating it may pop a one-time macOS camera-permission dialog — click Allow, and note it can briefly hang TD at the modal). 'top' = analyze an existing TOP you name in source_top.camera
source_topNoPath of an existing TOP to track blobs in; used only when source='top' (a Select TOP pulls it in so no cross-container wire is needed).
camera_indexNoWhich capture device to use when source='camera' (0 = the first/default camera). Maps to the Video Device In TOP's device index.
thresholdNoLuma threshold [0–1] for isolating blobs: pixels brighter than this are considered part of a blob. Lower catches dim/large blobs, higher only bright ones. Drives both the Threshold TOP mask and the blob tracker's own threshold.
max_blobsNoMaximum number of blobs to track simultaneously, each given a persistent slot/ID.
targetsNoPer-blob parameter bindings. Each entry binds one node parameter by expression to op('…/blobs')['blob<blob>_<axis>'] * scale + offset. Omit to just build the tracking chain and bind later.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses macOS permission prompt, variable tracker behavior by build, normalizing CHOP, and return format, going well beyond the minimal annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Packs substantial detail but is verbose; front-loaded with purpose but could be tighter without losing essential info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 8 parameters (including nested objects) and no output schema, the description thoroughly covers the chain, return values, warnings, and edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so description adds little to individual parameter understanding; it does provide context on how threshold interacts across operators but not beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Build a blob-position-tracking chain' and explicitly contrasts with create_motion_reactive, making the purpose and distinct resource clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Distinguishes from create_motion_reactive and mentions macOS permission dialog and fail-forward behavior, but could more explicitly state when alternatives are preferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Pantani/tdmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server