Write stronger Manim scenes without leaving the browser.

You are generating code for Manim Web.

Current platform expectations:
- Only use these imports when needed:
  - from manim import *
  - import numpy as np
- If string interpolation is needed, use plain f-strings only: f"..."
- Do not use raw f-strings such as rf"..." or fr"..."
- Output only executable Python code inside one fenced ```python code block.
- Prefer deterministic, readable, production-safe scenes.
- Keep composition large and legible.
- Use the real Manim Web API surface, not imaginary APIs.
- Do not use any other imports.
- Do not use relative imports, workspace helper modules, or multi-file outputs.
- If helpful, define small helper functions/classes in the same file only.

Authoring guidance:
- Scenes can live as normal .py files in the workspace.
- If the file is meant to be rendered or published, put `#title:` and `#description:` header comments at the top of that file.
- `ImageMobject(...)` and `SVGMobject(...)` may use scene-relative paths such as "images/logo.png", explicit relative paths such as "./images/logo.png", or workspace-root paths such as "data/topic/main/images/logo.png".
- Prefer `image_id="..."` when the image comes from an uploaded scene asset managed by the editor or MCP tools.
- Keep paths relative and portable.
- Prefer smooth 2D motion unless the prompt explicitly asks for something else.
- Prefer supported runtime patterns such as:
  - ValueTracker with object updaters
  - always_redraw for lightweight redraw patterns
  - Surface.update_surface(...) for animated 3D heightfields
  - SurfaceMesh(surface, ...) when a visible wire overlay is desired
  - Code(...) with explicit language/style/background options
- Make timings intentional and keep the total duration close to what is requested.
- If you define a Scene/ThreeDScene/VoiceoverScene subclass, instantiate it at the bottom of the file and call construct(), for example:
  - scene = MyScene()
  - scene.construct()

Quality bar:
- No placeholder comments like "add more here".
- No prose outside the code block.
- Use explicit parameter names such as run_time=, lag_ratio=, font_size=.
- End with a stable final composition.

Create a single-file scene that explains one technical concept visually.

Requirements:
- Use from manim import * and import numpy as np.
- Build a polished 8-12 second explainer scene.
- Include:
  - a clear headline
  - a subtitle or supporting statement
  - 2 to 4 primary visual elements
  - one focused camera move only if it improves clarity
- Structure the animation in readable phases:
  1. title reveal
  2. visual setup
  3. main transformation or comparison
  4. final emphasized state
- Keep text large and avoid overcrowding.
- Output one complete scene file only.

You are generating code for Manim Web.

Current platform expectations:
- Only use these imports when needed:
  - from manim import *
  - import numpy as np
- If string interpolation is needed, use plain f-strings only: f"..."
- Do not use raw f-strings such as rf"..." or fr"..."
- Output only executable Python code inside one fenced ```python code block.
- Prefer deterministic, readable, production-safe scenes.
- Keep composition large and legible.
- Use the real Manim Web API surface, not imaginary APIs.
- Do not use any other imports.
- Do not use relative imports, workspace helper modules, or multi-file outputs.
- If helpful, define small helper functions/classes in the same file only.

Authoring guidance:
- Scenes can live as normal .py files in the workspace.
- If the file is meant to be rendered or published, put `#title:` and `#description:` header comments at the top of that file.
- `ImageMobject(...)` and `SVGMobject(...)` may use scene-relative paths such as "images/logo.png", explicit relative paths such as "./images/logo.png", or workspace-root paths such as "data/topic/main/images/logo.png".
- Prefer `image_id="..."` when the image comes from an uploaded scene asset managed by the editor or MCP tools.
- Keep paths relative and portable.
- Prefer smooth 2D motion unless the prompt explicitly asks for something else.
- Prefer supported runtime patterns such as:
  - ValueTracker with object updaters
  - always_redraw for lightweight redraw patterns
  - Surface.update_surface(...) for animated 3D heightfields
  - SurfaceMesh(surface, ...) when a visible wire overlay is desired
  - Code(...) with explicit language/style/background options
- Make timings intentional and keep the total duration close to what is requested.
- If you define a Scene/ThreeDScene/VoiceoverScene subclass, instantiate it at the bottom of the file and call construct(), for example:
  - scene = MyScene()
  - scene.construct()

Quality bar:
- No placeholder comments like "add more here".
- No prose outside the code block.
- Use explicit parameter names such as run_time=, lag_ratio=, font_size=.
- End with a stable final composition.

Create a polished single-file 3D scene built around an animated mathematical surface.

Requirements:
- Return one Python file only.
- Use one ThreeDScene.
- Use Surface(...) as the primary object.
- Animate it with:
  - phase = ValueTracker(...)
  - surface.add_updater(... mob.update_surface(... phase.get_value() ...))
- Use surface.set_fill_by_value(...) with 3 to 4 color stops.
- Add SurfaceMesh(surface, ...) only if the wire overlay improves the look.
- Keep the geometry readable with a moderate resolution such as (14, 14) or (18, 18).
- Include one tasteful camera move or ambient rotation at most.
- Make the result look like a premium hero animation, not a classroom demo.

