R3

The size and place of meshes and imported models, in R3 units (metres): the world-space box around each (min, max, size, centre), the mesh's scale, rotation and parents applied. Name a Mesh, or the root Empty of a Blender model (r3_blender_import makes one, named "<model>_root"), and the box covers it and every mesh under it, with each part listed. Use it before scaling or placing anything relative to its size: to stand a model on the ground, move it so its min.y is the ground height (r3_terrain_height on a terrain); to make it 2 m long, scale by 2 / size. Several in one call (up to 20). Works…

Read back what components actually hold — a material's colour and roughness, a mesh's position, which material it uses. r3_project_load gives you the names; this gives you the values behind them. Pass SEVERAL entityRefs in one call — telling six similarly-named materials apart is the case this exists for, and it is one round trip rather than six. What comes back is exactly what r3_component_set takes, so read → change → write needs no translation: value components are expanded inline ({"position": {"x": 0, "y": 2, "z": 0}}), references are the target's entityRef as a string (or null when emp…

Set one or more properties on a component that already exists in a project — a material's roughness, a mesh's position, which material a mesh uses. Kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save (r3_editor_set is the same tool). The answer says what was kept and its seq. Components are addressed by entityRef; r3_project_load returns those names. Properties come in four shapes and the value you pass differs: • plain value — {"roughness": 0.25}, {"visible": false} • value component (position / rotation / scale…

Every R3 document this server can give you, IN READING ORDER, with what each one covers and how big it is. R3's documentation begins here: no model has R3 in its pretraining, and code written from tool descriptions alone saves cleanly and then silently does nothing. r3_docs_read returns one.

Return one R3 document in full, or one API symbol. Paths come from r3_docs_list: r3_docs_read("CODE_PATTERNS.md") how a Code component is written (reading order 1) r3_docs_read("PHYSICS_USAGE.md") colliders, rigid bodies, joints r3_docs_read("HOWTO_PHYSICS.md") one task step by step (how-tos: r3_docs_list) r3_docs_read("api") index of every component, system and event r3_docs_read("api/component/Mesh") one component r3_docs_read("api/system/PhysicsRapier") one system r3_docs_read("api/event/KEY_DOWN") one event, and …

The same tool as r3_component_add (this is its older name): add one component of ANY registered type — a collider, a rigid body, a joint, a light, a material, a geometry … — with its values and references set before it is created, kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. Use r3_editor_create for a ready-made object. `type` is the short type name, e.g. "ColliderCuboid" (an unknown type is refused with the list). `values` take r3_component_set's shapes: a plain value {"friction": 0.2}; a value component as th…

Capture the canvas of a project open in the user's R3 editor — the scene as it looks NOW, running physics included — and LOOK at it: the answer is an image. Call it after a visual change (r3_editor_set, r3_editor_create, r3_editor_code …) to check what you built, and after r3_editor_run to see it move. By default (`camera: "editor"`) it is what the user sees: the editor's view camera, edit aids included. `camera: "project"` takes it through the project's own camera instead, with no edit aids, as a visitor sees it: use that to check a camera or a camera script. At most 1280 px each way (`width`…

The same tool as r3_code_write (this is its older name): replace a Code component's code, kept at once in the project's live copy: every R3 tab with the project open runs the new code now, no editor needed and nothing to save. Name it with componentId or entityRef and pass baseVersion, the codeVersion r3_code_read answered: code is never merged, so on an older version it is refused with the current code and version (apply your change to that and call again). The code is a FUNCTION BODY (a top-level `return {start, update};`); read r3_docs_read("CODE_PATTERNS.md") for the R3 APIs. A syntax erro…

The same tool as r3_factory_run (this is its older name): add an object — a cube, sphere, light, physics body … — kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. r3_factory_list lists the factories and their params.

Delete components from the project the user has OPEN in their R3 editor, exactly as the editor's delete dialog asks it — in TWO calls. First call WITHOUT `confirm`: it returns the plan and changes nothing — the selected components, what only they use (their geometry, material, colliders …), an Entity's members, the modes on offer and a planToken. Then call again with the same componentIds and confirm: {"mode": …, "planToken": …}: "one" deletes only the selection, "with_dependents" also what only it uses, "bundle" (one Entity) the entity with its members. The mode is the user's choice, unless t…

Read what components hold RIGHT NOW in an R3 tab that has the project open: runtime values included — a moving body's position while the project runs. Use it to debug live behaviour. It needs a tab with the project open (r3_editor_open opens one). r3_component_read reads the kept values without a tab. Select with any of: `ids` (component ids from r3_project_load), `type` ("Mesh", "RigidBodyDynamic", …) and `entityRef`; they combine. `fields` keeps only the properties you name (e.g. ["position", "rotation"]). At most 50 components per call; a larger answer is refused with how to narrow it. Va…

Open a project in the R3 editor the user has open in their browser (their most recently used R3 tab) and focus it, so they see it. A project already open there is just focused (never reloaded). It is how the user gets to see the project you are working on, and how a tab gets the project r3_editor_inspect reads. The same access rules as opening it by hand: the user's own projects, their teams', and public ones. The editor holds up to 4 projects; at that limit it refuses. Nothing is saved or changed. When no editor is open, the answer says where the user can open one.

Press the Run buttons of the user's open R3 editor: start physics, code, audio and music (all of them, or the ones named in `systems`), exactly as the user's own click does — a paused simulation resumes. Use it to TEST what you built: run it, then look with r3_editor_capture and read live values with r3_editor_inspect. Changes nothing saved. The systems serve every project open in that editor tab. The scene only moves while that tab is in front: a browser pauses a background tab, and the answer then says the scene is NOT advancing. Needs the editor:run right.

The same tool as r3_component_set (this is its older name): change properties of a component, kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save. Name the component with componentId or entityRef. `values` take r3_component_set's shapes: a plain value {"roughness": 0.25}; a value component as an object of the keys to change {"position": {"y": 2}} (an EMPTY slot, e.g. a rigid body's centerOfMass, is made from the fields given: {"centerOfMass": {"z": -0.3, "mass": 8}}); a reference as the target's entityRef {"material": …

