zwitschi
bf23a27939
Tools/blosm_blockout.py imports the committed extract in 3Dsimple mode and reports per-building dimensions so a units failure is visible in the log. The result (87 meshes) is committed as the blockout baseline: hero 25.68 x 54.88 x 14.50 m against 25.75 x 54.88 m of OSM geometry, so the import is 1:1 metres. Two headless defects needed working around: the asset-directory check that fires before mode is honoured, and an empty default-level table sending the add-on down a broken relative import. Member fetching stays off so the import does not depend on Overpass.
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:
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:
- Blosm refuses to import until an asset directory is set; the paid asset pack path is passed explicitly and is not committed.
- 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.
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 | Measured in Blender | OSM geometry | Height source |
|---|---|---|---|
| El Capitan Entertainment Centre | 25.68 × 54.88 × 14.50 m | 25.75 × 54.88 m | height tag 14.5 |
| El Capitan Theatre | 38.59 × 54.87 × 20.62 m | 38.59 × 54.87 m | building:levels=6 × 3.2 m, plus roof |
| Madame Tussaud's | 42.41 × 57.20 × 15.90 m | 42.0 m frontage | height tag 15.9 |
| TCL Chinese Theatre | 43.75 × 76.19 × 18.10 m | 44.0 m frontage | height tag 18.1 |
The 0.07 m width difference on the hero is Blosm's own projection of the outline, not a units problem. Anything larger than a few centimetres would be a flag.
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.