chore: update docs

3 files changed, 240 insertions, 240 deletions

diff --git a/docs/README.md b/docs/README.md
index 57afb1a..3ab9570 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,27 +1,27 @@
-# Donut Documentation
+# donut documentation
 
-Deeper documentation for Donut, the real-time Schwarzschild black-hole renderer.
-The top-level [`README.md`](../README.md) is the overview; the two documents here
+deeper documentation for donut, the real-time schwarzschild black-hole renderer.
+the top-level [`README.md`](../README.md) is the overview; the two documents here
 go into how it actually works.
 
-- **[physics.md](physics.md)** — the physics and maths. Tracing light through
-  curved spacetime: the Schwarzschild metric, null geodesics and the equations of
+- **[physics.md](physics.md)** — the physics and maths. tracing light through
+  curved spacetime: the schwarzschild metric, null geodesics and the equations of
   motion, the numerical integrator and its adaptive step, the event horizon /
-  photon sphere / ISCO, the Novikov–Thorne accretion disk, gravitational and
-  Doppler redshift with relativistic beaming, and the observable quantities the
-  renderer can measure. Tied throughout to
+  photon sphere / isco, the novikov–thorne accretion disk, gravitational and
+  doppler redshift with relativistic beaming, and the observable quantities the
+  renderer can measure. tied throughout to
   [`assets/shaders/geodesic.slang`](../assets/shaders/geodesic.slang).
 
-- **[architecture.md](architecture.md)** — how the program is built. The code's
-  layering (Application / Scene / RenderPath / UILayer), the portable RHI that lets
-  the same rendering run on OpenGL and Vulkan, the frame loop, the unified
+- **[architecture.md](architecture.md)** — how the program is built. the code's
+  layering (application / scene / renderpath / uilayer), the portable rhi that lets
+  the same rendering run on opengl and vulkan, the frame loop, the unified
   scene-and-simulation world, the rendering pipeline (progressive resolution,
-  supersampling, environment lighting, tone-mapping), the docking UI, the export
+  supersampling, environment lighting, tone-mapping), the docking ui, the export
   pipeline, and the build system.
 
-For each pixel, Donut casts a ray from the camera and follows it backward through
-the curved spacetime around Sagittarius A\*. Rays that fall past the horizon are
+for each pixel, donut casts a ray from the camera and follows it backward through
+the curved spacetime around sagittarius a\*. rays that fall past the horizon are
 the shadow; rays that graze the photon sphere wind around it into the bright ring;
 rays that strike the hot orbiting disk pick up its shifted glow; rays that escape
-read the background sky. That trace is one GPU shader, fed by a small portable
+read the background sky. that trace is one gpu shader, fed by a small portable
 graphics layer so it runs identically on both backends.
diff --git a/docs/architecture.md b/docs/architecture.md
index c244586..0868775 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -1,27 +1,27 @@
-# The Architecture of Donut
+# the architecture of donut
 
-How Donut is put together as a program: how the code is layered, how the same
-rendering runs on two graphics APIs, how a frame is drawn, and how the editor, the
+how donut is put together as a program: how the code is layered, how the same
+rendering runs on two graphics apis, how a frame is drawn, and how the editor, the
 live simulation, and the data export fit together.
 
-For the physics behind the image itself, see [`physics.md`](physics.md).
+for the physics behind the image itself, see [`physics.md`](physics.md).
 
-## Contents
+## contents
 