Use what the project's camera shows NOW, in the user's open R3 editor, as the project's share image: the picture its live page, link previews (social cards) and the showcase show, used when the project is next published (r3_publish_live, or Publish update in the editor). The editor waits until the scene's textures have loaded and takes it without edit aids (no grid, gizmos or outlines), as a visitor sees it; the answer is the picture it set. It is for once the project looks right (r3_editor_capture shows it beforehand), or when the user asks for a new picture. A live page keeps the share image…

Press the Stop buttons of the user's open R3 editor: stop physics, code, audio and music (all of them, or the ones named in `systems`), exactly as the user's own click does. Stopping physics puts every body back where it was placed. Changes nothing saved. Needs the editor:run right.

Undo the last change YOU (this agent key or app connection) made to a project: everything one of your tool calls changed is undone together, and the user sees it at once in any R3 tab that has the project open. Use it when your own change was wrong or the user asks you to take it back. It never undoes the user's changes or another agent's: only yours. `count` undoes your last few changes, newest first. If someone else changed the same thing after you, that change of yours is SKIPPED: nothing is changed, the answer says who changed what, and that change of yours is dropped from your history (t…

List the R3 factories available to r3_factory_run, with each one's options, types and defaults. A factory builds a complete, correctly-wired object — a cube is a mesh plus geometry plus material plus colour, already connected. Call this before r3_factory_run if you are unsure of a factory name or its options.

Add an object to an existing R3 project — a cube, sphere, terrain, lighting, a physics body, and so on. Each factory builds a complete, correctly-wired object (mesh + geometry + material + colour, already connected), so you never assemble components by hand. Kept at once in the project's live copy: every R3 tab with the project open shows it now, no editor needed and nothing to save (r3_editor_create is the same tool). The answer says what was kept and its seq. Use r3_factory_list to see the factories and their options.

Set the instructions that ship WITH a project — controls, what to press, what it does. R3 renders them in a modal behind a floating "?" button and the H key, in the editor and in the live portal alike, so whoever opens your preview link can read them. This is the built-in surface for that, so a Code component needs no overlay of its own. The body is markdown — headings, bullets, `code`, links: the controls as a player needs them, e.g. "## Controls\n\n- `Space` — jump". A project has ONE help. Call this again and it replaces the text rather than adding a second. REPLACING needs baseVersion, t…

Store a small image YOU generated in this R3 account's image library and get back the URL for it — the value R3ComponentTexture.url takes. This is how you make a checkerboard, a gradient, a test grid or a noise tile and then actually put it on something with r3_component_set. Pass the image as a base64 data URL (data:image/png;base64,…), up to 1MB decoded. PNG, JPEG, GIF and WebP are stored; PNG is the right choice for a generated pattern. This is NOT a way to upload an image file you already have. You would have to emit every byte of it as base64, which for a real texture is far more output…

List the images this R3 account owns, with the URL to use for each one. That URL is exactly what R3ComponentTexture.url takes, so this is how you find the account's own artwork — a wood grain, a logo, a skybox — and then point a texture at it with r3_component_set. Search by name rather than paging: search: "wood" is matched against every image on the account by the server, not against the page you happen to be holding. Each row says whether it is a "texture" (an ordinary image for a material slot) or an "environment" map (.hdr / .exr). Those two are not interchangeable: an environment map b…

Create a shareable preview link for a saved R3 project, so a person can open it in a browser and see it running. The link is valid for 7 days and does NOT make the project public; making a new one is free. It is how the user sees what you built. Takes the projectId returned by r3_project_create. When an R3 tab has the project open, the project's picture (its card and the link's image) is refreshed from that tab; when none has, the picture refreshes the next time the project is opened in R3.

