Skip to main content
Glama

Create body bubbles

create_body_bubbles

Creates an interactive bubble simulation driven by live hand and body tracking. An open palm emits soap-like bubbles that collide with the performer's body landmarks and visible contour.

Instructions

Create a MediaPipe-ready interactive bubble installation over the live camera: a detected open palm emits soap-like bubbles, body and hand landmarks act as soft colliders that can bat or lift them, a visible body contour is rendered in the same output so the interaction reads clearly, bubbles stay inside the screen box, settle on the lower floor, and pop/fade after a configurable lifetime (default 30 seconds). By default it keeps the bubble count low and disables pose-wrist emission, so bubbles are created only by an open palm. Builds a self-contained Base COMP with a Script CHOP physics solver, Script SOP bubble outlines, Script SOP body contour, camera-background composite, Geometry/Render/Null TOP output, a frame cooker, and live controls for emission rate, gravity, drag, buoyancy, skeleton impulse, bubble repulsion, tracking smoothing, body radius, body contour, camera opacity, lifetime, and bounce. Provide hand_chop_path from setup_hand_tracking and body_chop_path from setup_body_tracking/create_pose_tracking for full interaction.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName for the generated bubble-physics Base COMP.body_bubbles
parent_pathNoParent COMP where the body-bubble system is created./project1
hand_chop_pathNoOptional hand-tracking CHOP from setup_hand_tracking: 21 samples per hand with tx/ty/tz/confidence. Open palm emits bubbles.
body_chop_pathNoOptional body/pose CHOP from setup_body_tracking or create_pose_tracking: 33 samples with tx/ty/tz/confidence. Landmarks collide with bubbles.
camera_top_pathNoTOP to use as the visible camera background. The MediaPipe plugin exposes the live camera at /project1/MediaPipe/video./project1/MediaPipe/video
show_camera_backgroundNoComposite the camera TOP behind the body contour and bubbles.
hide_camera_tracking_overlaysNoWhen camera_top_path belongs to the MediaPipe plugin, turn off its built-in tracking overlays so only the clean camera appears behind this system.
camera_opacityNoOpacity for the camera background when show_camera_background is enabled.
bubble_countNoMaximum number of live/recyclable bubbles in the simulation.
lifetime_secondsNoSeconds each bubble remains visible before popping and disappearing.
emit_on_open_palmNoWhen true, emit only while an open palm is detected in hand_chop_path.
fallback_to_pose_wristsNoOptional fallback: when hand tracking has no landmarks, emit from pose wrist landmarks. Disabled by default so bubbles are created only by an open palm.
show_body_contourNoRender the tracked body as a visible contour in the same output as the bubbles, so collisions read as performer interaction.
body_contour_widthNoLine width in pixels for the visible body contour overlay.
hand_emit_rateNoBubbles emitted per second while the palm is open.
palm_open_thresholdNoWorld-space average wrist-to-fingertip distance required to treat the hand as an open palm.
gravityNoDownward acceleration in screen-space units per second squared.
body_radiusNoCollision radius around each tracked body/hand landmark, in screen-space units.
wall_bounceNoEnergy retained when bubbles hit the left/right/top screen bounds.
floor_bounceNoEnergy retained when bubbles hit the lower screen floor.
dragNoAir drag applied to bubble velocity each second; higher settles faster.
buoyancyNoSmall upward force countering gravity; keep below gravity for weighted bubbles.
skeleton_impulseNoHow strongly moving body/hand landmarks transfer motion to bubbles.
bubble_repulsionNoSoft collision force between bubbles so they do not collapse into one point.
tracking_smoothingNoTemporal smoothing for body/hand colliders inside the bubble solver.
output_resolutionNoRender resolution [width, height] for the output TOP.
expose_controlsNoExpose live EmitRate/Gravity/BodyRadius/Lifetime/Bounce controls on the container.
Behavior4/5

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

Annotations provide basic hints (non-readonly, non-destructive, open world). The description adds substantial behavioral context: bubbles stay inside screen, settle on floor, pop after configurable lifetime, and builds a self-contained COMP with physics solver and various controls. No contradiction with 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?

The description is front-loaded with the main purpose but becomes verbose towards the end listing all sub-components and controls. It could be more concise by grouping technical details. However, it is still readable and informative.

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

Completeness3/5

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

Given the complexity (27 parameters, no output schema), the description covers the system behavior and dependencies well. However, it lacks explicit mention of the output type (a TOP? a COMP?) beyond parameter references. The user may need to infer that the tool creates a component outputting a TOP.

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 baseline 3. The description provides an overall system overview but does not add significant per-parameter meaning beyond what the schema already gives. The parameter descriptions in schema are already very detailed.

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 clearly states it creates a MediaPipe-ready interactive bubble installation with specific behaviors: open palm emits bubbles, body/hand landmarks act as colliders, body contour rendered. This is distinct from sibling tools like create_body_reactive or create_blob_reactive, which likely have different visual outputs.

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

Usage Guidelines3/5

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

The description implies usage context by requiring hand_chop_path and body_chop_path from setup_hand_tracking and setup_body_tracking/create_pose_tracking. It notes default behaviors (low bubble count, disabled wrist emission) but does not explicitly tell the agent when to choose this tool over alternatives or when not to use it.

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