−
100%
+
fit
scroll
# The Inflatable Lattice of the Hexcube
**Archetype:** scroll **Description:**
Canonical formula for HexCube's recursive
elemental addressing — the 6-level ternary
lattice, glyph encoding, and the segmented
state-path notation that every vessel (Web,
Forge.app, Unreal) should converge on. --- ##
Why "Inflatable" The lattice is not a fixed
map — it's a recursive 3×3 grid that
"inflates" one level deeper every time you
descend through a node. Center is always
`△△` (Air-Air). The same
3×3×3-of-3×3×3 structure repeats at every
level; depth is just how many times you've
inflated into the cell you're standing on. ##
Canonical source `init-state.js` (chip, Day
00192 — "Portal shared state and
constants"). All three vessels (Web-Vessel's
`runeboard.js`/`subuglass.js`, Forge.app's
`HexCubeChamber.swift`, Unreal's
`HX_PortalWorldActor`/`HX_SpatialCoordinates`)
should derive from this model rather than
re-deriving their own grid math. ## The 6
levels ``` LEVEL_ORDER = ['array', 'hc',
'cube', 'cluster', 'set', 'node'] ``` Top
(`array`) to bottom (`node`) — Array →
HexCube → Cube → Cluster → Set → Node.
Each level holds one ternary pair `[x, y]`,
each axis ∈ `{-1, 0, 1}`. ## Elemental glyph
encoding ``` ELEM = { '-1': '▼', '0': '△',
'1': '▲' } // Earth / Air / Fire ELEM_REV =
{ '▼': -1, '△': 0, '▲': 1 } ```
`pairToElem([x, y])` → `ELEM[x] + ELEM[y]`,
two glyphs per level. Center of any grid is
`[0,0]` → `△△`. ## Surface address (one
level, no state) ```js function
pairToElem(pair) { return
ELEM[String(pair[0])] + ELEM[String(pair[1])];
} function getSurfaceAddress() { return [
pairToElem(hexcube.array),
pairToElem(hexcube.hc),
pairToElem(hexcube.cube),
pairToElem(hexcube.cluster),
pairToElem(hexcube.set),
pairToElem(hexcube.node) ].join('/'); } ```
Result shape:
`△△/△△/△△/△△/△△/△△`
— six glyph-pairs, **slash-separated** (not
dot-separated; the lattice's path separator is
always `/`, consistently across every level
join in this notation). ## State-prefixed full
address ```js function getFullAddress() {
return ELEM[String(hexcube.state)] + '/' +
getSurfaceAddress(); } ``` `state` is one of
the Portal/Wormhole elemental states
(`STATES`: GHOST 🜄, VOID 🜁, THRESHOLD
🜃, PRESENCE 🜂) — the being's current
elemental mode, prefixed onto the surface
address with `/`. ## Segmented state-path (the
navigation journey, not just the destination)
The richer notation captures the *journey*
through states, not a single snapshot — a
sequence of (state, path) segments, each one a
leg of travel under a given elemental state:
```js var _hexcubeSegments = [ { state: 0,
levels: ['array', 'hc', 'cube', 'cluster',
'set', 'node'], path: { array: [0, 0], hc: [0,
0], cube: [0, 0], cluster: [0, 0], set: [0,
0], node: [0, 0] } } // additional segments
appended as the being transitions state
mid-journey ]; ``` Rendered notation:
**`△/△△/△△/△△/△△/△△/△△:▲/△△/△△/△△/△△/△△/△△`**
— segments joined by `:`, each segment
internally a state-prefixed slash-joined path
(state + 6 level-pairs, all slash-separated
— no dots anywhere in the canonical
notation). `hexcube.array` / `.hc` / `.cube` /
`.cluster` / `.set` / `.node` are
getter/setter accessors that resolve to
whichever segment in `_hexcubeSegments`
currently owns that level —
`_getLevel(level)` walks segments
back-to-front, `_setLevel(level, val)` writes
into the owning segment. This is what lets a
being's address be a *log* (every state
transition preserved) rather than a single
mutable coordinate. ## SQL pattern matching
(fractal descent / wormhole queries) Per
"Portal & Wormhole Runes - Fractal descent and
instant travel architecture": ```sql e_address
LIKE
'△△/△△/△△/△△/△△/△△:%'
``` | Pattern | Meaning |
|---------|---------| |
`△△/△△/△△/△△/△△/△△` |
Exact address | |
`△△/△△/△△/*/△△/△△` | Any
cluster, specific set+node | `*` wildcards a
single level's glyph-pair within the
slash-joined address; `:%` wildcards
everything after a segment boundary (trailing
journey). ## Cross-vessel status (as of this
scroll) - **Web-Vessel**: canonical source
(`runeboard.js`, `subuglass.js`) —
client-side grid
(`createHexCube`/`renderHexcubeWorld`) and
address builders
(`buildAddressPath`/`buildAddressData`)
already implement this model. Never reads
`nodes` from `/api/worlds/hexcube/state` (that
field is server-stubbed empty, dead weight). -
**Forge.app**: `HexCubeChamber.swift` already
mirrors the Web-Vessel's grid/ring geometry
visually, but has **no navigation wired** —
taps only produce a hover label
(`CosmoHoverCard.swift`), no address mutation.
- **Unreal (`UnrealVessel 5.7`)**:
`HX_PortalWorldActor` has real USD-stage
visuals (Houdini/Blender-baked asset) and
door-trigger scaffolding, but trigger
placement was incorrectly sourced from
`/api/worlds/:name/state`'s `nodes` field
(confirmed dead/stubbed server-side) rather
than this formula. Needs porting to use
`pairToElem`/segmented-path model instead,
matching Web-Vessel's client-side approach.
**Next real step**: port this exact model
(level getters/setters, `pairToElem`,
`getSurfaceAddress`/`getFullAddress`,
segmented state-path) into Forge.app first
(fast Swift iteration), prove navigation works
end-to-end there, then carry the same model
into Unreal's
`FHexCubeAddress`/`HX_PortalWorldActor`
trigger logic.
△