Request: export getWallHideState(wallNode, wallMesh, wallMode, cameraDir) from @pascal-app/viewer (currently a private function in systems/wall/wall-cutout.js; only WallCutout is exported).
Use case: a host application rendering overlays/companion layers inside <Viewer>'s children seam needs to respect the see-through wall states that WallCutout computes per camera move (visible / translucent / invisible). Today the only options are (a) re-implementing the facing-vs-camera dot product — which will drift from your semantics when they evolve — or (b) inferring the state from the currently assigned material variant's transparent flag, which is fragile against internal reshuffles.
Exporting the pure helper (it takes its inputs explicitly and touches no module state) would let hosts stay in lockstep with your hide-state semantics without forking. Happy to PR it if that's preferred.
Context: @pascal-app/viewer 0.9.2, host app mounting custom layers via Viewer children.
🤖 Generated with Claude Code
Request: export
getWallHideState(wallNode, wallMesh, wallMode, cameraDir)from@pascal-app/viewer(currently a private function insystems/wall/wall-cutout.js; onlyWallCutoutis exported).Use case: a host application rendering overlays/companion layers inside
<Viewer>'s children seam needs to respect the see-through wall states thatWallCutoutcomputes per camera move (visible / translucent / invisible). Today the only options are (a) re-implementing the facing-vs-camera dot product — which will drift from your semantics when they evolve — or (b) inferring the state from the currently assigned material variant'stransparentflag, which is fragile against internal reshuffles.Exporting the pure helper (it takes its inputs explicitly and touches no module state) would let hosts stay in lockstep with your hide-state semantics without forking. Happy to PR it if that's preferred.
Context:
@pascal-app/viewer0.9.2, host app mounting custom layers via Viewer children.🤖 Generated with Claude Code