The asset-brief template (scope/visual-reference/naming/gen-path/ acceptance, one page) and five real briefs — station walls, rural walls, doors, floors, furniture/props — each citing its D-235 axis tokens and palette.md register rows (or the D-257 toon default), conventions.md naming/mask/footprint rules, and the image-gen -> glb-gen -> promotion path with concrete acceptance counts. Doors carry the negative no-state-frame-files constraint (runtime mechanism stays Phase 5); furniture/props' first acceptance is promoting the three unpromoted spike GLBs. deferred.md is the formal register for the T-1051 four (lamp posts, barns, TVs, billboards) + cars/Q-067, with rationale and revisit triggers — satisfying T-1051's own 'or record formal deferral' deliverable. Child stories under T-961 are created lead-side at merge. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4.3 KiB
title, description, type, status, ticket, decision_refs, author, created, updated
| title | description | type | status | ticket | decision_refs | author | created | updated | |||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Asset Brief — Doors | Door models — no D-235 ObjectTag axis; logical DoorSpec exists, runtime open/closed mechanism deferred to Phase 5 | design | active |
|
Araminta | 2026-07-25 | 2026-07-25 |
Asset Brief — Doors
One page. Gates its child story — the story does not enter in_progress
without this brief attached.
1. Scope
Door models (furniture or props manifest category — a door is a
fitted architectural object, closer to props; the manifest's category
field is authoritative regardless of subdirectory per conventions.md §1).
Doors have no D-235 ObjectTag axis — wall/roof/facade/street are building-
exterior surface tags; a door is a discrete object that sits in a wall
opening. What DOES exist already: the logical DoorSpec/
InteriorDescriptor model (T-979/T-998, D-231) — door count derivation
(Main/Service/Emergency/Hidden) and initial-state derivation (Open/
Closed/TemporalWindow/Locked/Sealed) — but that work is server-side
struct definition only, not visual. This brief covers the visual asset
only; it does not touch T-979/T-998's derivation logic.
2. Visual Reference
No D-235 token to cite — doors take palette.md §2's toon default (same
shader family as characters/furniture: toon.gdshader or toon_masked .gdshader, roughness=1.0/specular=0.0). A door with a glazed panel
(e.g. a station door with a window) falls under the §2.1 glazing carve-out
if the pane is gameplay-load-bearing for sightlines — treat that panel as a
separate material slot at minimal-PBR, the rest of the door stays flat toon.
No dedicated door row exists in palette.md §3's material register (that
table only covers wall/roof/facade/street) — if a door's finish should match
its host building's wall material (e.g. a timber door on a timber_wall
building), that is a future content-authoring choice, not something this
brief specifies.
3. Naming
<category>_<descriptor>.glb per conventions.md §1 — e.g. door_sliding .glb, door_hinged.glb. Negative constraint, binding (conventions.md
§5): do NOT author state-frame suffix files (door_open.glb/
door_closed.glb). One door .glb per descriptor; the DoorSpec states
(Open/Closed/TemporalWindow/Locked/Sealed) are a runtime
transform/animation on that single model — the actual mechanism
(AnimationPlayer swing, procedural hinge rotation, or a named "open" bone
convention) is explicitly a Phase-5 rendering decision, out of scope for
this Phase-4 asset brief and for the story it gates. Mask sidecar
(<model>_mask.png) only if a tintable variant is wanted; footprint is
single-tile ([1, 1], omit the field) — a door does not span multiple sim
tiles.
4. Generation Path
Standard path: /image-gen (toon-shaded concept, 3/4 front view, closed-door
pose since there is no baked open state) → /glb-gen (Trellis) → Blender
postprocess → promotion into client/assets/models/props/ + manifest.json
entry. No texture-only alternative here — a door is inherently a discrete
mesh, not a tileable surface.
5. Acceptance
2 starter assets enter models.md + manifest.json at planned: (1)
door_hinged — the generic single-leaf door, the closest thing this class
has to a D-235-style fallback default even though no generic_door tag is
formally ratified (Q-119's text lists "generic door/floor/furniture parents"
as a candidate milestone-0 set alongside the ratified generic_wall/roof/ facade/street — milestone-0 IF Q-119 resolves yes, not resolved here);
(2) door_sliding — matches the workshop-outcomes.md §3.3 door_sliding
prior-art mention and a plausible station-context default. Both ship as one
model each, no state-frame variants, per §3's negative constraint.
Cross-References
docs/assets/visual/conventions.md§1, §2, §5 — model naming, mask sidecar, door-state negative constraintdocs/assets/visual/palette.md§2 — toon default, glazing carve-out if applicabledocs/assets/visual/models.md— target catalogclient/assets/models/manifest.json- T-979/T-998 (D-231) — the logical
DoorSpec/InteriorDescriptorthis brief's visual asset will eventually attach to (Phase 5, not this brief's scope)