Skip to main content
Glama

Image → particles

image_to_particles

Transform any image into a GPU particle field that dissolves into points on audio cues and springs back to the original image. Each particle carries its pixel's color and rest position.

Instructions

Turn any image (a file path or an existing TOP) into a GPU particle field: each particle's rest position is its pixel in the source and (by default) its colour is sampled from that pixel. A spring force pulls particles toward their rest pixel; an optional audio chain scatters them away and lets them spring back, producing the iconic 'image dissolves into points on the drop, then re-forms' VJ look. Builds a new baseCOMP holding a downsampled source TOP, a one-shot rest-position GLSL TOP, velocity + position feedback loops (RGBA32float), an instanced Geometry COMP, Render, and a Null output. This is the only particle tool seeded by image/video pixels (rest positions + per-pixel colour); pick a sibling instead when particles are NOT driven by an image: create_gpu_particle_field for a free noise/curl/gravity drift field, create_particle_flock for boids/flocking, create_pop_particle_system for TouchDesigner's native POP particle network, create_particle_system for a simple CPU emitter. Default source is TD's stock Banana.tif; default audio source is 'none' (image idles statically) — 'file' and 'device' are opt-in (the latter may pop the macOS mic-permission dialog). Returns a summary plus a JSON block with the container path, particle count, output path, exposed controls, node errors, warnings, and an inline preview image.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dampNoPer-frame velocity damping.
sideNoParticle grid edge; count = side². 192 → 36 864 particles. The source TOP is resampled to side×side so each texel maps 1:1 to one particle.
sourceNoImage source: { kind:'file', path } loads a moviefileinTOP, { kind:'top', path } references an existing TOP. Default uses TD's stock Banana.tif from app.samplesFolder.
audio_fileNoAudio file path when audio_source='file'.
color_modeNo'image' = particle colours sampled from source pixels (via instancecolorop). 'mono' = white points. 'tint' = single colour multiplied by luminance.image
tint_colorNoRGB used when color_mode='tint'.
parent_pathNoParent network where the container is created./project1
audio_sourceNoDrives the scatter impulse. 'none' = image idles statically. 'file' = audiofileinCHOP (set audio_file). 'device' = audiodeviceinCHOP (opt-in; may pop the macOS mic-permission dialog).none
particle_sizeNoRadius of each instanced dot (TOP instancing applies translate only, so size lives on the source sphere SOP).
expose_controlsNoWhen true, expose live PointSize / SpringStiff / ScatterStr / Damp / Zoom knobs.
scatter_strengthNoAudio impulse magnitude. 0 = particles sit perfectly on the image.
spring_stiffnessNoForce pulling each particle toward its rest pixel. Higher snaps back faster.
Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=false) already indicate mutation but non-destructive nature. The description adds significant behavioral context: it builds a new baseCOMP with specific internal nodes (downsampled source, feedback loops, instanced geometry), details audio scattering behavior, and warns about permission dialogs. It does not contradict annotations.

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

Conciseness4/5

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

The description is longer than average but front-loaded with the core idea. It is logically structured: main purpose, network build details, sibling differentiation, defaults, and warnings. All sentences earn their place; minor verbosity could be trimmed but it remains impactful.

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?

Given high complexity (12 parameters, audio integration, network construction), the description covers all critical aspects: purpose, internal components, alternative tools, defaults, edge cases (mac permission), and return format (summary + JSON with path, count, controls, errors, preview). Without an output schema, it adequately explains what the tool returns.

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

Parameters5/5

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

Schema coverage is 100% with detailed descriptions, but the tool description adds substantial meaning beyond the schema: it explains how 'side' maps to particle count and resampling, clarifies source types and their behavior (e.g., video source produces 'video made of points'), and describes the effect of 'audio_source' options. Every parameter's role in the particle system is contextualized.

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 uses a specific verb ('Turn') and resource ('image into GPU particle field'), clearly stating the tool's primary function. It distinguishes itself from siblings by explicitly listing alternative tools for non-image-driven particles, making the purpose unambiguous.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use and when-not-to-use guidance, naming four sibling tools (create_gpu_particle_field, create_particle_flock, etc.) and stating conditions for their use. It also covers defaults (Banana.tif, no audio) and potential side effects (macOS mic-permission dialog).

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