cozyclay 1.2.0 → 1.5.0

package/dist/index.html

@@ -3,7 +3,7 @@
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
-    <meta name="description" content="CozyClay is an open-source, browser-based 3D staging and previz studio. Block a scene, pose characters, author camera moves and cuts, and preview generated motion — no Blender, no Unity, no install." />
+    <meta name="description" content="Free, open source previs software that runs in the browser. Block a scene, pose characters, and author camera moves and cuts, then hand the same shots to an AI video model. No Blender, no Unity, no install." />
     <meta name="theme-color" content="#232323" />
     <meta name="apple-mobile-web-app-title" content="CozyClay" />
     <link rel="canonical" href="https://cozyclay.org/" />
@@ -14,19 +14,19 @@
 
     <meta property="og:type" content="website" />
     <meta property="og:site_name" content="CozyClay" />
-    <meta property="og:title" content="CozyClay — browser-based 3D staging and previz studio" />
+    <meta property="og:title" content="CozyClay — open source 3D previs software, in your browser" />
     <meta property="og:description" content="Block a scene, pose characters, author camera moves and cuts, and preview generated motion. Open source, runs in your browser." />
     <meta property="og:url" content="https://cozyclay.org/" />
     <meta property="og:image" content="https://cozyclay.org/media/cozyclay-demo-poster.jpg" />
     <meta property="og:image:width" content="1920" />
     <meta property="og:image:height" content="1080" />
-    <meta property="og:image:alt" content="A CozyClay shot mid-wipe: the greybox previz on one half, the generated result on the other." />
+    <meta property="og:image:alt" content="A CozyClay shot mid-wipe: the greybox previs on one half, the generated result on the other." />
     <meta name="twitter:card" content="summary_large_image" />
-    <meta name="twitter:title" content="CozyClay — browser-based 3D staging and previz studio" />
+    <meta name="twitter:title" content="CozyClay — open source 3D previs software, in your browser" />
     <meta name="twitter:description" content="Block a scene, pose characters, author camera moves and cuts, and preview generated motion. Open source, runs in your browser." />
     <meta name="twitter:image" content="https://cozyclay.org/media/cozyclay-demo-poster.jpg" />
 
-    <title>CozyClay — browser-based 3D staging and previz studio</title>
+    <title>CozyClay — open source 3D previs software, in your browser</title>
 
     <meta property="og:video" content="https://cozyclay.org/media/cozyclay-demo.mp4" />
     <meta property="og:video:type" content="video/mp4" />
