Skip to main content
Glama

Create POP particle system

create_pop_particle_system

Create a complete POP particle simulation chain with a render rig and live controls for emission rate, lifetime, feedback gain, and force texture.

Instructions

Build a complete POP particle simulation (particle_pop → feedback_pop → lookup_texture_pop → field_pop → null_pop) inside a new baseCOMP, wire a render rig (poptoSOP → geometryCOMP → renderTOP → nullTOP), and expose EmissionRate, Lifetime, FeedbackGain, and ForceTexture live controls. When force_texture_path is omitted, a noiseTOP is created inside the container as the default force source so the chain always cooks. Supports three output modes: 'particles' (particle render), 'field' (field_pop visualization), and 'composite' (compositeTOP add of both). POP chain creation is delegated to build_pop_chain (Layer 2); this tool adds only the render rig and control exposure. This is the only particle tool built on TouchDesigner's native POP operators (force-texture driven, with field/composite output modes); pick a sibling instead for non-POP paths: create_gpu_particle_field for a GPU noise/curl/gravity drift field, create_particle_flock for GPU boids/flocking, image_to_particles to reconstruct an image/video as points, create_particle_system for a simple CPU emitter. NOTE: POPs are Experimental — the result carries an unverified marker; live-validate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoContainer basename created under parent_path.pop_particle_system
outputNoWhich TOP the output nullTOP mirrors. 'particles' = render of particle_pop chain; 'field' = rendered field_pop visualization; 'composite' = compositeTOP (add) of both.particles
lifetimeNoParticle lifetime in seconds; mapped to particle_pop life/lifeexpect. Exposed as Lifetime knob.
resolutionNoRender TOP resolution [width, height].
parent_pathNoParent COMP path (default '/project1')./project1
emission_rateNoParticle birth rate per second; mapped to particle_pop birthrate and exposed as EmissionRate knob.
feedback_gainNoFeedback strength on feedback_pop (mapped to inputmul). Exposed as FeedbackGain knob.
force_texture_pathNoExisting TOP path to drive the force field via lookup_texture_pop.par.top. If omitted, a noiseTOP is created inside the container as the default force source.
Behavior4/5

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

Annotations already indicate non-readOnly, openWorld, non-destructive. Description adds context: creates new baseCOMP, wires render rig, exposes live controls, and auto-creates noiseTOP if force_texture_path omitted. Experimental note adds transparency.

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?

Description is long but well-structured with clear sentences, each adding value. Front-loaded with main purpose. Slightly verbose due to comprehensive coverage, but no fluff.

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?

No output schema, but description fully explains three output modes and what each produces. Mentions delegation to Layer 2 tool. Covers all behavioral aspects needed for an AI agent to use correctly.

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

Parameters4/5

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

100% schema description coverage sets baseline at 3. Description adds that EmissionRate, Lifetime, FeedbackGain, ForceTexture are exposed as live control knobs, providing extra context beyond schema descriptions.

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?

Description clearly states it builds a complete POP particle simulation with specific operator chain and render rig. It explicitly distinguishes from four sibling tools by naming alternatives and specifying non-POP paths.

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?

Explicitly tells when to use (POP particle simulation) and when not to use (non-POP paths) with four named sibling alternatives. Also notes experimental status and delegation to build_pop_chain for the POP chain.

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