-- [Overview](#overview)
-- [The RHI: one interface, two backends](#the-rhi-one-interface-two-backends)
-- [A frame, end to end](#a-frame-end-to-end)
-- [The two renderers](#the-two-renderers)
-- [Scene and Simulation: one world](#scene-and-simulation-one-world)
-- [The rendering pipeline](#the-rendering-pipeline)
-  - [Progressive resolution and supersampling](#progressive-resolution-and-supersampling)
-- [The workspace: tabs](#the-workspace-tabs)
-- [The export pipeline](#the-export-pipeline)
-- [The build system](#the-build-system)
+- [overview](#overview)
+- [the rhi: one interface, two backends](#the-rhi-one-interface-two-backends)
+- [a frame, end to end](#a-frame-end-to-end)
+- [the two renderers](#the-two-renderers)
+- [scene and simulation: one world](#scene-and-simulation-one-world)
+- [the rendering pipeline](#the-rendering-pipeline)
+  - [progressive resolution and supersampling](#progressive-resolution-and-supersampling)
+- [the workspace: tabs](#the-workspace-tabs)
+- [the export pipeline](#the-export-pipeline)
+- [the build system](#the-build-system)
 
-## Overview
+## overview
 
-Donut is split into a few pieces with distinct jobs, so the physics, the platform,
+donut is split into a few pieces with distinct jobs, so the physics, the platform,
 and the interface can change independently.
 
 ```mermaid
@@ -44,24 +44,24 @@ flowchart TD
     BHR -.reads.-> Scene
 ```
 
-| Component | File | Responsibility |
+| component | file | responsibility |
 | --- | --- | --- |
-| `Application` | [`src/core/application.cpp`](../src/core/application.cpp) | Owns everything; runs the main loop; handles input, resize, vsync, fullscreen; exposes actions to the UI |
-| `Scene` | [`src/scene/scene.h`](../src/scene/scene.h) | The world as plain data — placed objects, black-hole/disk parameters, the editor and simulation cameras, the HDRI path |
-| `UILayer` | [`src/ui/ui_layer.cpp`](../src/ui/ui_layer.cpp) | The docking shell: menu bar, dockable panels, default layouts; returns which view is live and drives the scene through `AppActions` |
-| `RenderPath` | [`src/rendering/render_path.cpp`](../src/rendering/render_path.cpp) | Turns the scene into pixels on whatever device is active; owns the two renderers and the environment cubemap |
-| `RHI::Device` | [`src/rendering/rhi.h`](../src/rendering/rhi.h) | The portable GPU interface every backend implements |
+| `Application` | [`src/core/application.cpp`](../src/core/application.cpp) | owns everything; runs the main loop; handles input, resize, vsync, fullscreen; exposes actions to the ui |
+| `Scene` | [`src/scene/scene.h`](../src/scene/scene.h) | the world as plain data — placed objects, black-hole/disk parameters, the editor and simulation cameras, the hdri path |
+| `UILayer` | [`src/ui/ui_layer.cpp`](../src/ui/ui_layer.cpp) | the docking shell: menu bar, dockable panels, default layouts; returns which view is live and drives the scene through `AppActions` |
+| `RenderPath` | [`src/rendering/render_path.cpp`](../src/rendering/render_path.cpp) | turns the scene into pixels on whatever device is active; owns the two renderers and the environment cubemap |
+| `RHI::Device` | [`src/rendering/rhi.h`](../src/rendering/rhi.h) | the portable gpu interface every backend implements |
 
-Two things carry most of the weight here. `Scene` is plain data with no knowledge
-of the backend or the UI, and everything that touches the GPU goes through one
-narrow interface (the RHI). The `Application` stays thin: it hands the document to
+two things carry most of the weight here. `Scene` is plain data with no knowledge
+of the backend or the ui, and everything that touches the gpu goes through one
+narrow interface (the rhi). the `Application` stays thin: it hands the document to
 `Scene`, the pixels to `RenderPath`, and the controls to `UILayer`.
 
-## The RHI: one interface, two backends
+## the rhi: one interface, two backends
 
-Donut runs on both OpenGL and Vulkan (through MoltenVK on macOS) from one codebase.
-All rendering is written once against an abstract Render Hardware Interface in the
-`Donut::RHI` namespace, and each API supplies an implementation.
+donut runs on both opengl and vulkan (through moltenvk on macos) from one codebase.
+all rendering is written once against an abstract render hardware interface in the
+`Donut::RHI` namespace, and each api supplies an implementation.
 
 ```mermaid
 flowchart LR
@@ -72,23 +72,23 @@ flowchart LR
     VK --> VKAPI[("Vulkan / MoltenVK")]
 ```
 
-The interface (in [`rhi.h`](../src/rendering/rhi.h)) is small and shaped for modern
-GPUs:
+the interface (in [`rhi.h`](../src/rendering/rhi.h)) is small and shaped for modern
+gpus:
 
 - `Device` is the factory and frame driver: `create_buffer`, `create_texture`,
   `create_cubemap_from_hdri`, `create_render_target`, `create_pipeline`;
-  `begin_frame` / `end_frame`; `set_vsync`, `resize`, `wait_idle`; the ImGui hooks;
+  `begin_frame` / `end_frame`; `set_vsync`, `resize`, `wait_idle`; the imgui hooks;
   and the export helpers `run_offscreen`, `read_render_target`,
   `read_render_target_float`.
 - `CommandList` records work: `begin_render_pass` / `end_render_pass` (a `nullptr`
   target means the swapchain), `bind_pipeline`, `set_viewport`, `bind_uniform`,
   `bind_texture`, `bind_vertex_buffer`, `draw`.
-- `Buffer`, `Texture`, `Pipeline` and `RenderTarget` are opaque GPU resources.
+- `Buffer`, `Texture`, `Pipeline` and `RenderTarget` are opaque gpu resources.
 - `Format` is `{ None, Swapchain, RGBA8, RGBA16F, RGBA32F, D32 }`. `Swapchain`
   means whatever the presented image is, resolved per backend; `RGBA32F` is what
   makes raw floating-point export possible.
 
-The backend is chosen once at startup, before the window exists, since the two APIs
+the backend is chosen once at startup, before the window exists, since the two apis
 want the window created differently:
 
 ```mermaid
@@ -106,14 +106,14 @@ sequenceDiagram
     A->>D: init(native window)
 ```
 
-Because the renderers only ever see the RHI, the same draw code gives
-pixel-identical output on both backends. That parity is checked by rendering to an
+because the renderers only ever see the rhi, the same draw code gives
+pixel-identical output on both backends. that parity is checked by rendering to an
 off-screen target and comparing the read-back pixels.
 
-## A frame, end to end
+## a frame, end to end
 
-The main loop is `Application::run`: poll events, render, then let vsync pace the
-frame or sleep to hit the target FPS. Each frame is assembled in
+the main loop is `Application::run`: poll events, render, then let vsync pace the
+frame or sleep to hit the target fps. each frame is assembled in
 `Application::render_frame`:
 
 ```mermaid
@@ -132,26 +132,26 @@ sequenceDiagram
     Dev->>Dev: end_frame — submit + present
 ```
 
-The `View` the UI returns — `None`, `Scene` or `BlackHole` — decides which
-viewport is live and therefore what `RenderPath` draws. The `moving` flag, true
+the `View` the ui returns — `None`, `Scene` or `BlackHole` — decides which
+viewport is live and therefore what `RenderPath` draws. the `moving` flag, true
 while the user is dragging or flying the camera, triggers the progressive-resolution
 path described below.
 
-## The two renderers
+## the two renderers
 
-`RenderPath` owns two independent renderers, both written purely against the RHI.
+`RenderPath` owns two independent renderers, both written purely against the rhi.
 
 `SceneRenderer` ([`scene_renderer.cpp`](../src/rendering/scene_renderer.cpp)) is the
 world editor: a conventional rasteriser that draws the placed spheres, the ground
 grid, the selection outline and gizmo, and a near-black black-hole marker at the
 origin, sized to the horizon and ringed with an amber accretion-glow outline so it
-reads against the dark background. This is what you manipulate in the Scene view.
+reads against the dark background. this is what you manipulate in the scene view.
 
 `BlackHoleRenderer` ([`black_hole_renderer.cpp`](../src/rendering/black_hole_renderer.cpp))
-is the geodesic ray tracer. It runs the physics shader from [`physics.md`](physics.md)
+is the geodesic ray tracer. it runs the physics shader from [`physics.md`](physics.md)
 as a full-screen fragment pass into an off-screen target, then presents that target
-to the screen. This is the expensive work, and it runs only when the centre view is
-Simulation, and during export.
+to the screen. this is the expensive work, and it runs only when the centre view is
+simulation, and during export.
 
 `RenderPath::render` routes to the right one based on the `View`:
 
@@ -163,104 +163,104 @@ flowchart TD
     R -->|BlackHole| GP["Off-screen geodesic pass →<br/>blit to swapchain + ImGui"]
 ```
 
-## Scene and Simulation: one world
+## scene and simulation: one world
 
-The editor and the simulation are the same world, not two separate scenes. The
+the editor and the simulation are the same world, not two separate scenes. the
 constant `SCENE_UNITS_PER_RS = 3.0` connects them: three editor grid units equal
-one Schwarzschild radius. `SceneRenderer` draws the black-hole marker's horizon at
+one schwarzschild radius. `SceneRenderer` draws the black-hole marker's horizon at
 that radius, and `BlackHoleRenderer` takes every placed `SceneObject`, multiplies
 its position and radius by $r_s/3$ (the code's `SagA_rs / 3`) to reach physical metres, and uploads
 them into the shader's `Objects` uniform (up to 16 spheres).
 
-So a sphere placed in the Scene view shows up in the same spot in the Simulation
+so a sphere placed in the scene view shows up in the same spot in the simulation
 view, except now the curved rays bend around the hole and lens it, and it can appear
-stretched, doubled, or smeared into an arc. The spheres are passive lit objects,
+stretched, doubled, or smeared into an arc. the spheres are passive lit objects,
 planets and the like; they don't exert their own gravity, only the black hole bends
 light.
 
-## The rendering pipeline
+## the rendering pipeline
 
-When the Simulation view is active, `BlackHoleRenderer::render_geodesic` does three
+when the simulation view is active, `BlackHoleRenderer::render_geodesic` does three
 things each frame:
 
-1. Fills the uniforms (`fill_uniforms`): the camera basis and FOV; the
+1. fills the uniforms (`fill_uniforms`): the camera basis and fov; the
    black-hole/disk parameters (radii converted to metres, temperature, brightness,
    turbulence); the integration budget (`quality_steps`, clamped 1000–15000); and
    the scene objects.
-2. Picks the off-screen target by the `moving` flag (below) and runs the geodesic
+2. picks the off-screen target by the `moving` flag (below) and runs the geodesic
    fragment shader over a full-screen quad into it.
-3. Blits that target to the swapchain (`blit`) with a present pipeline, flipping
-   vertically where needed so OpenGL and Vulkan agree on orientation, then draws the
-   ImGui overlay on top.
+3. blits that target to the swapchain (`blit`) with a present pipeline, flipping
+   vertically where needed so opengl and vulkan agree on orientation, then draws the
+   imgui overlay on top.
 
-Inside the shader, each pixel builds a ray from the camera basis, FOV and aspect,
+inside the shader, each pixel builds a ray from the camera basis, fov and aspect,
 marches the geodesic (see [physics](physics.md#the-equations-of-motion)), and shades
 from whatever it hit: the opaque disk's redshifted blackbody, the black shadow, a
-lit object, or the background. The background is the HDRI loaded as a cubemap
+lit object, or the background. the background is the hdri loaded as a cubemap
 (`create_cubemap_from_hdri`); escaped rays sample it at a mip level chosen from how
 fast neighbouring rays diverge (`ddx`/`ddy`), so the strongly lensed background
-blurs rather than aliasing into a shimmering fan. The colour channel is then
-tone-mapped with an ACES filmic curve.
+blurs rather than aliasing into a shimmering fan. the colour channel is then
+tone-mapped with an aces filmic curve.
 
-### Progressive resolution and supersampling
+### progressive resolution and supersampling
 
-Interactivity trades against quality through resolution and sample count, not by
+interactivity trades against quality through resolution and sample count, not by
 touching the physics:
 
-| State | Off-screen target | Samples per pixel |
+| state | off-screen target | samples per pixel |
 | --- | --- | --- |
-| Camera moving | `GEO_LO` = 480 × 270 | 1 |
-| Camera settled | `GEO_HI` = 960 × 540 | 4× rotated-grid supersampling |
+| camera moving | `GEO_LO` = 480 × 270 | 1 |
+| camera settled | `GEO_HI` = 960 × 540 | 4× rotated-grid supersampling |
 
-The integration budget is the same in both states, because the disk needs a high
+the integration budget is the same in both states, because the disk needs a high
 step count to resolve at steep poses and lowering it during motion makes it
-flicker. When the camera stops, the renderer switches to the larger target and the
+flicker. when the camera stops, the renderer switches to the larger target and the
 fragment shader averages four sub-pixel samples in a rotated-grid ("4-rook") pattern
 before tone-mapping, which cleans up the near-horizontal lensed edges and the thin
 photon ring.
 
-## The workspace: docking and panels
+## the workspace: docking and panels
 
-The interface is a docking shell. A main menu bar sits above a full-viewport dock
-space with a pass-through centre, so the live 3D render shows through the middle
+the interface is a docking shell. a main menu bar sits above a full-viewport dock
+space with a pass-through centre, so the live 3d render shows through the middle
 while dockable tool panels attach to the edges — drag, tab, hide, or restore them
-like a normal desktop app. The layout persists in `imgui.ini` between runs.
+like a normal desktop app. the layout persists in `imgui.ini` between runs.
 
-The panels are separate windows, each toggled from the **Window** menu:
+the panels are separate windows, each toggled from the **window** menu:
 
-| Panel | For |
+| panel | for |
 | --- | --- |
-| Outliner | The sphere list: add, delete, select |
-| Properties | The selected sphere's transform and colour, plus the viewport gizmo |
-| Black Hole | Camera mode/FOV, the accretion disk, and integration quality |
-| Settings | Display & renderer: vsync, frame cap, resolution, fullscreen, UI scale, API, overlay, HDRI |
-| Export | Choose which observable channels, at what resolution and format, then render to disk |
-| Stats | Device, backend, FPS and frame time |
+| outliner | the sphere list: add, delete, select |
+| properties | the selected sphere's transform and colour, plus the viewport gizmo |
+| black hole | camera mode/fov, the accretion disk, and integration quality |
+| settings | display & renderer: vsync, frame cap, resolution, fullscreen, ui scale, api, overlay, hdri |
+| export | choose which observable channels, at what resolution and format, then render to disk |
+| stats | device, backend, fps and frame time |
 
-Two menus drive the rest. **View** picks what the centre viewport shows — `Scene`
+two menus drive the rest. **view** picks what the centre viewport shows — `Scene`
 (the world editor) or `Simulation` (the lensed black hole) — which is the `View`
-`UILayer::draw` returns to the `RenderPath`. **Layout** applies one of the default
-arrangements, each built programmatically with ImGui's `DockBuilder` API and paired
+`UILayer::draw` returns to the `RenderPath`. **layout** applies one of the default
+arrangements, each built programmatically with imgui's `DockBuilder` api and paired
 with a sensible view and panel set:
 
-| Layout | View | Panels shown |
+| layout | view | panels shown |
 | --- | --- | --- |
-| Simulation (default) | `Simulation` | Black Hole, Stats |
-| Scene editing | `Scene` | Outliner, Properties, Stats |
-| Export | `Simulation` | Export, Black Hole, Stats |
+| simulation (default) | `Simulation` | black hole, stats |
+| scene editing | `Scene` | outliner, properties, stats |
+| export | `Simulation` | export, black hole, stats |
 
-On first launch (no saved `imgui.ini`) the Simulation layout is built by
-`DockBuilder`; after that the user's arrangement is restored, and *Layout → Reset*
-rebuilds the current preset. Only panels are docked windows — the centre stays a
-pass-through hole onto the full-frame 3D render, so `Application::update_input`
-drives the camera whenever the cursor is over that centre (ImGui reports it doesn't
+on first launch (no saved `imgui.ini`) the simulation layout is built by
+`DockBuilder`; after that the user's arrangement is restored, and *layout → reset*
+rebuilds the current preset. only panels are docked windows — the centre stays a
+pass-through hole onto the full-frame 3d render, so `Application::update_input`
+drives the camera whenever the cursor is over that centre (imgui reports it doesn't
 want the mouse) and yields to the panels otherwise.
 
-## The export pipeline
+## the export pipeline
 
-Export writes out the physical quantities Donut computes, not just a screenshot. It
+export writes out the physical quantities donut computes, not just a screenshot. it
 is driven by `RenderPath::export_frame`
-([`render_path.cpp`](../src/rendering/render_path.cpp)) and the RHI's off-screen
+([`render_path.cpp`](../src/rendering/render_path.cpp)) and the rhi's off-screen
 helpers.
 
 ```mermaid
@@ -275,48 +275,48 @@ flowchart LR
     WR --> Files["exports/donut_[channel]_[timestamp].[ext]"]
 ```
 
-A few points worth knowing:
+a few points worth knowing:
 
-- The export always renders the settled view (`moving = false`) from the simulation
+- the export always renders the settled view (`moving = false`) from the simulation
   camera, at the requested resolution, whatever the live window is doing.
-- Any combination of colour, redshift $g$, emission temperature and impact parameter
+- any combination of colour, redshift $g$, emission temperature and impact parameter
   (the observables from [physics](physics.md#observable-channels)) can be exported in
   one pass.
-- PNG requests use an `RGBA8` target and the standard shader pipeline
-  (`m_geo_pipeline`), giving a viewable tone-mapped or false-coloured image. PFM and
-  CSV requests use an `RGBA32F` target and an HDR pipeline variant
+- png requests use an `RGBA8` target and the standard shader pipeline
+  (`m_geo_pipeline`), giving a viewable tone-mapped or false-coloured image. pfm and
+  csv requests use an `RGBA32F` target and an hdr pipeline variant
   (`m_geo_pipeline_hdr`), so the file holds the actual floating-point values: $g$ as
-  a ratio, temperature in Kelvin, impact parameter in $r_s$, colour as linear HDR
-  radiance. For the disk-only channels, the alpha channel carries a validity mask (1
+  a ratio, temperature in kelvin, impact parameter in $r_s$, colour as linear hdr
+  radiance. for the disk-only channels, the alpha channel carries a validity mask (1
   where a ray hit the disk, 0 elsewhere).
-- Formats are PNG via `stb_image_write`, PFM (Portable Float Map — raw RGB float,
-  the usual choice for HDR data) via a small writer, and CSV for the scalar channels,
+- formats are png via `stb_image_write`, pfm (portable float map — raw rgb float,
+  the usual choice for hdr data) via a small writer, and csv for the scalar channels,
   one grid value per cell.
 - `run_offscreen` records a transient command buffer, submits it and waits, with no
-  swapchain and no frame pacing. The target is then read back on the CPU and written
+  swapchain and no frame pacing. the target is then read back on the cpu and written
   to a timestamped file under `exports/`.
 
-## The build system
+## the build system
 
-Donut uses premake5 to generate GNU Makefiles. Both backends compile into one
+donut uses premake5 to generate gnu makefiles. both backends compile into one
 binary; the choice between them is made at runtime from the saved settings, so
-there is no separate "OpenGL build" and "Vulkan build".
+there is no separate "opengl build" and "vulkan build".
 
-Generate and build (arm64 macOS):
+generate and build (arm64 macos):
 
 ```bash
 premake5 gmake && make config=debug
 ```
 
 `premake5 clean` is wired up as a custom action that removes the generated build
-output (`bin/`, `bin-int/`, the Makefiles) along with the transient runtime files
+output (`bin/`, `bin-int/`, the makefiles) along with the transient runtime files
 (`logs/`, `config/`, `imgui.ini`), for a genuine from-scratch reset.
 
-Vendored third-party code lives under `ext/`. The portable renderers and the RHI
+vendored third-party code lives under `ext/`. the portable renderers and the rhi
 are under `src/rendering/`, with the two backends under `src/platform/opengl/` and
 `src/platform/vulkan/`.
 
 ---
 
-See [`physics.md`](physics.md) for the maths behind the image, and the top-level
+see [`physics.md`](physics.md) for the maths behind the image, and the top-level
 [`README.md`](../README.md) for a project overview.
diff --git a/docs/physics.md b/docs/physics.md
index 98807e1..d4599a8 100644
--- a/docs/physics.md
+++ b/docs/physics.md
@@ -1,37 +1,37 @@
-# The Physics of Donut
+# the physics of donut
 
-Everything Donut draws comes from tracing light backward through the curved
-spacetime around a black hole. This document works through the physics and maths
+everything donut draws comes from tracing light backward through the curved
+spacetime around a black hole. this document works through the physics and maths
 of that trace, in roughly the order the shader applies it, with references to the
 code in [`assets/shaders/geodesic.slang`](../assets/shaders/geodesic.slang) —
 symbol names below (`InitRay`, `GeodesicRHS`, `DiskEmission`) all live in that file.
 
-For the software side — how the shader gets fed, the render backends, the docking
-UI and the export path — see [`architecture.md`](architecture.md).
+for the software side — how the shader gets fed, the render backends, the docking
+ui and the export path — see [`architecture.md`](architecture.md).
 
-## Contents
+## contents
 
-- [Overview](#overview)
-- [Units and scale](#units-and-scale)
-- [The Schwarzschild metric](#the-schwarzschild-metric)
-- [Null geodesics and conserved quantities](#null-geodesics-and-conserved-quantities)
-- [The equations of motion](#the-equations-of-motion)
-- [Numerical integration](#numerical-integration)
-- [The three critical radii](#the-three-critical-radii)
-- [The accretion disk](#the-accretion-disk)
-- [Redshift, Doppler beaming and colour](#redshift-doppler-beaming-and-colour)
-- [The impact parameter](#the-impact-parameter)
-- [Observable channels](#observable-channels)
+- [overview](#overview)
+- [units and scale](#units-and-scale)
+- [the schwarzschild metric](#the-schwarzschild-metric)
+- [null geodesics and conserved quantities](#null-geodesics-and-conserved-quantities)
+- [the equations of motion](#the-equations-of-motion)
+- [numerical integration](#numerical-integration)
+- [the three critical radii](#the-three-critical-radii)
+- [the accretion disk](#the-accretion-disk)
+- [redshift, doppler beaming and colour](#redshift-doppler-beaming-and-colour)
+- [the impact parameter](#the-impact-parameter)
+- [observable channels](#observable-channels)
 
-## Overview
+## overview
 
-A black hole isn't drawn like ordinary geometry. For each pixel Donut casts a ray
+a black hole isn't drawn like ordinary geometry. for each pixel donut casts a ray
 from the camera and follows it *backward* until one of four things happens: it
 crosses the event horizon, it strikes the accretion disk, it hits a placed object,
-or it escapes to the background sky. Mass bends the path of light, so the rays
+or it escapes to the background sky. mass bends the path of light, so the rays
 curve, and that one effect produces the whole picture: the dark shadow, the bright
 ring wrapped around it, the far side of the disk folded up over the top of the
-hole, and the Doppler-brightened leading edge.
+hole, and the doppler-brightened leading edge.
 
 ```mermaid
 flowchart LR
@@ -47,22 +47,22 @@ flowchart LR
     G --> H
 ```
 
-## Units and scale
+## units and scale
 
-Donut works in geometric units, $G = c = 1$. Mass then carries units of length,
-and the Schwarzschild radius reduces to
+donut works in geometric units, $G = c = 1$. mass then carries units of length,
+and the schwarzschild radius reduces to
 
 $$
 r_s = \frac{2GM}{c^2} = 2M, \qquad\text{so}\qquad M = \frac{r_s}{2}.
 $$
 
-One number describes the hole. For Sagittarius A* the shader fixes it as
+one number describes the hole. for sagittarius a* the shader fixes it as
 
 ```
 static const float SagA_rs = 1.269e10;   // metres  (M ≈ 4.3×10⁶ M☉)
 ```
 
-Every distance the integrator handles is a physical length in metres, written as a
+every distance the integrator handles is a physical length in metres, written as a
 multiple of `SagA_rs`, so the critical radii come out as constants:
 
 ```
@@ -70,16 +70,16 @@ R_PHOTON = 1.5 * SagA_rs   // photon sphere  (3M)
 R_ISCO   = 3.0 * SagA_rs   // ISCO           (6M)
 ```
 
-The scene editor uses a friendlier grid. The constant `SCENE_UNITS_PER_RS = 3.0`
+the scene editor uses a friendlier grid. the constant `SCENE_UNITS_PER_RS = 3.0`
 (in [`src/scene/scene_types.h`](../src/scene/scene_types.h)) sets three grid units
-to one Schwarzschild radius. When the renderer hands a placed object to the shader
+to one schwarzschild radius. when the renderer hands a placed object to the shader
 it scales the position by $r_s/3$ (the code's `SagA_rs / 3`) to get metres, so the editor and the
 simulation always agree on where things sit.
 
-## The Schwarzschild metric
+## the schwarzschild metric
 
-Sgr A* is treated as a non-rotating, uncharged black hole, whose spacetime is the
-exact Schwarzschild solution of Einstein's equations. In spherical coordinates
+sgr a* is treated as a non-rotating, uncharged black hole, whose spacetime is the
+exact schwarzschild solution of einstein's equations. in spherical coordinates
 $(t, r, \theta, \phi)$ the line element is
 
 $$
@@ -88,18 +88,18 @@ ds^2 = -\left(1-\frac{r_s}{r}\right)dt^2
       + r^2\left(d\theta^2 + \sin^2\theta\, d\phi^2\right).
 $$
 
-The factor that keeps recurring is abbreviated
+the factor that keeps recurring is abbreviated
 
 $$f(r) = 1 - \frac{r_s}{r},$$
 
-which is `float f = 1.0 - SagA_rs / r;` in the code. As $r \to r_s$, $f \to 0$ and
-the metric coefficients diverge. That divergence is a coordinate artifact rather
+which is `float f = 1.0 - SagA_rs / r;` in the code. as $r \to r_s$, $f \to 0$ and
+the metric coefficients diverge. that divergence is a coordinate artifact rather
 than a real singularity, but it is why the integrator stops a ray once it reaches
 $r \le r_s$ instead of pushing through.
 
-## Null geodesics and conserved quantities
+## null geodesics and conserved quantities
 
-Light follows null geodesics, the curves with $ds^2 = 0$. The metric has no
+light follows null geodesics, the curves with $ds^2 = 0$. the metric has no
 explicit dependence on $t$ or $\phi$ (a time-translation symmetry and an axial
 rotation symmetry), so two quantities stay constant along every ray:
 
@@ -126,16 +126,16 @@ own — one fewer equation per step. `L` is computed at initialisation as the ra
 angular momentum but isn't fed back into the equations of motion; the azimuthal
 motion is carried directly by $\dot\phi$.
 
-For a null geodesic the affine parameter has an arbitrary overall scale, and the
+for a null geodesic the affine parameter has an arbitrary overall scale, and the
 ray's shape — which is all the image depends on — doesn't change with it, so the
 exact normalisation of `E` is only a convention.
 
-## The equations of motion
+## the equations of motion
 
-Marching a ray means solving the geodesic equation
+marching a ray means solving the geodesic equation
 $\ddot x^\mu + \Gamma^\mu_{\alpha\beta}\dot x^\alpha \dot x^\beta = 0$ for the
-Schwarzschild metric. `GeodesicRHS` writes it as a first-order system in the six
-ray variables $(r,\theta,\phi,\dot r,\dot\theta,\dot\phi)$. The three positions
+schwarzschild metric. `GeodesicRHS` writes it as a first-order system in the six
+ray variables $(r,\theta,\phi,\dot r,\dot\theta,\dot\phi)$. the three positions
 advance by their velocities,
 
 $$\dot r,\qquad \dot\theta,\qquad \dot\phi,$$
@@ -159,11 +159,11 @@ $$
           - 2\cot\theta\,\dot\theta\,\dot\phi.
 $$
 
-The terms are the Christoffel symbols of the metric. In $\ddot r$ the first term
+the terms are the christoffel symbols of the metric. in $\ddot r$ the first term
 is the inward pull of gravity (it carries $\dot t^2$, hence the energy); the rest
-are the centrifugal contributions from angular motion. The $\theta$ and $\phi$
+are the centrifugal contributions from angular motion. the $\theta$ and $\phi$
 equations are the angular-momentum couplings that hold the ray to its orbital
-plane and sweep it around the hole. The code is a direct transcription:
+plane and sweep it around the hole. the code is a direct transcription:
 
 ```
 d2.x = -(SagA_rs/(2r²))·f·dt_dL²  +  (SagA_rs/(2r²f))·dr²  +  r·(dtheta² + sin²θ·dphi²);
@@ -171,19 +171,19 @@ d2.y = -2·dr·dtheta/r  +  sin(theta)·cos(theta)·dphi²;
 d2.z = -2·dr·dphi/r    -  2·(cos/sin)(theta)·dtheta·dphi;
 ```
 
-## Numerical integration
+## numerical integration
 
-There is no closed form for a general ray, so the integrator advances it in steps.
+there is no closed form for a general ray, so the integrator advances it in steps.
 
-`RK4Step` takes one step. It evaluates `GeodesicRHS` once, advances the six
-variables by `dL` times their rates, and recomputes the Cartesian position from
-the new spherical coordinates. That is a single forward-Euler stage, despite the
+`RK4Step` takes one step. it evaluates `GeodesicRHS` once, advances the six
+variables by `dL` times their rates, and recomputes the cartesian position from
+the new spherical coordinates. that is a single forward-euler stage, despite the
 name: only the first slope `k1` is evaluated, where a genuine fourth-order step
-would also compute `k2`, `k3` and `k4` at intermediate points. Moving to real RK4
+would also compute `k2`, `k3` and `k4` at intermediate points. moving to real rk4
 is the obvious accuracy upgrade; as it stands, almost all of the accuracy comes
 from the step-size control instead.
 
-`CalculateAdaptiveStepSize` chooses the step length. A fixed step would waste time
+`CalculateAdaptiveStepSize` chooses the step length. a fixed step would waste time
 far from the hole and lose the trajectory near it, so the step scales with distance
 from the photon sphere:
 
@@ -192,34 +192,34 @@ $$
 $$
 
 with $\Delta_\text{min} = 10^6$ and $\Delta_\text{max} = 2\times10^{10}$ metres.
-Far out, the ray is in near-flat space and crosses it in a handful of long
-strides. Near the photon sphere, where the path bends hardest and mistakes show
-the most, the step shrinks to follow the curve. A second clamp forces the step
+far out, the ray is in near-flat space and crosses it in a handful of long
+strides. near the photon sphere, where the path bends hardest and mistakes show
+the most, the step shrinks to follow the curve. a second clamp forces the step
 down to the disk's half-thickness whenever the ray is near the disk plane, so a
 thin, nearly edge-on disk is never stepped straight over.
 
-A ray's march ends on the first of these:
+a ray's march ends on the first of these:
 
-| Condition | Meaning |
+| condition | meaning |
 | --- | --- |
-| $r \le r_s$ (`Intercept`) | Fell through the horizon → shadow (black) |
-| Crossed / entered the disk slab | Hit the opaque disk → emit its colour |
-| `InterceptObject` (every 5 steps) | Hit a placed sphere → shade it |
-| $r > $ `earlyExitDistance` ($2\times10^{12}$) | Left the rendered region → sample the sky |
-| $\dot r > 0$ and $r > 50\,r_s$ | Outbound in flat space, direction frozen → sample the sky early |
-| step count exceeds the budget | Up to `quality_steps` (default 15000, clamped 1000–15000) |
+| $r \le r_s$ (`Intercept`) | fell through the horizon → shadow (black) |
+| crossed / entered the disk slab | hit the opaque disk → emit its colour |
+| `InterceptObject` (every 5 steps) | hit a placed sphere → shade it |
+| $r > $ `earlyExitDistance` ($2\times10^{12}$) | left the rendered region → sample the sky |
+| $\dot r > 0$ and $r > 50\,r_s$ | outbound in flat space, direction frozen → sample the sky early |
+| step count exceeds the budget | up to `quality_steps` (default 15000, clamped 1000–15000) |
 
-The step budget is the same whether the camera is moving or settled. At steep,
+the step budget is the same whether the camera is moving or settled. at steep,
 strongly-lensed poses the disk only resolves with a high step count, so cutting it
-during motion would make the disk flicker. Responsiveness during a drag comes from
+during motion would make the disk flicker. responsiveness during a drag comes from
 the rendering resolution and sample count instead — a smaller target and one sample
 per pixel while moving, sharpening to full resolution and 4× supersampling once the
 camera settles (see
 [`architecture.md`](architecture.md#progressive-resolution-and-supersampling)).
 
-## The three critical radii
+## the three critical radii
 
-Three radii set up everything you see:
+three radii set up everything you see:
 
 ```mermaid
 flowchart LR
@@ -229,39 +229,39 @@ flowchart LR
     end
 ```
 
-The **event horizon** at $r_s = 2M$ is the point of no return; the set of
-directions whose rays end there is the black shadow. The **photon sphere** at
+the **event horizon** at $r_s = 2M$ is the point of no return; the set of
+directions whose rays end there is the black shadow. the **photon sphere** at
 $\tfrac{3}{2}r_s = 3M$ is where light can circle the hole on unstable orbits, so
 rays passing near it loop around once or more before escaping — this makes the thin
-photon ring against the shadow and the folded multiple images of the disk. The
-**ISCO** at $3r_s = 6M$ is the innermost stable circular orbit, inside which matter
+photon ring against the shadow and the folded multiple images of the disk. the
+**isco** at $3r_s = 6M$ is the innermost stable circular orbit, inside which matter
 can't hold a steady orbit; it is the disk's inner edge, and `DiskEmission` clamps
 the inner radius with `max(disk.disk_r1, R_ISCO)`.
 
-## The accretion disk
+## the accretion disk
 
-Donut models the disk as a thin, opaque, self-luminous slab in the equatorial
-plane ($y = 0$), not a volumetric cloud. A ray hits it the first time it crosses
+donut models the disk as a thin, opaque, self-luminous slab in the equatorial
+plane ($y = 0$), not a volumetric cloud. a ray hits it the first time it crosses
 the midplane (or grazes into the slab of half-thickness `disk.thickness`) inside
 the radial band $[r_\text{in}, r_\text{out}]$, and that surface's emission is the
-pixel colour. The default band runs from $3\,r_s$ to $12\,r_s$.
+pixel colour. the default band runs from $3\,r_s$ to $12\,r_s$.
 
-A steady thin accretion disk radiates with a flux that rises from zero at the
+a steady thin accretion disk radiates with a flux that rises from zero at the
 inner edge, peaks just outside it, and tails off with radius:
 
 $$
 F(r) \;\propto\; \frac{1}{r^3}\left(1 - \sqrt{\frac{r_\text{in}}{r}}\right).
 $$
 
-This is the Novikov–Thorne / Shakura–Sunyaev thin-disk profile. Its peak sits at
+this is the novikov–thorne / shakura–sunyaev thin-disk profile. its peak sits at
 $r/r_\text{in} \approx 1.36$ with value `FLUX_PEAK = 0.0569`, which normalises it.
-A blackbody's flux goes as $T^4$ (Stefan–Boltzmann), so the local temperature is
+a blackbody's flux goes as $T^4$ (stefan–boltzmann), so the local temperature is
 
 $$
 T(r) = T_\text{peak}\left(\frac{F(r)}{F_\text{peak}}\right)^{1/4},
 $$
 
-where $T_\text{peak}$ is the tunable `disk.temperature`, 4800 K by default:
+where $T_\text{peak}$ is the tunable `disk.temperature`, 4800 k by default:
 
 ```
 flux  = max((1 - sqrt(1/xr)) / (xr*xr*xr), 0);   xr = rc / r_in
@@ -269,26 +269,26 @@ Tn    = pow(flux / FLUX_PEAK, 0.25);             // normalised temperature, peak
 Temit = disk.temperature * Tn;
 ```
 
-An optional turbulence overlay (the `turbulence` parameter, `disk.disk_num`)
-modulates the brightness with animated fractal noise to suggest churning gas. It
+an optional turbulence overlay (the `turbulence` parameter, `disk.disk_num`)
+modulates the brightness with animated fractal noise to suggest churning gas. it
 never changes the fact that the disk is an opaque surface.
 
-## Redshift, Doppler beaming and colour
+## redshift, doppler beaming and colour
 
-The disk is hot gas on relativistic orbits, deep in the gravity well. Two effects
+the disk is hot gas on relativistic orbits, deep in the gravity well. two effects
 shift its light on the way to the camera, and both collapse into a single redshift
 factor $g$ (observed frequency over emitted).
 
-The gas moves on prograde circular geodesics. For Schwarzschild, the locally
+the gas moves on prograde circular geodesics. for schwarzschild, the locally
 measured orbital speed is
 
 $$
 v = \sqrt{\frac{M}{r - 2M}} = \sqrt{\frac{r_s/2}{r - r_s}},
 $$
 
-which is exactly $0.5\,c$ at the ISCO. The velocity vector is
-$\boldsymbol\beta = v\,\hat\phi$, tangent to the orbit. Combining the gravitational
-and time-dilation shift of a circular orbit with the relativistic Doppler shift
+which is exactly $0.5\,c$ at the isco. the velocity vector is
+$\boldsymbol\beta = v\,\hat\phi$, tangent to the orbit. combining the gravitational
+and time-dilation shift of a circular orbit with the relativistic doppler shift
 from that motion gives
 
 $$
@@ -296,13 +296,13 @@ g = \frac{\sqrt{\,1 - \tfrac{3}{2}\,\dfrac{r_s}{r_c}\,}}{1 - \boldsymbol\beta\cd
 $$
 
 where $\hat n$ points along the photon toward the observer and $r_c$ is the
-cylindrical radius of the emission point. The numerator is the gravitational part
+cylindrical radius of the emission point. the numerator is the gravitational part
 (it vanishes at the photon sphere $r_c = \tfrac{3}{2}r_s$, where even orbiting
-light is infinitely redshifted); the denominator is the Doppler part, which
+light is infinitely redshifted); the denominator is the doppler part, which
 brightens and blueshifts the side turning toward the camera and dims and redshifts
-the receding side. As a check, $g \to \sqrt{1/2}$ at the ISCO, matching the code.
+the receding side. as a check, $g \to \sqrt{1/2}$ at the isco, matching the code.
 
-Two things follow from $g$, both physical:
+two things follow from $g$, both physical:
 
 $$
 T_\text{obs} = g\,T_\text{emit}
@@ -312,8 +312,8 @@ I_\text{obs} = g^4\,I_\text{emit}
 \qquad\text{(relativistic beaming)}.
 $$
 
-The colour is the Planckian blackbody colour at the observed temperature,
-`Blackbody(g · Temit)`, using a Tanner-Helland fit to the Planckian locus. The
+the colour is the planckian blackbody colour at the observed temperature,
+`Blackbody(g · Temit)`, using a tanner-helland fit to the planckian locus. the
 brightness keeps the physical $g^4$ beaming — the real approaching/receding
 asymmetry — while the enormous $T^4$ radial range is compressed to $T_n^2$ for
 display, so the colour gradient across the disk stays visible instead of collapsing
@@ -324,15 +324,15 @@ bright = pow(Tn, 2.0) * pow(g, 4.0) * edge;   // edge = soft inner/outer falloff
 colour = Blackbody(g * Temit) * bright;
 ```
 
-That $T_n^2$ in place of the physical $T_n^4 = F$ is the one intentional
+that $T_n^2$ in place of the physical $T_n^4 = F$ is the one intentional
 concession to legibility; the rest of the disk model is the genuine relativistic
 result.
 
-## The impact parameter
+## the impact parameter
 
-A ray's impact parameter $b$ is the perpendicular distance from the hole's centre
+a ray's impact parameter $b$ is the perpendicular distance from the hole's centre
 to the straight line the ray would have followed with no gravity — the quantity
-that sets how strongly it deflects. Donut reads it straight off the camera geometry
+that sets how strongly it deflects. donut reads it straight off the camera geometry
 (in units of $r_s$):
 
 $$
@@ -340,30 +340,30 @@ b = \frac{\lVert \mathbf{r}_\text{cam} \times \hat d\,\rVert}{r_s},
 $$
 
 with $\mathbf{r}_\text{cam}$ the camera position relative to the hole and $\hat d$
-the pixel's ray direction. Rays whose $b$ is near the critical value (about
+the pixel's ray direction. rays whose $b$ is near the critical value (about
 $\tfrac{3\sqrt3}{2}r_s$) are the ones that skim the photon sphere and build the
 ring.
 
-## Observable channels
+## observable channels
 
-The renderer already computes these physical quantities while tracing, so it can
-output them directly instead of only the final colour. The shader's `outputChannel`
+the renderer already computes these physical quantities while tracing, so it can
+output them directly instead of only the final colour. the shader's `outputChannel`
 picks which quantity each pixel reports, and `rawOutput` picks whether to write the
 raw floating-point value (for analysis) or a false-coloured / tone-mapped version
 (for viewing):
 
-| Channel | Quantity | Notes |
+| channel | quantity | notes |
 | --- | --- | --- |
-| 0 | Colour | The final tone-mapped HDR radiance — the normal image |
-| 1 | Redshift $g$ | Disk pixels only; validity flagged in alpha |
-| 2 | Emission temperature $T_\text{emit}$ (K) | Disk pixels only; validity in alpha |
-| 3 | Impact parameter $b$ ($r_s$) | A per-ray geometric quantity, defined everywhere |
+| 0 | colour | the final tone-mapped hdr radiance — the normal image |
+| 1 | redshift $g$ | disk pixels only; validity flagged in alpha |
+| 2 | emission temperature $T_\text{emit}$ (k) | disk pixels only; validity in alpha |
+| 3 | impact parameter $b$ ($r_s$) | a per-ray geometric quantity, defined everywhere |
 
-The raw channels are what make the export usable as data rather than just imagery;
+the raw channels are what make the export usable as data rather than just imagery;
 [`architecture.md`](architecture.md#the-export-pipeline) covers how they are
-rendered off-screen and written to PFM or CSV.
+rendered off-screen and written to pfm or csv.
 
 ---
 
-See also [`architecture.md`](architecture.md) for how the renderer is built, from
-the portable GPU layer up through the panels and the export pipeline.
+see also [`architecture.md`](architecture.md) for how the renderer is built, from
+the portable gpu layer up through the panels and the export pipeline.