@@ -67,7 +67,23 @@
             "name": "What is CozyClay?",
             "acceptedAnswer": {
               "@type": "Answer",
-              "text": "CozyClay is an open-source 3D staging and previsualization studio that runs in a browser. You block a scene with primitives and set pieces, pose characters, draw root paths, author camera moves and cuts on a timeline, and preview generated motion."
+              "text": "CozyClay is open source previs software that runs in a browser. You block a scene with primitives and set pieces, pose characters, draw root paths, author camera moves and cuts on a timeline, and preview generated motion."
+            }
+          },
+          {
+            "@type": "Question",
+            "name": "What is previs, and is it spelled previz?",
+            "acceptedAnswer": {
+              "@type": "Answer",
+              "text": "Previs is short for previsualization: the rough 3D pass where a shot gets blocked — camera position, lens, character movement, cut points — before anyone commits to final assets or render budget. It is written both previs and previz; the industry mostly writes previs, and both mean the same thing."
+            }
+          },
+          {
+            "@type": "Question",
+            "name": "Is there free previs software?",
+            "acceptedAnswer": {
+              "@type": "Answer",
+              "text": "CozyClay is free and open source under AGPL-3.0-or-later, and it runs in the browser. Run it locally with npx cozyclay and nothing leaves your machine. Modified network services must offer their users the corresponding source."
             }
           },
           {
@@ -221,7 +237,7 @@
           <a href="#what">What it does</a>
           <a href="#start">Quick start</a>
           <a href="#controls">Controls</a>
-          <a href="#faq">FAQ</a>
+          <a href="/ai-camera-control/">AI camera control</a>
           <a href="https://github.com/HaD0Yun/CozyClay">GitHub</a>
         </nav>
       </div>
@@ -235,9 +251,9 @@
 
         <h1>Block the shot before you pay to render it</h1>
         <p class="lede">
-          CozyClay is a browser-based 3D staging studio. Block a scene, pose characters,
-          author camera moves and cuts, then hand the exact same shots to a video model.
-          No Blender, no Unity, no install.
+          CozyClay is free, open source previs software that runs in your browser. Block a
+          scene, pose characters, and author camera moves and cuts — then hand the same
+          shots to an AI video model. No Blender, no Unity, no install.
         </p>
 
         <div class="reel">
@@ -249,8 +265,9 @@
           ></video>
         </div>
         <p class="reel-note">
-          Thirty seconds: greybox previz on the left of the wipe, the generated result on the
-          right. Every cut came out of the same camera setup you see being built.
+          Thirty seconds: greybox previs on the left of the wipe, the generated result on the
+          right. Every cut came out of the same camera setup you see being built — more on
+          <a href="/ai-camera-control/">camera control for AI video</a>.
         </p>
 
         <div class="cta">
@@ -266,7 +283,7 @@
       <section id="what">
         <h2>What you can do</h2>
         <p class="sub">
-          Previz is the part of animation where you decide what happens before anyone commits
+          Previs is the part of animation where you decide what happens before anyone commits
           to final assets. CozyClay keeps that whole loop in one page.
         </p>
         <div class="grid">
@@ -355,9 +372,36 @@ npm run dev</code></pre>
         <details open>
           <summary>What is CozyClay?</summary>
           <p>
-            CozyClay is an open-source 3D staging and previsualization studio that runs in a
-            browser. You block a scene with primitives and set pieces, pose characters, draw
-            root paths, author camera moves and cuts on a timeline, and preview generated motion.
+            CozyClay is open source previs software that runs in a browser. You block a scene
+            with primitives and set pieces, pose characters, draw root paths, author camera
+            moves and cuts on a timeline, and preview generated motion.
+          </p>
+        </details>
+        <details>
+          <summary>What is previs, and is it spelled previz?</summary>
+          <p>
+            Previs is short for previsualization: the rough 3D pass where a shot gets blocked —
+            camera position, lens, character movement, cut points — before anyone commits to
+            final assets or render budget. It is written both <strong>previs</strong> and
+            <strong>previz</strong>; the industry mostly writes previs, and both mean the same
+            thing.
+          </p>
+        </details>
+        <details>
+          <summary>Is there free previs software?</summary>
+          <p>
+            CozyClay is free and open source under AGPL-3.0-or-later, and it runs in the browser.
+            Run it locally with <code>npx cozyclay</code> and nothing leaves your machine. Modified
+            network services must offer their users the corresponding source.
+          </p>
+        </details>
+        <details>
+          <summary>Can I use it for camera control in AI video?</summary>
+          <p>
+            That is the reason it exists. Block the shot in 3D — angle, lens, dolly, the frame
+            the cut lands on — then take those camera moves to a video model instead of
+            describing them in a prompt and hoping. See
+            <a href="/ai-camera-control/">camera control for AI video</a>.
           </p>
         </details>
         <details>
@@ -402,7 +446,8 @@ npm run dev</code></pre>
     <footer class="site">
       <div class="wrap">
         <p>
-          <a href="https://github.com/HaD0Yun/CozyClay">GitHub</a> ·
+          <a href="https://github.com/HaD0Yun/CozyClay">Source code (AGPL)</a> ·
+          <a href="LICENSE">License</a> ·
           <a href="https://www.npmjs.com/package/cozyclay">npm</a>
         </p>
         <p>

package/dist/sitemap.xml

@@ -2,8 +2,14 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
     <loc>https://cozyclay.org/</loc>
-    <lastmod>2026-08-14</lastmod>
+    <lastmod>2026-08-15</lastmod>
     <changefreq>weekly</changefreq>
     <priority>1.0</priority>
   </url>
+  <url>
+    <loc>https://cozyclay.org/ai-camera-control/</loc>
+    <lastmod>2026-08-15</lastmod>
+    <changefreq>monthly</changefreq>
+    <priority>0.8</priority>
+  </url>
 </urlset>

package/mcp/LIVE-PROTOCOL.md

@@ -0,0 +1,144 @@
+# CozyClay live-control protocol v1
+
+The MCP JSON-RPC endpoint deliberately negotiates only protocol version
+`2025-11-25`. Older and draft tracks are rejected during `initialize`.
+
+One WebSocket, JSON text frames. The **MCP server hosts** the socket
+(`ws://127.0.0.1:5184/live`); the **editor is the client** and reconnects
+every 3 s while the page is open. Either side may be absent: the editor works
+exactly as before when nothing is listening, and the MCP server falls back to
+its in-memory scene when no editor is connected.
+
+## Frames
+
+editor -> server, once after connect:
+
+    { "type": "hello", "role": "editor", "version": 1 }
+
+server -> editor, once after `hello`:
+
+    { "type": "workspace", "handle": "<opaque workspace handle>" }
+
+The handle is newly issued for this socket connection. The editor surfaces it to
+its operator. A disconnect invalidates it; a reconnect receives a fresh handle.
+The editor also sends its stable per-tab `workspaceId` in `hello`; it is not an
+MCP tool argument and lets the hub route retained terminal motion outcomes to
+the same editor after that fresh handle is issued.
+
+server -> editor, one per command:
+
+    { "type": "cmd", "id": "<opaque string>", "name": "<command>", "args": { ... } }
+
+server -> editor, for an MCP-owned motion job state or terminal outcome (and again
+on reconnect while retained). A completed event follows the editor's successful
+`load_motion` acknowledgement:
+
+    { "type": "event", "name": "motion_job", "payload": { "taskId", "status", "createdAt", "lastUpdatedAt", "ttlMs", "pollIntervalMs", "outcome?" } }
+
+editor -> server, to cancel its own active job before editor delivery:
+
+    { "type": "event", "name": "motion_job_cancel", "payload": { "taskId": "<opaque task id>" } }
+
+editor -> server, one per command, echoing `id`:
+
+    { "type": "result", "id": "<same id>", "ok": true,  "value": { ... } }
+    { "type": "result", "id": "<same id>", "ok": false, "error": "<human message>" }
+
+Unknown `name` MUST answer `ok:false`, never silence. The server times a
+command out after 5 s and treats it as failed, except `load_motion`, which
+retains its dedicated 30 s editor decode and installation bound. Measurement
+justifies the existing headroom: 12 real editor installs of one 94,672-byte
+ARDY NPZ had nearest-rank p50 29.96 ms, p95 547.29 ms, and p99 547.29 ms;
+30 s remains appropriate for materially larger cold-cache production takes. A timeout or disconnect during
+a mutation is ambiguous: it may already have applied, so callers MUST NOT retry
+blindly and should `describe` before recovering.
+
+## Motion jobs
+
+`generate_motion` returns immediately with exactly `{ taskId, status, createdAt,
+lastUpdatedAt, ttlMs, pollIntervalMs }`; `pollIntervalMs` is `0` because the
+model never polls it. The MCP server retains terminal outcomes for `ttlMs`
+(currently 10 minutes) and pushes `motion_job` to the matching stable workspace
+on completion, failure, cancellation, or reconnect. For a completed job, the
+server first installs the take through the request/response `load_motion`
+command, then publishes the terminal lifecycle event. The event never installs
+the take a second time. A retained outcome that passes its TTL is explicitly
+expired and is never replayed.
+
+If the editor explicitly rejects `load_motion`, the job transitions to `failed`
+and publishes that terminal event. If the socket disconnects or times out while
+installation is in flight, the job also fails but is not retried: the mutation
+may already have applied, so retrying could install the same take twice.
+
+Cancellation is cooperative at the bridge HTTP stream: `motion_job_cancel`
+aborts that request. The ARDY bridge detects the disconnected stream and kills
+its request-owned child process groups. A cancelled job is terminal and is never
+sent to editor installation. There are no `tasks/*` tools or start/status/list
+polling tools in the MCP surface.
+
+## Commands (v1)
+
+All coordinates are metres, rotations are degrees of yaw, ids are the ids the
+scene document already uses.
+
+| name | args | value | notes |
+| --- | --- | --- | --- |
+| `ping` | `{}` | `{ "pong": true }` | liveness |
+| `describe` | `{}` | `{ document, sceneName, camera, stage, timeline, activeCharacterId, characters, objects }` | read the full live scene document plus active-scene convenience fields; the full `document` prevents one workspace's inactive scenes from leaking into another workspace's scene operations; `activeCharacterId` pins asynchronous work to the character selected when it started |
+| `capture_frame` | `{}` | `{ width: 640, height: 360, mimeType: "image/png", encoding: "base64", byteSize, data, assertions: { renderable, blackFrame, nonBlackPixels, behindCameraPlane, fartherAlongCameraForward, distanceToFloor, occludedBy, visiblePixelCount, characters } }` | leaves the authored document untouched, but is classified open-world/non-idempotent because an oversized PNG creates a mode-0600 managed temporary artifact. Character visibility and occlusion are computed from mounted engine geometry with bounded ray samples. Missing camera, black frame and compressed payloads above 1 MB fail explicitly. Inline responses honor `max_inline_bytes`; managed artifacts are capped at 20 and expire after 10 minutes. |
+| `set_camera` | `{ x?, y?, z?, focalMm? }` | `{ camera }` | omitted fields keep their value; the **viewport must visibly move** |
+| `add_character` | `{ subject, x?, z?, rot?, model? }` | `{ id }` | `model` is one of the stable character model ids |
+| `update_character` | `{ ref, x?, y?, z?, rot?, subject?, hidden? }` | `{ id }` | `ref` = id, letter (`"A"`) or 1-based slot |
+| `remove_character` | `{ ref }` | `{ id }` | must refuse to empty the cast |
+| `place_object` | `{ kind, x?, z?, y?, rot?, name?, parent? }` | `{ id }` | `kind` from OBJECT_LIBRARY; optional `name` labels the object and optional `parent` attaches it under another object |
+| `update_object` | `{ id, x?, y?, z?, rot?, rotX?, rotZ?, scale?, scaleX?, scaleY?, scaleZ?, color?, name? }` | `{ id }` | `scale` sets all three axes; per-axis values override it; `name` renames the object |
+| `remove_object` | `{ id }` | `{ id }` | |
+| `group_objects` | `{ parent, children }` | `{ parent, children }` | attach every child under parent |
+| `ungroup_objects` | `{ children }` | `{ children }` | detach every child |
+| `apply_batch` | `{ ops, atomic?: false, stopOnError?: true, label?: "MCP batch" }` | `{ label, applied: number[], failed: [{ index, error }], rolledBack }` | executes at most 100 object mutations as one undo entry. `atomic` and `stopOnError` are independent; atomic failure restores the pre-batch objects and creates no undo entry. Nested batches are rejected. v1 rejects character mutations because cast history is a separate store. |
+| `set_prompt_blocks` | `{ blocks: [{ startFrame, endFrame, text }] }` | `{ blocks }` | replace the active character's authored prompt clips after validating each frame range and text |
+| `load_motion` | `{ url, prompt?, blocks?, drop? }` | `{ loaded, url, blocks }` | install an ARDY motion on the selected character. It has the dedicated 30-second editor-processing timeout; motion-job completion carries the character id captured when generation started |
+| `load_scenes` | `{ document }` | `{ sceneName, activeSceneId, scenes: [{ id, name }] }` | replace the whole scene document (same shape `serializeSceneDocument` emits); the response attests the full scene list and active scene for `add_scene` and `switch_scene` parity |
+
+## Hard rules for the editor side
+
+- Every mutation MUST go through the same React state paths the UI itself
+  uses (the setters/reducers the gizmo, inspector and panels call). Mutating
+  three.js objects directly is forbidden: anything outside React state is
+  overwritten on the next render.
+- Every mutation MUST land in undo history exactly like the equivalent UI
+  action would, or be explicitly documented as not undoable.
+- The socket client MUST be a no-op in production builds unless explicitly
+  enabled; in dev it may always try. A failed connection must never surface
+  an error to the user - silence and retry.
+
+## Workspace routing
+
+The hub allows multiple editor instances at once; it never displaces an existing
+editor for a newer connection. `live_status` lists every current workspace
+handle. Every MCP tool that reads or mutates a live editor accepts `workspace_handle`.
+When exactly one editor is connected, omitting it selects that editor. With two
+or more editors, omitting it fails before dispatch and enumerates every candidate
+handle. An unknown or disconnected handle fails as unknown or stale and is never
+routed to another editor. The hub owns this resolution rule for every transport;
+there is no last-active, heartbeat, focus, or recency fallback.
+
+## Hard rules for the server side
+
+- When an editor is connected, live-capable tools forward to the workspace
+  selected by the rules above and answer from that workspace's `describe`; when
+  none is connected they fall back to the in-memory scene exactly as today.
+- `add_scene` and `switch_scene` forward the complete scene document through
+  `load_scenes` and verify it through `describe` before reporting success. They
+  never succeed while the MCP server and selected editor have different scene
+  lists. Without an editor they retain the in-memory fallback.
+- A live mutation may only target the explicitly selected workspace, except for
+  the exactly-one-editor auto-selection case. Ambiguity is an error, never a
+guess.
+
+Browser editor connections are accepted only from loopback HTTP origins, and a
+stable workspace id may have only one live socket. Native loopback clients have
+no Origin header and remain part of the trusted-local MCP boundary.
+- Any bounded MCP read reports `total`, `returned`, `truncated`, and a
+  `revision`. Omitted entries must be reachable by an explicit selector or
+  cursor; `describe_scene` uses `character_cursor` and `object_cursor`.

package/mcp/README.md

@@ -0,0 +1,160 @@
+# CozyClay MCP server
+
+Lets an AI assistant (Claude Desktop, Cursor, any MCP client) block a scene, place the camera,
+generate character motion and read the shot back as film vocabulary — then turn it into an AI
+image/video prompt.
+
+Works two ways, with one tool catalog:
+
+- **Editor open** — tool calls drive the visible viewport live: camera, cast, set, motion,
+  prompt blocks on the timeline.
+- **No editor** — scene, camera, prompt and project-file tools run in memory with no browser,
+  GPU or build step. `capture_frame`, `set_prompt_blocks`, `generate_motion`, and
+  `apply_batch` explicitly require a live editor.
+
+## Run it locally
+
+```sh
+cd mcp
+npm install
+npm start          # speaks MCP over stdio and hosts ws://127.0.0.1:5184/live
+npm run verify     # drives the no-editor fallback as a client and checks results
+npm run verify:live # drives a fake editor over the live WebSocket protocol
+```
+
+Then point a client at it. For Claude Desktop, in `claude_desktop_config.json`:
+
+```json
+{
+  "mcpServers": {
+    "cozyclay": {
+      "command": "node",
+      "args": ["/absolute/path/to/CozyClay/mcp/server.mjs"]
+    }
+  }
+}
+```
+
+Restart the client; 24 tools appear.
+
+Prefer a long-lived endpoint? `node server.mjs --http 5183` serves Streamable HTTP at
+`http://127.0.0.1:5183/mcp` (one isolated session per client), with a plain status page at `/`.
+
+## What it does
+
+Describe the shot you want. The server does the trigonometry and answers the way a crew would.
+
+> "Put a detective and a courier in an alley, then give me a low wide profile shot of the courier."
+
+```
+WIDE SHOT · RIGHT PROFILE · KNEE LEVEL · 24MM
+
+size      wide shot — the subject fills 40% of frame height
+view      a right-side profile view
+level     a low knee-level angle looking up at the subject
+distance  4.39m
+```
+
+`render_prompt` turns that same geometry into a prompt that carries the real framing, so the
+generated frame matches the blocking instead of drifting off into a generic shot.
+
+## Tools
+
+| tool | what it does |
+| --- | --- |
+| `describe_scene` | the whole state: camera, framing, cast, set |
+| `live_status` | whether an editor tab is connected for live control |
+| `describe_shot` | current camera geometry as film vocabulary |
+| `capture_frame` | a compressed live render with camera-plane, visibility and occlusion assertions |
+| `set_camera` | move the lens / change focal length directly |
+| `frame_shot` | frame by intent — size, view, level, side |
+| `add_character` / `place_character` / `remove_character` | the cast |
+| `focus_character` | choose who the camera frames |
+| `place_object` / `update_object` / `remove_object` | the set — `place_object` also accepts `name` and `parent`, so multi-part assets like "Building A" land as one named assembly |
+| `group_objects` | attach children to a parent so they move as one; pass `parent: null` to detach |
+| `apply_batch` | execute up to 100 object mutations as one user-visible undo transaction |
+| `render_prompt` | the shot as an AI image or video prompt |
+| `generate_motion` | multi-phase character motion through the ARDY bridge — phases land as prompt blocks |
+| `mark_camera_move` / `describe_camera_move` | name a move between two camera positions |
+| `add_scene` / `switch_scene` | multiple scenes per project |
+| `open_project` / `save_project` | read and write `.cclayproject` files |
+
+Project file tools are restricted to `COZYCLAY_PROJECT_ROOT` (the server
+working directory by default), accept direct child `.cclayproject` files only,
+anchor relative opens to the retained project-root working-directory inode, reject symlink escapes,
+open the final name with `O_NOFOLLOW`, and require
+`overwrite: true` before replacing an existing regular file.
+
+Coordinates are metres (`x` right, `z` toward the default camera, `y` height above the floor).
+Rotations are degrees of yaw. Characters are addressed by letter (`"A"`), slot (`"2"`) or id
+(`"char-a"`).
+
+## Live editor control
+
+The server hosts `ws://127.0.0.1:5184/live` by default (`COZYCLAY_LIVE_PORT` or
+`--live-port <port>` to change it). Start the editor with that same `COZYCLAY_LIVE_PORT` so its
+Vite build connects to the selected loopback endpoint; `npm run dev` preserves the environment
+variable for the browser. A CozyClay editor tab then connects on its own; `live_status` tells you whether one is attached. With an editor connected, mutations
+forward to it and reads report its real state — the screen you are looking at is the source of
+truth. Without one, headless-capable tools keep their in-memory behaviour while `capture_frame`
+returns an explicit connected-editor error. The other three live-only tools return a readable
+ordinary response explaining that an editor is required. In `--http` mode each session
+child attempts to bind the live port, so one session owns the editor and the others
+intentionally run memory-only.
+
+The wire protocol — one WebSocket, sixteen commands, editor-side rules — is specified in
+[`LIVE-PROTOCOL.md`](LIVE-PROTOCOL.md).
+
+## Motion generation
+
+`generate_motion` takes plain-language beats and a length:
+
+```
+phases: ["seated on a chair, slowly stands up",
+         "breaks into a sprint",
+         "trips and falls hard to the ground"]
+seconds: 10
+```
+
+It tiles them into contiguous ARDY segments, streams the generation through the local bridge
+(`127.0.0.1:5181`, started by `npm run dev`), and — when an editor is connected — loads the
+result onto the active character with prompt blocks on the timeline. Beats longer than the
+per-block limit are split into consecutive blocks, so one phase can produce multiple blocks.
+Pass a previous `motion_url` to reload a clip without generating again.
+
+## Round-trips with the studio
+
+`save_project` writes a real `.cclayproject` file, so a scene blocked here opens in the studio to
+be posed, timed and generated — and a scene built in the studio opens here with `open_project`.
+The configured project-root directory must only be writable by the trusted user running the MCP
+server; project I/O rejects symlinks and hard-linked project files but relies on that directory
+permission boundary to prevent an untrusted local process from adding links during an operation.
+
+## Design
+
+This server owns no geometry, no film vocabulary and no prompt text. Every answer is computed by
+the same modules the studio renders with, imported straight from the working tree:
+
+| module | responsibility |
+| --- | --- |
+| `../src/shot.js` | geometry → film vocabulary → prompt |
+| `../src/scenes.js` | the scene document and its stage envelope |
+| `../src/scene-objects.js` | the set: create / update / remove, clamped and snapped |
+| `../src/camera-move.js` | two framings → a named camera move |
+| `../src/project.js` | the `.cclayproject` envelope |
+
+That is the whole design. Because the imports are relative, the server always speaks the working
+tree's vocabulary: retune a band in `shot.js` and this server reports the new answer on its next
+start, with nothing to publish or reinstall. The studio and the MCP server cannot disagree about
+what a 35mm medium shot is, because there is only one implementation of it.
+
+`frame_shot` is the one place that inverts `shot.js` rather than calling it — it solves for the
+camera position that produces a requested size. `npm run verify` checks all 420 combinations the
+schema accepts, so a retune in `shot.js` fails loudly here instead of quietly mis-framing.
+
+### Framing conflicts
+
+Shot size is treated as the stronger request. An extreme close-up from an overhead lens is
+geometrically impossible on a wide lens — the camera would sit inside the subject — so the server
+lengthens the lens until the requested angle fits and says so, the way a crew swaps glass rather
+than abandoning the close-up.