gig-line/Art/blender

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:

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.

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.

Street corridor

street/street-2026-11-06.blend — road, kerbs, and both sidewalks, built by Tools/street_mesh.py from the DEM and the centreline.

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/street_mesh.py -- \
  --osm Geo/raw/osm-api-map-2026-11-06.osm \
  --dem Geo/raw/dem-3dep-1m-26911-2026-11-06.tif \
  --out Art/blender/street/street-2026-11-06.blend

• Road_Hollywood: 8 120 verts, 7 812 faces, carriageway −10.5…+10.5 m, DEM elevations plus a 2 cm lift so it does not z-fight the terrain.
• Sidewalk_South 4.0 m wide, Sidewalk_North 5.3 m wide, both raised by the kerb height.
• Kerb_South, Kerb_North: vertical faces, mostly 0.13 m — the 0.15 m assumption minus nothing on the road side — and flushed to 0 within ±2.5 m of each signalised crossing with a 1.5 m blend. Measured from the built mesh: 256 steps at 0.13 m, 15 flush, a few in transition.

Crown check on the built mesh at mid-block: gutter −10.5 m → +0.99, −5 m → +1.38, centre → +1.52, +5 m → +1.58, +10.5 m → +1.52. The crown sits just north of the centreline, as the cross-sections said.

Assumptions, recorded rather than hidden: kerb upstand 0.15 m (DEM cannot resolve it), sidewalk widths from the setback arithmetic, and crossing ramps modelled as kerb flushes rather than graded ramps. Crossing markings, kerb radii at the junctions, driveway aprons, drainage inlets, and pavement joints are not modelled.

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.