demo: multi-goal capture script + clearer VolRover run docs + genericize downstream refs

README.md

@@ -142,20 +142,26 @@ Drive demos in `examples/`:
   for adversarial start/goal pairs).
 - **`volrover_grl_snam_planner.py`** — the surrogate's native sparse-obstacle regime.
 
-Capture a drive to video **offscreen** (no window): `scripts/capture_drive_video.py`.
-
-### 5. DBG variant — the full gym (`grl_snam_dbg`)
-The dataset-specific extension lives in the separate **`grl_snam_dbg`** project
-(it depends on GRL-SNAM, not the other way round). Its `grl_snam_dbg_demo.py`
-runs the **full communication-resilient navigation gym** end-to-end (~2 min,
-seeded): radio/material/jammer physics → episode generation → the 7-head
-coefficient network forward pass → differentiable surrogate rollout → phased
-GPU/CPU training → evaluation metrics → online adaptation. **Expected to see** a
-staged console report of what each phase produced (loss curves, metrics, a
-trained model), and — once the DBG→lab adapter lands — the `austin_south` terrain
-with 28 agents moving along their `movement_bundle.v1` tracks and a live
-path-loss field volume rendered in volrover3. That adapter + demo are the DBG
-project's deliverable, keeping DBG-specific code out of this general library.
+**Capture a drive to video — offscreen, no window** (the same way the demo films are
+made: a scripted chase camera through VTK — the VolRover3 engine — not a screen grab):
+```bash
+# one fixed A→B run
+python scripts/capture_drive_video.py <bundle> checkpoints/coef_sdf.pt \
+    --start -361 114 --goal 185 50 -o drive.mp4
+# the DYNAMIC multi-goal free-drive: goals re-targeted live, drone chase cam, ~3 min
+python scripts/capture_multigoal_video.py <bundle> checkpoints/coef_sdf.pt \
+    --sdf <bundle>/nav_sdf.npz --minutes 3 -o multigoal.mp4
+```
+Both run headless (offscreen GL is fine) and only need the volrover env + a trained
+checkpoint + a scene bundle + ffmpeg — no display, no live app window.
+
+### 5. Dataset-specific extensions
+Applied, dataset-specific work lives in **separate downstream projects** that depend on
+GRL-SNAM (not the other way round) and keep their dataset-specific code and models out
+of this general library. Such an extension reuses exactly the pieces shown above — the
+differentiable surrogate, the coefficient network, and the `pycvc`/`pycvc_gl` scene
+bindings — and versions its own additions in its own repository. This library stays
+general; the extensions stay separate and private.
 
 ## Repository Structure
 

examples/lab_demo.py

@@ -1,8 +1,8 @@
 """Demo: build a synthetic GRL-SNAM scene in the lab and show / snapshot it.
 
 General GRL-SNAM only — a wavy terrain, a couple of obstacle meshes, two
-agent trajectories, agent markers, and a risk field. A DBG adapter would
-instead feed a real movement_bundle.v1 through the same Lab API.
+agent trajectories, agent markers, and a risk field. A downstream adapter
+would instead feed its own real track data through the same Lab API.
 
 Run (with pycvc / pycvc_gl on PYTHONPATH and a display):
     python examples/lab_demo.py           # interactive window

examples/volrover_grl_snam_planner.py

@@ -5,7 +5,7 @@
 #
 # The path is produced by iterating grl_snam's differentiable surrogate rollout
 # (dynamics.integrate_surrogate_v2) one step at a time — the same physics-informed
-# integrator the DBG gym trains through (semi-implicit Euler + IPC obstacle
+# integrator downstream training runs through (semi-implicit Euler + IPC obstacle
 # barrier). Control coefficients here are hand-set to a known-good regime; with a
 # trained CoefEnergyNet checkpoint you'd predict them per step and refine online
 # with grl_snam.adaptation.HistSecantController (the "continuous learning" loop) —

grl_snam/selftest.py

@@ -13,8 +13,8 @@
   4. SHAPES: (o, v, min_clear) come back as (B,2), (B,2), (B,).
 
 This is the correctness counterpart to the visual grl_snam_lab demo. It needs
-torch (a declared GRL-SNAM dependency); the DBG *full-gym* end-to-end demo lives
-in the grl_snam_dbg project.
+torch (a declared GRL-SNAM dependency); the applied full-gym end-to-end demo lives
+in a separate, private downstream project.
 
 Run: ``grl-snam-selftest`` (installed console script) or ``python -m grl_snam.selftest``.
 """

grl_snam_lab/README.md

@@ -3,7 +3,7 @@
 A domain-general 3D lab for GRL-SNAM built on the CVC graphics stack
 (`pycvc` + `pycvc_gl`, the Python bindings for libcvc / cvcGL). It speaks
 general GRL-SNAM vocabulary — **terrain, obstacles, agent paths, agents,
-scalar fields (risk / SDF / path-loss)** — and turns each into a live 3D
+scalar fields (e.g. risk / SDF)** — and turns each into a live 3D
 scene node. It has **no** mission- or dataset-specific knowledge.
 
 ```python
@@ -17,12 +17,12 @@ lab.show()                 # interactive window (needs a display)
 # lab.render_png("s.png")  # offscreen snapshot
 ```
 
-## Adapting for DBG (and other datasets)
+## Adapting for a dataset
 
-Keep dataset-specific code **in the downstream project**. A DBG adapter reads
-a `movement_bundle.v1` and drives the same general API — e.g. one `add_path`
-per soldier track, `add_field` for a path-loss raster, `add_mesh` for the
-scene's buildings. The lab stays general; the mapping lives with the data.
+Keep dataset-specific code **in the downstream project**. An adapter reads that
+project's own track format and drives the same general API — e.g. one `add_path`
+per agent track, `add_field` for a scalar raster, `add_mesh` for the scene's
+buildings. The lab stays general; the mapping lives with the data.
 
 ## Requirements
 

grl_snam_lab/__init__.py

@@ -3,12 +3,12 @@
 A thin, **domain-general** layer over the CVC graphics stack (``pycvc`` +
 ``pycvc_gl``, the SWIG bindings for libcvc / cvcGL). It speaks the vocabulary
 of GRL-SNAM — *terrain*, *obstacles*, *agent paths*, *agents*, and *scalar
-fields* (risk / SDF / path-loss) — and turns each into a live 3D scene node.
+fields* (e.g. risk / SDF) — and turns each into a live 3D scene node.
 It knows nothing about any specific mission or dataset.
 
 Downstream projects adapt it by feeding their own data through this API — e.g.
-a DBG loader reads a ``movement_bundle.v1`` and calls :meth:`Lab.add_path`
-once per soldier track. Keep dataset-specific code in the downstream project;
+an adapter reads that project's own track format and calls :meth:`Lab.add_path`
+once per agent track. Keep dataset-specific code in the downstream project;
 keep this package general.
 
 The graphics backend (``pycvc``/``pycvc_gl``) is imported lazily so the module