Remove the preview link of an R3 project: every preview link to it stops working at once (teammates' too). Only when the user asked for it, or when the preview link is what blocks an r3_project_delete the user asked for: a preview link is temporary, so it may then be removed without a separate request, and the user is told it was removed. A live project stays live; a project that was only previewed is no longer published. Deletes nothing: r3_preview_create makes a new link. A project with no open preview link is refused and left as it is. Needs the publish:preview right.

What OTHER people changed in a project — the user in any R3 tab, their other agents — oldest first, grouped per author and per thing: properties set, code and help updated (with versions), components added, deleted or restored, the project renamed. Your own changes are never listed. Every answer about a project already ends with a short "Since your last call" line; this is its full list. Without `since`: from where you last looked (and moves that mark to now, unless advance: false). The mark belongs to your agent key or app connection, not to the conversation: two conversations on one share i…

Create a new R3 project and save it to the user's account. Produces a complete, openable project — scene, world, camera, renderer, lighting, audio listener and music transport — ready for components to be added. Pass `template` for a phone project (mobile-portrait / mobile-landscape) that fills the screen when published. Returns the project id, which every other project tool takes. r3_whoami confirms which account it is created in.

Permanently delete an R3 project. With the project:delete:created right (on by default), only a project YOU created (this agent key or app connection) — use it to clean up your own abandoned attempts; the user's own projects and other agents' are refused. With project:delete:owned, any project the user owns, and only when the user asked for it: pass owned: true for a project you did not create (an app connection is then asked for that right). A published project (live, or with an open preview link) is refused: it must be taken offline first. If the refusal is for a preview link (temporary, 7 d…

List the projects this R3 account can work on — its own and its teams' — last updated first, with the projectId every other project tool takes. It is how a project the user names ("my slot machine") rather than giving an id is found: search for it; its projectId is what r3_project_load takes. Search by name rather than paging: search: "slot" is matched (case-insensitively, anywhere in the name) against EVERY project by the server, not against the page you are holding. Names are not unique: when more than one project matches, the candidates' name, team and last save tell them apart, and which …

List the components in an existing R3 project — what it contains and, for each one, its entityRef: the name code addresses it by (`this['mesh_cube_1']`). Read this before writing any code for a project, and after any tool call whose outcome was reported as unknown, to see what actually landed. Value components (Vector3, Color, Scalar) are not listed individually — reach them through their owner, e.g. `mesh.position.x`.

Rename a project: the name shown in the user's project list, the editor's title and the live page. The same change as clicking the title in the R3 editor, kept at once in the project's live copy (every open R3 tab shows it). The public address does not change: a preview or live link keeps working. Scripts are not affected (they never address the project by name). Renaming a COMPONENT is not this tool: that is done in the R3 editor.

Publish an R3 project live: makes a RELEASE (a frozen copy) of the project as it is now and makes it the one its public live URL shows, for anyone. Only when the user asked for it. Changing the project does NOT change the live site; r3_publish_live does: on a project that is already live this is a publish update (a new release replaces the live one), and the answer names the release number and what changed since the previous live release. `note` (optional, up to 500 characters) is stored with the release. Going live the FIRST time uses one of the live-project slots of the project owner's plan …

Read the publish settings of one of the user's own R3 projects in this environment — what the app's Deploy → Settings shows: Works on (keyboard / touch / both / not tested), the SEO title and description that search engines and link previews show, how the live page starts (Start button, first click, on load), its controls and badge, and what Save does for a live project. Also answers a SUGGESTION for Works on, from a scan of the project's code for keyboard / touch / pointer handlers — only a suggestion. r3_publish_settings_set changes them. Needs the project:read right.

Change publish settings of one of the user's own R3 projects in this environment — the app's Deploy → Settings. Only the settings named change (the rest stay as they are). Only when the user asked for it, or approved the text: these settings shape the PUBLIC live page — its title and description in search results and link previews (seoTitle, seoDescription), Works on (keyboard puts a "made for a keyboard" note on phones and a "desktop" badge; touch a "mobile" badge; both, both; untested none — set it only after the user confirmed it or it was tested, never from the code scan alone), how it sta…

List the releases of an R3 project, newest first: number, date, who made it, note, size, which one is LIVE (what the public URL shows), pinned, and releases in the trash (restorable for 7 days). Also says whether the project has saved changes that are not live yet: saving does NOT change the live site; r3_publish_live does. Read-only. Needs the project:read right.

Put a project's working copy back the way one of its releases (saved versions) had it: components added since are removed, removed ones come back, values and scripts go back to that version (each script as a new version on top of the current one), and the name. The user sees it at once in any R3 tab that has the project open. Only when the user asked for it. Two steps: WITHOUT planToken it changes nothing and says what restoring would change, with a planToken; the same call WITH that planToken, once the user has seen the plan and agreed, restores. If the project changed in between, nothing is…

Make an earlier release of a live R3 project the one its public URL shows again (rollback, or forward again). Only when the user asked for it. The project must be live; this never uses a plan slot. A release in the trash or one marked incomplete is refused. Nothing is deleted: the release that was live stays in the list. Take the number from r3_release_list. Needs the publish:live right.

The public R3 roadmap: what is planned, in progress, proposed by the community and shipped, with each item's vote count and whether the user has voted for it — plus the user's OWN suggestions still awaiting R3's approval, marked pending, and the ones R3 declined, marked declined with R3's reason (only the user sees them; neither is votable); a declined item is not suggested again. It shows whether an item already covers an idea before r3_roadmap_suggest: r3_roadmap_upvote votes for that one instead of a duplicate. Narrow it with `search` (title and description, any case) and `status`.

Suggest a feature for R3's public roadmap, in the user's name and naming you (your agent key or app connection). It is HELD until R3's team approves it: not public, not votable, until then. r3_roadmap_list shows whether an item already covers it (r3_roadmap_upvote votes for that one instead). A good suggestion says what the feature lets a person do and why (what was being built when it was missed). Something broken rather than missing is r3_bug_report's. Rate-limited per agent key or app connection (a few a day). Needs the roadmap:suggest right.

Add the user's vote to a public roadmap item (its id from r3_roadmap_list), when the user wants it or it covers what you were about to suggest. One vote per user: an item the user already voted for stays voted, and this never removes a vote. Needs the roadmap:vote right.

How high the ground of a heightfield terrain is at the world (x, z) positions you ask, exactly as physics and the drawn terrain have it, plus the terrain's lowest and highest point, centre, size and footprint. Use it to place something ON a terrain: an object stands on the ground at (x, z) when its lowest point is at the returned y (a vehicle: its wheels' bottom); the returned ground normal says how steep it is there. One call takes up to 100 points; with none it describes the terrain only. `terrain` is the terrain's Mesh, GeometryHeightfield or ColliderHeightfield (entityRef or id); leave it…

Wire a texture set to a material in a project: the colour map to `map`, the normal map to `normalMap`, the ambient-occlusion / roughness / metalness map to `aoMap` + `roughnessMap` (+ `metalnessMap` when the set is metallic), the SAME repeat on every map, and roughness 1 (THREE multiplies the roughness map by the material's roughness; the default 0.5 would halve it). Creates one Texture per map, or reuses a Texture of the project already on that image. MaterialStandard / Physical get every map; Lambert / Phong / Toon get map, normalMap and aoMap; Basic is refused (unlit). `repeat` is how often…

Make a matching, seamlessly tiling texture SET for a material: a colour map, a normal map and a packed ambient-occlusion / roughness / metalness map, rendered by R3 from a procedural recipe (seeded noise, stones, bricks …). Nothing is uploaded and it is free. The maps are stored as images in the account (the owner sees them in the Images browser as "<name> · albedo.png" …). Start from a preset (gravel, sand, concrete, bricks) with optional controls: seed (another variation), scale (an integer: finer pattern), colours (the ramp's "#rrggbb" stops), contrast, bumpiness (normal strength), roughne…

Read one texture set: its name, size, tile size, the three map urls, the numbers its render measured, the sets it was edited from, and the full RECIPE (the editable source). The account's own sets, or anyone's public one. To change a set, r3_texture_update makes a new version of it.

Change a texture set the account owns: its look (controls: seed, scale, colours, contrast, bumpiness, roughness {min, max}, size, tileWorldSize, height, applied to the set's own recipe; `scale` multiplies its pattern, so 2 is twice as fine as now) or a whole new `recipe` (read the current one with r3_texture_read, change it, pass it here). The set itself never changes: the change is saved as a NEW set ("Gravel" → "Gravel 2", or the `name` you give) that links back to it, and every project and release that uses the old maps keeps them. The answer names the user's projects still on the old maps;…

Take a live R3 project offline: its public live URL stops working at once, and the live-project slot it used on the plan is free again. Only when the user asked for it. Other people open a live project, so one that blocks an r3_project_delete goes offline only once the user has been asked and agreed, never as a step of the delete. Deletes nothing: the project, and any preview link, stay; r3_publish_live makes it live again. A project that is not live is refused and left as it is. Needs the publish:live right.

Report the R3 account you act for, how you are connected (an agent key, or an app connection made with Sign in with R3), what you are allowed to do, the account's plan (its name and how many live projects it allows and uses: going live needs one), and whether the R3 platform is reachable. It verifies the credential end to end and names the capabilities it carries, so it is the call that confirms the account before any other tool. For an account with no project yet it gives the first step.