pascalorg/editor

Environment @pascal-app/cli 0.1.5, self-hosted via npx @pascal-app/cli start (Linux, systemd), browser on http://pascal.localhost:<port> No cloud account involved — purely the local editor + local SQLite storage What happens In the References panel (Reference settings → Scans → "Upload scan or guide image"), picking a scan file (.glb) is a silent no-op in the self-hosted editor: the file chooser opens and accepts the file, then nothing: no network request is issued, no console error, no upload progress, no scan node added ("1 scan on this level" stays unchanged). Verified with devtools/network open: zero requests after file selection. Why (from source) packages/editor/src/components/ui/sidebar/panels/site-panel/index.tsx — handleUpload ends with: clearUpload(levelId) onUploadAsset?.(projectId, levelId, file, type) onUploadAsset is an optional prop and nothing in the local runtime provides it, so the optional call vanishes. (Guide images are fine — they have a local in-tre

What happened Imported a minimal hand-authored IFC4 file (IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey, one IfcSlab, four IfcWalls forming its perimeter) through editor.pascal.app/ifc. The 4 walls round-tripped perfectly: reported Length 10.00ft, Height 9.84ft, Thickness 0.656ft — exact matches for the 3.048m / 3m / 0.2m in the source file. The slab (IfcArbitraryClosedProfileDef + IfcExtrudedAreaSolid, no material layer set, PredefinedType = .BASESLAB.) came in as "Footprint 1 slab" but rendered offset to the side of the wall footprint instead of underneath it, and reports Thickness 0.16ft (≈0.049m) instead of the file's 0.15m. Expected: the slab occupies the same footprint as the walls (same rectangle, verified below) and reports 0.15m / ~0.492ft thickness. What I ruled out The file is internally consistent: the slab's profile points (#42–#46, (1.524,1.524)→(4.572,3.9624)) are the exact same absolute coordinates as the wall corner placements (#86, #108, #130

Summary packages/editor/src/components/tools/shared/pointer-support-cap.ts only type-checks when the consuming project enables noUncheckedIndexedAccess. const belongsToActiveLevel = (nodeId: AnyNodeId) => { let current = nodes[nodeId] // inferred as AnyNode (no `| undefined`) const visited = new Set<AnyNodeId>() while (current && !visited.has(current.id)) { if (current.id === levelId) return true visited.add(current.id) current = current.parentId ? nodes[current.parentId as AnyNodeId] : undefined // ^^^^^^^^^ } return false } With noUncheckedIndexedAccess: true (which the project itself uses) the initializer is AnyNode | undefined and the assignment is fine. With the flag off — a common, perfectly valid strict setup — the variable is inferred as AnyNode and assigning undefined fails: node_modules/@pascal-app/editor/src/components/tools/shared/pointer-support-cap.ts(166,9): error TS232

Summary LevelSystem animates level elevation with an unclamped lerp factor: // packages/viewer/src/systems/level/level-system.ts obj.position.y = lerp(obj.position.y, targetY, delta * 12) delta * 12 is a per-frame interpolation factor, so it must stay in [0, 1]. It exceeds 1 as soon as a frame takes longer than ~83 ms (12 fps) and exceeds 2 past ~167 ms (6 fps). Above 2 the iteration diverges: each frame overshoots the target further than the last, and the level's position.y runs away exponentially within a dozen frames. Impact The level (and everything parented to it — walls, doors, windows, roofs) is translated to a coordinate like -3.6e+22 and effectively disappears from the scene. The scene graph is intact; only the rendered transform is broken, so it looks like "the upper floor never loads". This does not reproduce on a desktop GPU at 60 fps. It reproduces reliably on: headless rendering (SwiftShader / software WebGL), which is what CI-style screenshot checks use; low-end phone

Split out of #492 as cause 2. #556 fixed cause 1 (level-wide recompute per frame); this is the remaining half and a design change rather than a regression. Measurement All numbers from @toycenterboss-bot's instrumented profiling in #492. macOS, Chrome, WebGPU renderer (three r185), frameloop="never" — so 50 FPS is a ceiling, and a 50.x reading means "hit the ceiling", not "hit the hardware limit". Scene Nodes Contents Draw calls Orbit FPS empty 0 grid and helpers only 24 50.3 zones 142 flat polygons 130 50.2 outer walls 88 perimeter only 534 50.0 real plan 310 walls and rooms 1362 50.2 full import 1089 outer + inner walls 6520 42.7 Cost tracks visible meshes, not node count — a 142-node zone scene costs 130 calls, an 88-node wall scene costs 534. Every scene under roughly 1400 calls holds the ceiling; the 1089-wall import falls off it. A scene-graph walk on that scene found 8 meshes with one material group, 1081 with three, and 24 with six: 3395 draw units, double