Wall Phase 3 milestone B: runtime port behind feature flag
Brings the wall kind onto the registry path when
NEXT_PUBLIC_USE_REGISTRY_FOR_WALL=true; default-off keeps wall on its
legacy path unchanged.
Files added:
- nodes/src/wall/renderer.tsx — thin placeholder-mesh mount point.
Identical pattern to the legacy WallRenderer: registers ref via
useRegistry, marks dirty on mount, renders hosted children
recursively via NodeRenderer. The legacy WallSystem fills geometry
on the next frame regardless of which mount path is active.
- nodes/src/wall/system.tsx — a bundle component that renders
<WallSystem /> + <WallCutout /> (both re-exported from viewer).
Registered via def.system with priority 4 to mirror the legacy
WallSystem's useFrame priority. Zero logic duplication — the
~970 lines of CSG/mitering/cutaway code stays in viewer.
Files changed:
- packages/viewer/src/index.ts — new exports for WallSystem, WallCutout,
and NodeRenderer. The first two so the registry-driven system bundle
can compose them; NodeRenderer so any parent kind (wall, slab,
ceiling, building) can recursively render hosted children without
reaching into viewer internals.
- nodes/src/wall/definition.ts — adds renderer + system fields. Tool
field stays absent (wall placement / endpoint drag remain bespoke
for now; the affordance port is a later milestone).
- nodes/src/index.ts — conditionally appends wallDefinition to
builtinPlugin.nodes based on isWallRegistryEnabled(). With the flag
off, the array is identical to before this commit; with it on,
Phase 0 dispatch shims switch wall to the registry path:
* <LegacySystem kind="wall"> around WallSystem returns null
* <LegacySystem kind="wall"> around WallCutout returns null
* <NodeRenderer> takes the registry-first branch and mounts the
new renderer instead of the legacy switch case for 'wall'
* RegisteredSystems mounts the new system bundle, which re-mounts
the same WallSystem + WallCutout components from viewer
No behavior change with the flag off. With the flag on, behavior should
be byte-identical (same components, same priority, same geometry path).
Manual verification next: place walls, t-junctions, walls-with-doors
with the flag toggled both ways; confirm visual + interactive parity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.7
parent
0a723fa1f2
commit
02aeca8439
@@ -90,9 +90,28 @@ export const wallDefinition: NodeDefinition<typeof WallNode> = {
|
||||
|
||||
parametrics: wallParametrics,
|
||||
|
||||
// No `geometry` / `renderer` / `system` / `tool` fields yet — see file
|
||||
// header. Adding them registers wall via `builtinPlugin.nodes` and flips
|
||||
// the dispatch shims; do that in milestone B once the runtime port lands.
|
||||
// Wall's renderer is the thin placeholder-mesh mount point from milestone
|
||||
// B; the system bundle composes the legacy `WallSystem` + `WallCutout`
|
||||
// re-exported from viewer (so we don't duplicate ~970 lines of CSG /
|
||||
// mitering / cutaway logic just to swap the dispatch). The legacy
|
||||
// mount in `<LegacySystem kind="wall">` short-circuits the moment
|
||||
// `nodeRegistry.has('wall')` is true.
|
||||
//
|
||||
// No `tool` yet — wall placement / endpoint drag / curve drag remain
|
||||
// bespoke until the affordance port lands. Phase 0 shims keep the legacy
|
||||
// wall tool running while wall is registered (it's not wired through the
|
||||
// registry tool dispatch).
|
||||
renderer: {
|
||||
kind: 'parametric',
|
||||
module: () => import('./renderer'),
|
||||
},
|
||||
system: {
|
||||
module: () => import('./system'),
|
||||
// Priority 4 mirrors the legacy WallSystem's useFrame priority — keeps
|
||||
// miter cascade running after door/window animation systems (priority 2)
|
||||
// but before zone/level systems that read wall positions.
|
||||
priority: 4,
|
||||
},
|
||||
|
||||
presentation: {
|
||||
label: 'Wall',
|
||||
|
||||
Reference in New Issue
Block a user