Your browser sucks, JavaScript disabled! Gunnar's console needs JavaScript and WebAssembly. Git over SSH on port 2222 does not.

nordisk/facett

facett-map3d-flight/.nornir/terrain-benchmarks.md

Terrain DEM — HEAVY benchmark results

Bench: benches/heavy_terrain.rs (criterion). Run:

export CARGO_TARGET_DIR=/mnt/work4t/cargo-target/facett-map3d-flight
cargo bench -p facett-map3d-flight

Machine (HEAVY — full cores + max memory)

Tile size

Default grid 1024 × 1024 vertices = 1 048 576 vertices / 2 093 058 triangles per mesh build. .hgt load bench uses a real 1-arc-second SRTM tile: 3601² = 12 967 201 samples. Sampling benches use 1 000 000 query points. Override the grid with MAP3D_FLIGHT_BENCH_GRID.

Results (median)

Bench Time Throughput What
hgt_load/srtm_1arcsec_3601 36.8 ms 352 Melem/s parse a full 1-arc-sec SRTM .hgt (3601², big-endian i16)
dem_sample/bilinear_1M 18.9 ms 53.0 Melem/s bilinear elevation_at over 1 M points on a real DEM grid
procedural_sample/fbm_1M 64.3 ms 15.6 Melem/s synthetic-fallback (4-octave) sampling over 1 M points
build_mesh_dem/dem_1024x1024 45.7 ms 45.8 Mtri/s full terrain mesh (verts + normals + indices) from a DEM
build_mesh_synth/synth_1024x1024 67.1 ms 31.2 Mtri/s same build over the procedural fallback

Reading it: a ~2.1 M-triangle Sweden terrain patch builds from a real DEM in ~46 ms single-threaded (≈22 full rebuilds/s; incremental/streamed builds are far cheaper), DEM bilinear sampling runs at 53 M queries/s (the elevation_at the drape pass will hammer per footprint), and a full 1-arc-second SRTM tile parses at 352 M samples/s (~37 ms for a 13 M-sample tile). The procedural fallback is ~4× the sampling cost of a DEM lookup (four trig octaves vs a 4-tap bilinear) but never touches disk — the deterministic CI/no-tile path.