Skip to main content
Glama

Create RayTK scene

create_raytk_scene

Build a minimal RayTK raymarch scene by selecting an SDF primitive and optional union, material, camera, and light. Requires RayTK toolkit staged and loaded.

Instructions

Build the minimal renderable RayTK node graph (sphereSdf → raymarchRender3D → Null TOP) from RayTK's real ROP COMP masters, copied at runtime — the node-graph-native complement to create_raymarch_scene (which stays the lightweight, no-dependency GLSL path). Optional flags union a second SDF, insert an inline basicMat, and add an explicit lookAtCamera / pointLight. Requires the RayTK toolkit staged + loaded (manage_packages install raytk, then load the .tox); RayTK 0.46 requires TouchDesigner 2025.30770+. Fails forward with 'stage & load RayTK first' guidance when the library is absent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName of the container COMP created for the scene. Defaults to 'raytk_scene_<sdf_primitive>'.
materialNoInsert a RayTK basicMat (material category) inline between the SDF/union chain and the renderer, so the surface gets a base color/shading instead of the renderer default.
add_lightNoAdd a RayTK pointLight (light category) wired into the renderer's Light input (connector index 2, 0-based). Default false uses the renderer's built-in light — leave false for the minimal scene.
add_cameraNoAdd a RayTK lookAtCamera (camera category) wired into the renderer's Camera input (connector index 1, 0-based). Default false uses the renderer's built-in camera — leave false for the minimal scene.
union_withNoOptional second SDF primitive to combine with sdf_primitive via a RayTK simpleUnion (combine category). Omit for a single primitive. Example: sdf_primitive=sphereSdf + union_with=boxSdf yields a merged blob.
parent_pathNoParent COMP path the RayTK scene container is created inside./project1
sdf_primitiveNoPrimary RayTK SDF primitive ROP to raymarch. One of sphereSdf, boxSdf, boxFrameSdf, torusSdf. These are RayTK 'sdf'-category COMP masters copied from the loaded library — not native TouchDesigner operators.sphereSdf
Behavior4/5

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

Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds behavioral context: operators are 'copied at runtime', the tool fails forward with guidance if the library is absent. This goes beyond annotations without contradicting them.

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

Conciseness5/5

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

Two sentences: first sentence states the core action and comparison, second covers options and prerequisites. No wasted words, front-loaded with the essential purpose. Every sentence serves a clear function.

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

Completeness4/5

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

For a tool with 7 fully described parameters and no output schema, the description covers prerequisites, failure mode, and sibling differentiation. It omits details on the exact return value (though the tool creates a node graph, which is implicit). Adequate for the complexity.

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?

Schema coverage is 100%, so baseline is 3. The description briefly summarizes the optional flags (union, material, camera, light), adding meaning beyond the schema descriptions by explaining their role in the node graph. It does not detail each parameter but adds high-level context.

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 the tool builds a minimal RayTK node graph (sphereSdf → raymarchRender3D → Null TOP) and distinguishes itself from the sibling create_raymarch_scene as the 'node-graph-native complement'. The verb 'Build' and the specific resource and structure make the purpose unmistakable.

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?

The description explicitly states prerequisites ('requires the RayTK toolkit staged + loaded') and provides a fallback behavior ('fails forward with guidance'). It contrasts with create_raymarch_scene, implying this tool is for full node-graph control. No explicit exclusions or 'when not to use', but the context is clear enough.

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