# Blender sources

Editable `.blend` files. Everything here is regenerable or hand-editable, and every generated file records the exact command that produced it.

## Blockout

`blockout/blockout-2026-11-06.blend` — OSM blockout for the demo bounds, imported with Blosm from the committed extract. 276 objects, 87 meshes, in collections split by feature (`…_buildings`, `…_roads_secondary`, `…_paths_footway`, `…_roads_primary`, …).

### Rerun command

The Flatpak Blender cannot be launched with `flatpak run` from an agent shell, so the binary inside the app tree is called directly with the Flatpak user scripts path. This is exact, not approximate:

```bash
B=/var/lib/flatpak/app/org.blender.Blender/x86_64/stable/active/files
C="$HOME/.var/app/org.blender.Blender/config/blender/5.2"

LD_LIBRARY_PATH="$B/blender/lib" \
BLENDER_USER_SCRIPTS="$C/scripts" \
"$B/blender/blender" -b --factory-startup \
  --python Tools/blosm_blockout.py -- \
  --osm Geo/raw/osm-api-map-2026-11-06.osm \
  --bounds 34.1006,-118.3422,34.1020,-118.3370 \
  --assets-dir /run/media/system/DATA/Downloads/blosm-assets/assets \
  --out Art/blender/blockout/blockout-2026-11-06.blend
```

Run time is about 36 s for this extent. Two headless-only workarounds are baked into the script and must stay there:

1. Blosm refuses to import until an asset directory is set; the paid asset pack path is passed explicitly and is **not** committed.
2. In background mode the GUI never fills Blosm's default level table, and the add-on then takes a code path with a broken relative import. The script seeds one entry.

## Frame correction

Blosm projects with a **sphere** of radius 6 378 137 m about the origin, not an ellipsoid. Against EPSG:26911 that is conformal but about 0.4 % oversized and rotated by the meridian convergence, which put the theatre ~2 m off. `Tools/blosm_blockout.py --origin` therefore fits a six-parameter affine from Blosm's frame into UTM on five spread control points and applies it to the imported roots. Fit residual: **0.0 cm**. After it, the blockout and the terrain share one metric frame.

Two traps, both already handled in the script: transform only **root** objects (children inherit, and doing both applies the transform twice — that looked like a 2 m placement error), and fit an affine, not a similarity (a similarity leaves ~30 cm).

## Terrain

`terrain/terrain-2026-11-06.blend` — regular grid from the committed 3DEP DEM, built by `Tools/terrain_from_dem.py`.

```bash
B=/var/lib/flatpak/app/org.blender.Blender/x86_64/stable/active/files
LD_LIBRARY_PATH="$B/blender/lib" "$B/blender/blender" -b --factory-startup   --python Tools/terrain_from_dem.py --   --dem Geo/raw/dem-3dep-1m-26911-2026-11-06.tif   --osm Geo/raw/osm-api-map-2026-11-06.osm   --out Art/blender/terrain/terrain-2026-11-06.blend
```

- 191 × 106 grid at 2 m over X −330…+50, Y −100…+110: 20 246 vertices, 13 640 faces.
- Z is NAVD88 minus 115.911 m, the DEM value at the origin, so the origin ground is Z 0.
- Building footprints from the OSM extract are **cut out** (6 310 cells), so rooftops never become terrain. 72 footprints masked.
- Z range −2.80…+8.19 m. The high values are the ground rising north of the boulevard, not rooftops: the maximum sits at the northern edge, Y +110.

Spot checks against the measured cross-sections:

| Point | Terrain Z |
| --- | ---: |
| Origin, Hollywood × Highland | 0.00 |
| Orange Drive end of the block | +3.39 |
| North sidewalk mid-block | +1.43 |
| South gutter, mid-block | +0.93 |
| Road centre, mid-block | +1.38 |

That reproduces both the 3.4 m eastward fall and the ~2 % crown, so the DEM, the cross-sections, and this mesh agree.

## Scale check (blockout, 2026-11-06)

Blender works in metres, and the imported meshes match the OSM geometry, so the blockout is 1:1 before any Unreal export:

| Building | Blender dimensions | OSM way outline | Height source |
| --- | --- | --- | --- |
| El Capitan Entertainment Centre | 25.72 × 54.47 × 14.50 m | 25.75 × 54.88 m | `height` tag 14.5 |
| El Capitan Theatre | 38.66 × 54.46 × 20.96 m | 38.59 × 54.87 m | `building:levels=6` × 3.2 m, plus roof |
| Madame Tussaud's | 42.48 × 56.77 × 15.90 m | 42.0 m frontage | `height` tag 15.9 |
| TCL Chinese Theatre | 43.78 × 75.90 × 18.10 m | 44.0 m frontage | `height` tag 18.1 |

Widths agree to a few centimetres; depths differ by up to 0.4 m because Blosm assembles **multipolygon relations**, not the raw way I measured. Placement after the frame correction agrees with the UTM control points to 0.1–0.5 m per building — the residual is relation assembly and Blosm's edge straightening, not projection.

Buildings **without** a `height` tag get levels × 3.2 m, which is a placeholder, not evidence. Every such height is a modelling decision to be replaced from the reference photography.

## Relation completeness

The extract is complete for the block but not for every relation inside its bbox: Blosm's optional member fetch pulled six ways from Overpass, all belonging to one 213 × 152 m multipart complex about 100 m north of the boulevard — outside the `0.1.0` bounds and out of scope. That fetch is therefore **off by default** (`--load-missing` enables it), so the committed blockout is reproducible offline from the committed extract alone. If background massing later needs that complex, refetch a wider extract rather than reintroducing a network dependency.

## What this blockout is not

- Not cleaned, not subdivided into façade modules, not UV-mapped, not detailed.
- Materials are placeholders from Blosm's simple mode. Realistic mode needs the paid material pack and was not run.
- Terrain, kerbs, and crossing ramps are not in it: those come from the DEM cross-sections in `Geo/verification/2026-11-06-cross-sections.md`.