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>
91 lines
4.4 KiB
Markdown
91 lines
4.4 KiB
Markdown
---
|
|
title: "Asset Brief — Floors"
|
|
description: "Floor surface textures — D-228 FloorMaterial axis, no D-235 ObjectTag (interior/ground-surface, not building-exterior)"
|
|
type: design
|
|
status: active
|
|
ticket: ""
|
|
decision_refs: [D-228, D-244, D-257]
|
|
author: "Araminta"
|
|
created: 2026-07-25
|
|
updated: 2026-07-25
|
|
---
|
|
|
|
# Asset Brief — Floors
|
|
|
|
One page. Gates its child story — the story does not enter `in_progress`
|
|
without this brief attached.
|
|
|
|
---
|
|
|
|
## 1. Scope
|
|
|
|
Floor **surface textures** — the D-228 `FloorMaterial` axis (built surface
|
|
over ground: `None`/`Concrete`/`Pavement`/`Carpet`/`Metal`/… — an open,
|
|
extensible vocabulary owned by the tile-fill layer, not D-235). This is a
|
|
**different axis than D-235's `StreetSurface`** (outdoor paved/cobble/
|
|
packed-earth streets) — floors are the interior/indoor-adjacent ground
|
|
surface a character walks on inside a building footprint. No prior art
|
|
beyond `placeholder-art-spec-v01.md` §2.1's 4 sprite-era floor placeholders
|
|
and `workshop-outcomes.md` §3.3's mention (both pre-cascade, superseded
|
|
production model per D-244). Out of scope: street surfaces (D-235 axis,
|
|
folded into whichever wall/facade brief's district ends up owning street
|
|
dressing — not this brief), doors, furniture footprints.
|
|
|
|
## 2. Visual Reference
|
|
|
|
No D-235 register row exists for `FloorMaterial` (palette.md §3 only covers
|
|
wall/roof/facade/street) — floors take `palette.md` §2's toon default
|
|
(flat-lit, `roughness=1.0`/`specular=0.0`) with **one exception mirroring the
|
|
§2.1 glazing carve-out logic**: a `Metal` floor with a genuinely
|
|
polished/mirror finish (rare, e.g. a showroom) would need the same
|
|
minimal-PBR treatment for the same functional reason (a flat-toon mirror
|
|
floor misleads the player about reflections the way flat-toon glass misleads
|
|
about sightlines) — this is a narrow, judgment-call extension of an existing
|
|
carve-out, not a new rule; most `Metal` floors (deck plating, catwalk) stay
|
|
flat toon. `Concrete`/`Pavement` should read consistently with `palette.md`
|
|
§3.1's `concrete_wall` warm-neutral-grey register even though there is no
|
|
formal floor row — reuse that hue family for visual coherence between wall
|
|
and floor in the same room, rather than picking an unrelated grey.
|
|
|
|
## 3. Naming
|
|
|
|
Texture: `<object_tag>_<map_type>.png` shape from `conventions.md` §3,
|
|
substituting the `FloorMaterial` value for the object_tag slot since floors
|
|
aren't D-235-vocabulary-keyed — e.g. `concrete_floor_basecolor.png`,
|
|
`carpet_floor_basecolor.png`, `metal_floor_normal.png`. No standalone floor
|
|
*model* — floors are always a tileable surface, texture-only, no Trellis
|
|
step. No mask sidecar (material register drives color, not tint); no
|
|
`footprint_tiles` (a floor texture tiles across the tile grid, it doesn't
|
|
have a discrete multi-tile footprint the way a piece of furniture does).
|
|
|
|
## 4. Generation Path
|
|
|
|
Texture-only path: `/image-gen` produces a flat, tileable concept at the
|
|
target hue/grain (no 3/4-view object framing — a floor concept should be a
|
|
top-down or straight-on flat material swatch) → lands directly in
|
|
`textures.md`, no `/glb-gen`/Trellis step (there is no mesh to convert).
|
|
Concept prompts should explicitly request a **seamlessly tileable** surface
|
|
pattern — the standard `/image-gen` style block doesn't cover tiling by
|
|
default and needs an explicit add-on instruction for this class.
|
|
|
|
## 5. Acceptance
|
|
|
|
3 starter assets enter `textures.md` at `planned`: (1) `concrete_floor` —
|
|
the most common interior default, reusing the `concrete_wall` warm-grey hue
|
|
family per §2; (2) `pavement_floor`; (3) `carpet_floor` — the class's first
|
|
non-hard-surface test case (different grain/weathering behavior than the
|
|
masonry-derived floors). No generic-fallback-parent entry applies here — the
|
|
Q-119 generic-parent question is scoped to the ratified D-235 axes plus "door/
|
|
floor/furniture parents" it names as a candidate extension; if that
|
|
extension is adopted (Q-119 resolves yes), a `generic_floor` placeholder
|
|
becomes milestone-0 for this class too, but that decision is not made here.
|
|
|
|
---
|
|
|
|
## Cross-References
|
|
|
|
- `docs/assets/visual/conventions.md` §3 — texture naming shape (adapted for non-ObjectTag axis)
|
|
- `docs/assets/visual/palette.md` §2, §3.1 — toon default + glazing-carve-out logic, wall hue-family reuse
|
|
- `docs/assets/visual/textures.md` — target catalog
|
|
- D-228 — `FloorMaterial` axis definition (override-stack: wild → economic → user mutator)
|