@@ -42,7 +42,7 @@ release-candidate foundation, not yet a 0.10.0 release candidate.
| QA/CI | Headless suite, smokes, screenshot compare, 21/21 judge | Release-candidate smoke matrix, final gallery and release dry run | Regressions escape the release gate | 0.9.6 / 0.10.0 |
| Release/legal | Unsigned desktop/macOS builds, Web/HQ packages | Signing/notarization decision, checksums, AI-asset provenance, credits, privacy/body-camera and rating review | Public release blocked by trust/policy | 0.10.0 |
| Documentation | Architecture/ADR/status/roadmap ownership established | Final README/changelog/status/TODO/smoke-checklist sign-off and known-limitations page | Docs drift at launch | 0.9.6 / 0.10.0 |
| Future 0.x | Stable 0.x feature set | Live replay, more venues, VO/music, image-to-mesh props and seasonal content | Scope creep before release | 0.11.0+ |
| Future 0.x | Stable 0.x feature set | Live replay, more venues, VO/music, image-to-mesh props and seasonal content | Scope creep before release | Unscheduled |
**Current priority: ** map optimization, the **pre-build NPC revisit ** , the
**0.9.3 UI polish ** , **0.9.4 NPC visual optimization ** , **0.9.5 texture
@@ -200,15 +200,15 @@ verify every distribution path. This is the next minor release after the 0.9.x p
- [ ] Exit: the release candidate is content-locked, externally played, legally reviewed,
documented, reproducibly built, and approved as the 0.10.0 release candidate.
## Milestone 0.11.0 — NPC model variety
## Character development
Goal: break the eight-character clone effect with four licence-cleared crowd-variety looks while
keeping the frozen `npc_base` bone, tint-slot and gear-attach contract. The procedural generator is
the primary path; Quaternius is a reviewed reference and MakeHuman is deferred to a separate local
development pipeline. Start only after the 0.10.0 release candidate is published; this milestone
must not delay the release.
development pipeline. Start only after the current release candidate is published; this work must
not delay the release.
### 0.11.1 Source review and decision
### Source review and decision
- [x] Research free/open-source character sources and evaluate at least three downloads against
the existing Blender contract. (Measured Quaternius CC0, Kenney CC0, Khronos
@@ -228,19 +228,19 @@ must not delay the release.
`docs/blender_previews/sheet_npc_sources_research.jpg` with Cesium CC-BY attribution;
the project-owned crowd prototype sheet is also committed.)
### 0.11.2 Intake and validation
### Intake and validation
- [ ] Add a Blender `inspect` path that imports a GLB, applies node transforms, reports
tris/verts, bounds, bones, materials, UVs and skinning, and lists contract failures.
- [ ] Add an `adapt` path for future external assets: scale/ground, weld seams, decimate, map the
five tint slots, and either rebuild the contract armature or record an explicit second-rig
contract. The Quaternius prototype showed that a contract rebuild needs a proportion warp,
so this is not on the 0.11.0 critical path.
so this is not on the character-development critical path.
- [ ] Keep `tools/blender_assets.py audit` as the single final gate; add a regression test for the
intake report/adaptation using a deterministic synthetic or licence-cleared fixture.
- [ ] Document the adapter commands and the go/no-go checks in `docs/asset-tooling.md` .
### 0.11.3 One-character prototype
### Quaternius prototype
- [x] Prototype one Quaternius CC0 variant: weld/decimate to budget and capture Idle/Walk
renders. (12,518 imported verts -> 3,199 after weld -> 2,423 / 4,654 tris after a 0.75
@@ -250,10 +250,10 @@ must not delay the release.
proportions and gear fit. (No-go for a contract rebuild: T-pose 62-bone realistic rig,
~0.96 m hip, ~1.68 m arm span and ~0.153 m shoulder joint do not match the arm-down
13-bone contract. Keep as reference; a second rig/animation path needs its own ADR.)
- [x] Make a go/no-go decision on Option B. (No-go for 0.11.0 ; proceed with the procedural
- [x] Make a go/no-go decision on Option B. (No-go for the current pass ; proceed with the procedural
generator and keep Quaternius as a visual/style reference.)
### 0.11.4 Roster and runtime
### Roster and runtime
- [x] Approve four crowd-variety looks (build, head silhouette, hair/beard, outer layer and
accessory; no clothing that labels the NPC's behaviour). (`npc_crowd_a` bun/slim/sunglasses,
@@ -261,13 +261,13 @@ must not delay the release.
hood/cup; prototype sheet committed.)
- [ ] Add the four approved specs to `CHARACTERS` , build and commit their GLBs/AO maps, and
update the manifest with roles and tint data. (Prototype assets are local under `tmp/` ;
do not add them to the 0.10.0 release candidate.)
do not add them to the current release candidate.)
- [ ] Replace the fixed `character_model_for()` mapping with deterministic per-role pools and add
tests for repeatability and duplicate avoidance.
- [ ] Rebuild and verify gear fit for every new variant (`blender_assets.py fit` plus the runtime
gear checks).
### 0.11.5 QA and release
### QA and release
- [ ] Run the 24-NPC budget smoke, portrait baseline, gear fit, headless suite and a release build
with the expanded library.
@@ -276,7 +276,7 @@ must not delay the release.
- [ ] Exit: a reviewed 12-character library passes contract audit, portrait/gear acceptance,
the 24-NPC budget and licence/provenance review without changing the runtime contract.
### 0.11.6 Deferred MakeHuman local pipeline
### Deferred MakeHuman local pipeline
- [x] Evaluate the MakeHuman CC0 base mesh for a later separate local development pipeline.
(19,158 verts / 36,972 tris; scaled to 1.82 m; decimate 0.35 -> 3,780 verts / 6,468 tris;
@@ -286,6 +286,152 @@ must not delay the release.
yes, prototype the local MPFB/MakeHuman pipeline outside the repo and commit only the final
CC0-derived assets with provenance.
## Local map development
Goal: build a local, data-backed map pipeline that can replace or supplement the stylized venue
geometry with licensed OpenStreetMap footprints, 3D building massing, reference-derived photoreal
facades and AI-assisted composition. This is an unversioned development track, not a release gate.
### Data, licensing and scope
- [ ] Define the first target block and whether the result replaces, supplements or only informs
the current stylized venue specs (`docs/hollywood-boulevard-map.md` ,
`docs/joke-shop-map.md` ).
- [ ] Audit OpenStreetMap's ODbL attribution/share-alike obligations and decide whether derived
geometry ships, stays development-only, or needs a separate data layer.
- [ ] Choose an offline OSM extract workflow (Overpass/Geofabrik) and pin the extract date and
query so the map build is reproducible.
- [ ] Evaluate licence-compatible 3D building datasets (OSM Buildings, Overture, CityGML/LOD1–
or local authority data); record coverage, accuracy, format and redistribution terms.
- [ ] Add a provenance sidecar for every map source and derived asset, including source URL,
licence, capture/extract date and attribution text.
### Reference imagery
- [ ] Write a reference shot list per block: facade materials, windows, signage, rooflines,
street furniture, curb cuts and lighting.
- [ ] Download and catalogue reference images from Wikimedia Commons, local/own photography or
other clearly licensed sources; record author, licence and attribution. Do not use
unlicensed Street View or scraped commercial imagery.
- [ ] Separate development-only references from shipped textures; commit only images with clear
redistribution rights and keep the rest under `tmp/` or the ignored reference folders.
- [ ] Define the photoreal target and a material-derivation workflow (albedo/normal/roughness,
AO, weathering) that matches the existing Compatibility renderer.
### Geometry and AI-assisted composing
- [ ] Prototype OSM footprint import into Blender at game scale and orientation, then compare it
against the current venue footprint/collider layout.
- [ ] Import 3D building massing for the target block, clean the topology and assign LOD bands;
do not import unbounded city-scale meshes into the runtime.
- [ ] Build a reusable photoreal facade kit (window bays, cornices, storefronts, awnings, signage)
so buildings share materials and stay inside the venue triangle/material budgets.
- [ ] Add an AI-assisted composition step for palette, facade rhythm and reference boards; record
the model, prompt and output, and keep human review as the acceptance gate. AI output must
not be treated as licensed map data or shipped without provenance.
- [ ] Integrate the result behind `WorldBuilder.VENUE_SPECS` with colliders, navigation obstacles,
occlusion and the existing day/night materials.
### Gaussian splatting evaluation: photo intake and provenance
Gaussian splatting is evaluated as a photo-driven pipeline: licensed or permissioned photos
become a reference, texture source, mesh proxy or distant backdrop. It is an unversioned local
track with no runtime dependency or release gate until the ADR closes it, and it extends the
reference-image licence and privacy gates above rather than replacing them.
- [ ] Define the accepted photo channels: project/team captures, volunteer or user-supplied
photos with written permission, and downloaded images from clearly licensed archives
(Wikimedia Commons, Openverse, Mapillary and similar). Record which channel produced
each reconstruction.
- [ ] Write a one-page capture brief for user-supplied photos: overlapping arc or orbit around
the facade, 60–
filters off, no motion blur, no people or plates in frame where avoidable, overcast or
even light, and the facade height/doors/steps included in several frames.
- [ ] Build an intake checklist and provenance sidecar per photo set: contributor, consent or
property permission, licence and attribution text, source URL, capture date, camera/lens,
location, faces/plates/interiors present, redactions applied, file hashes and whether the
set is shipped or development-only.
- [ ] Set the licence gate: own photos need an explicit contributor licence; CC0/CC BY are
preferred; CC BY-SA triggers a share-alike review for derived textures and meshes; reject
Street View, social-media scrapes, unlicensed commercial imagery and AI-upscaled copies of
unknown originals. Attribution must be feasible in `CREDITS.md` before use.
- [ ] Set the privacy gate: blur or remove faces, minors, licence plates, screens, private
interiors and anything behind a closed door; obtain property permission where required;
keep a redacted copy as the reconstruction input and never commit the originals.
- [ ] Treat downloaded photo sets as sparse and of unknown intrinsics. Use them for reference,
palette and texture study, or as extra training views; do not expect a usable splat from
10–
- [ ] Keep photos, masks, COLMAP databases, checkpoints and splats outside git; commit only
derived, licensed, provenance-stamped assets that pass the review gate.
### Gaussian splatting: reconstruction and alignment
- [ ] Pin a reproducible offline toolchain (for example COLMAP or GLOMAP for camera poses plus
gsplat, OpenSplat, Nerfstudio or Brush for training), with exact versions, GPU/VRAM/disk
needs and known failure modes recorded in the sidecar.
- [ ] Reconstruct two quality tiers: a dense 100–
10–
file size and held-out PSNR/SSIM/LPIPS for both.
- [ ] Mask sky, people, vehicles and moving foliage before training; verify the masks do not
erase facade edges, signage or window detail, and keep the redacted input variant.
- [ ] Align the splat to game coordinates from the OSM footprint plus surveyed points (door
width, column spacing, step rise, storefront height) and record alignment residuals in a
Blender scene containing both the splat and the current venue geometry.
- [ ] Judge quality from held-out views and a render from the game’
not from training views alone; reject splats that only look correct from the capture path.
- [ ] Maintain a coverage map per block: which facades, corners and rooflines have usable views,
and which areas must fall back to the facade kit or stylized geometry.
### Gaussian splatting: map enhancement paths
- [ ] **Path A — Reference and QA (lowest risk): ** render the splat from game camera poses and
compare it with the realism captures; derive dimensions, signage placement, facade rhythm
and material colours. No splat data reaches the runtime.
- [ ] **Path B — Texture derivation: ** project splat renders onto the facade kit to produce
albedo, normal, roughness and AO candidates; de-light and bake them, then verify UV scale,
tiling and readability under the Compatibility renderer.
- [ ] **Path C — Mesh proxy: ** extract a mesh from the splat or dense reconstruction, retopo and
dress it in Blender, assign LODs, and keep it inside the venue triangle/material budgets
with mesh-based colliders and navigation.
- [ ] **Path D — Distant backdrop: ** test a baked panorama, impostor or billboard generated from
the splat for skyline and opposite-street depth where the player cannot walk; measure file
size, loading and visible pop at the venue boundary.
- [ ] **Path E — User-photo supplement: ** let a small supplied photo set improve one facade or
landmark (a signage patch, colour reference or hero detail) without rebuilding the venue;
define the minimum evidence and the same licence/privacy/review gate as a full capture.
- [ ] For every path record quality gain versus effort, licence compatibility of the derived
output, and whether the result may ship or stays development-only. Prefer the cheapest
path that closes the visible gap.
### Gaussian splatting: runtime evaluation and decision
- [ ] Probe Godot 4.7.2 Compatibility and Web support for splat rendering in a throwaway scene:
addon or importer availability, shader/sort cost, memory, load time and fallback behaviour.
Do not add a splat dependency to the release project during evaluation.
- [ ] Set hard limits before any runtime experiment: maximum per-splat file size and total
memory, allowed frame-time delta on the 24-NPC budget scene, acceptable Web load time, and
no compute-shader requirement for the Compatibility/Web path.
- [ ] Keep collision and navigation mesh-based even if a splat is displayed; a splat must never
become the playable floor or the access/occlusion authority.
- [ ] Write the ADR with a per-path go/no-go, the accepted licence/provenance rules, whether each
result ships or stays development-only, rejected alternatives and the evidence bundle.
- [ ] Exit: one licensed photo capture measurably improves a venue through a documented path and
passes visual, performance and provenance review; or the approach is rejected with
reproducible findings and removed from the release path.
### QA and exit
- [ ] Compare the data-backed block against the existing screenshots and map documentation; keep
the stylized fallback available.
- [ ] Run the venue triangle/mesh budget, navigation and collider checks, plus day/night capture
comparisons.
- [ ] Update `docs/architecture.md` , the venue map documents, `docs/asset-tooling.md` ,
`docs/development-status.md` and `CHANGELOG.md` when the pipeline ships or a source is
rejected.
- [ ] Exit: one local block is reconstructed from licensed data with reference-derived photoreal
facades, passes performance/navigation/visual QA and has complete provenance; or the
pipeline is rejected with the findings recorded.
## Future 0.x / non-blocking candidates
- [ ] Live 3D body-camera replay.
@@ -302,6 +448,11 @@ must not delay the release.
- Godot version changes can alter lighting/imports; do not combine an engine baseline move with a
content/feature milestone.
- Signed macOS builds and legal/AI provenance are release blockers, not polish.
- Photo-derived map assets add a second provenance risk: downloaded or user-supplied photos can
carry unclear licences, identifiable people, plates and property restrictions. No photo or
splat-derived asset ships without a completed sidecar, consent/licence review and redaction.
- Gaussian-splat training is GPU/disk-heavy and the toolchain churns quickly; keep it offline,
version-pinned and outside CI, and never make a runtime splat renderer a release dependency.
- Keep the de-escalation-first rules and rare-emergency design unchanged while adding progression,
difficulty and feedback.
zwitschi