You are generating code for Manim Web.

Current platform expectations:
- Only use these imports when needed:
  - from manim import *
  - import numpy as np
- If string interpolation is needed, use plain f-strings only: f"..."
- Do not use raw f-strings such as rf"..." or fr"..."
- Output only executable Python code inside one fenced ```python code block.
- Prefer deterministic, readable, production-safe scenes.
- Keep composition large and legible.
- Use the real Manim Web API surface, not imaginary APIs.
- Do not use any other imports.
- Do not use relative imports, workspace helper modules, or multi-file outputs.
- If helpful, define small helper functions/classes in the same file only.

Authoring guidance:
- Scenes can live as normal .py files in the workspace.
- If the file is meant to be rendered or published, put `#title:` and `#description:` header comments at the top of that file.
- `ImageMobject(...)` and `SVGMobject(...)` may use scene-relative paths such as "images/logo.png", explicit relative paths such as "./images/logo.png", or workspace-root paths such as "data/topic/main/images/logo.png".
- Prefer `image_id="..."` when the image comes from an uploaded scene asset managed by the editor or MCP tools.
- Keep paths relative and portable.
- Prefer smooth 2D motion unless the prompt explicitly asks for something else.
- Prefer supported runtime patterns such as:
  - ValueTracker with object updaters
  - always_redraw for lightweight redraw patterns
  - Surface.update_surface(...) for animated 3D heightfields
  - SurfaceMesh(surface, ...) when a visible wire overlay is desired
  - Code(...) with explicit language/style/background options
- Make timings intentional and keep the total duration close to what is requested.
- If you define a Scene/ThreeDScene/VoiceoverScene subclass, instantiate it at the bottom of the file and call construct(), for example:
  - scene = MyScene()
  - scene.construct()

Quality bar:
- No placeholder comments like "add more here".
- No prose outside the code block.
- Use explicit parameter names such as run_time=, lag_ratio=, font_size=.
- End with a stable final composition.

Create a scene that intentionally leans on updater patterns that must compile and bake cleanly.

Task:
- Use ValueTracker plus one or more object updaters that read tracker.get_value() directly.
- Prefer examples like:
  - a moving dot following a tracker
  - a number or label that updates from the same tracker
  - one secondary transform or emphasis animation after the tracker motion
- Do not fake the motion with manual frame stepping.
- Keep the logic clean enough that another agent could reuse it as a known-good updater template.
- Keep it 5 to 8 seconds and end in a stable final state.

You are generating code for Manim Web.

Current platform expectations:
- Only use these imports when needed:
  - from manim import *
  - import numpy as np
- If string interpolation is needed, use plain f-strings only: f"..."
- Do not use raw f-strings such as rf"..." or fr"..."
- Output only executable Python code inside one fenced ```python code block.
- Prefer deterministic, readable, production-safe scenes.
- Keep composition large and legible.
- Use the real Manim Web API surface, not imaginary APIs.
- Do not use any other imports.
- Do not use relative imports, workspace helper modules, or multi-file outputs.
- If helpful, define small helper functions/classes in the same file only.

Authoring guidance:
- Scenes can live as normal .py files in the workspace.
- If the file is meant to be rendered or published, put `#title:` and `#description:` header comments at the top of that file.
- `ImageMobject(...)` and `SVGMobject(...)` may use scene-relative paths such as "images/logo.png", explicit relative paths such as "./images/logo.png", or workspace-root paths such as "data/topic/main/images/logo.png".
- Prefer `image_id="..."` when the image comes from an uploaded scene asset managed by the editor or MCP tools.
- Keep paths relative and portable.
- Prefer smooth 2D motion unless the prompt explicitly asks for something else.
- Prefer supported runtime patterns such as:
  - ValueTracker with object updaters
  - always_redraw for lightweight redraw patterns
  - Surface.update_surface(...) for animated 3D heightfields
  - SurfaceMesh(surface, ...) when a visible wire overlay is desired
  - Code(...) with explicit language/style/background options
- Make timings intentional and keep the total duration close to what is requested.
- If you define a Scene/ThreeDScene/VoiceoverScene subclass, instantiate it at the bottom of the file and call construct(), for example:
  - scene = MyScene()
  - scene.construct()

Quality bar:
- No placeholder comments like "add more here".
- No prose outside the code block.
- Use explicit parameter names such as run_time=, lag_ratio=, font_size=.
- End with a stable final composition.

Create a scene that showcases code as a first-class visual object.

Requirements:
- Use one or two Code(...) blocks only.
- Pick a real configuration such as:
  - language="python"
  - language="c++"
  - style="dracula"
  - formatter_style="vscode-light"
  - background="window" or background="rectangle"
- Make the code block large and legible.
- Build the rest of the composition around the code block instead of mixing in unrelated widgets.
- Use simple motion like FadeIn, Transform, Circumscribe, or a clean side-by-side comparison.
- The scene should feel like a product-quality code explainer or launch visual.