Fixing a few things

README.md

@@ -243,6 +243,53 @@ gnommo -p myproject render --res low        # Fast preview at 490x270
 gnommo -p myproject render --res tiny       # Ultrafast preview at 320x180
 ```
 
+A partial `--slides S1:S10` render writes a range-suffixed file (e.g.
+`PHIL_COSM_102_S1_S10.mp4`) so sections don't overwrite each other or the full render.
+
+**Render log:** every render writes `<project>/<project>.log` (e.g. `video2.log`) with
+the platform/ffmpeg/memory header, the exact ffmpeg command, and a `[mem …]` memory
+sample every 3s. If a render crashes, check the tail of this log first.
+
+---
+
+### Render rig configuration (memory / performance)
+
+The compositing ffmpeg graph holds a lot at once (RGBA layer buffers, many inputs, the
+final mux), so peak RAM is high. Two knobs keep it bounded — both matter on a render rig.
+
+**1. FFmpeg thread cap — `~/.gnommo.conf`** (on the render machine)
+
+Fewer filter threads = far less peak memory (each parallel `format=rgba`/swscaler stage
+holds its own full-frame buffers). The render honours `[performance] cpu_limit`, a
+fraction of logical CPUs. **Unset defaults to 1 thread (safest).** On a memory-tight box
+keep it low:
+
+```ini
+[performance]
+cpu_limit = 0.25
+```
+
+> Note: the render uses `-filter_complex`, capped by `-filter_complex_threads` (not
+> `-filter_threads`, which only applies to simple `-vf` graphs). This is why an
+> uncapped render graph could OOM even when the preprocessor was fine.
+
+**2. WSL2 memory/swap — `C:\Users\<you>\.wslconfig`** (Windows host, for an Ubuntu-on-WSL rig)
+
+A WSL2 VM only gets a *slice* of host RAM (default ~50%, or 8 GB on older builds). If the
+render exceeds that slice, **Windows OOM-kills the whole VM** — it surfaces as
+`Wsl/Service/E_UNEXPECTED` / "Catastrophic failure", not a normal out-of-memory error, and
+the Windows host still shows plenty of RAM free. Raise the cap and give it swap headroom:
+
+```ini
+[wsl2]
+memory=24GB      # give the VM more of the host RAM
+swap=16GB        # headroom so it pages instead of dying catastrophically
+processors=8
+```
+
+Then, from PowerShell: `wsl --shutdown`, and restart the session. Confirm the VM's cap in
+the render log header — its `memory: … total` is the VM slice, not the host RAM.
+
 ---
 
 ## Shortcut: All Stages