jazrs1
**Package / versions tested:** `@designcodeio/threeui` — reproduces identically on `0.3.0`, `1.0.0`, and `1.1.0` (latest, published ~1 week ago as of this report). **Environment:** Chromium (Playwright-driven headless, but also reproduces in a normal launched instance), WebGL2 confirmed active on the canvas. ## What's observed Mounting `SylvaLivingWorldScene` (`variant="living-green"`) renders the iframe, and most of the scene comes up correctly: - The starfield/dust particle field renders - A soft ambient glow renders - A butterfly renders and correctly perches on a point on the branch surface (so its host geometry must exist) - A wireframe "cage" is visible **The branch/moss geometry itself never becomes visible**, at any wait time (tested up to 12s). The wireframe cage is a problem in its own right: per the source's own comments it's meant to be a transient effect that "snaps on, rides the [scan] front, then burns off" a few seconds into an entrance reveal animation — it never disappears, staying on screen indefinitely. ## Repro Minimal: ```tsx import { SylvaLivingWorldScene } from "@designcodeio/threeui"; import "@designcodeio/threeui/style.css"; export default function Page() { return <div style={{ width: "100vw", height: "100vh" }}> <SylvaLivingWorldScene variant="living-green" /> </div>; } ``` I also reproduced this **outside React/Next.js entirely** — extracted the exact `srcDoc` string the component builds (same slicing logic as `SylvaLivingWorldScene`'s internal adapter: everything from `<main class="hero" id="hero">` through the end of the file, with the bundled `three.min.js` inlined) and loaded it as a bare `<iframe sandbox="allow-scripts" srcdoc="...">` on a static HTML page with no framework at all. Same result: everything except the branch geometry renders, same persistent wireframe cage. That rules out anything Next.js/React-specific — it's in the shipped `inner-green-3d.html` source (or in how it behaves under this exact sandbox). ## What I ruled out - Narrow-viewport code path (`NARROW.matches` confirmed `false` at 1600×1000) - `prefers-reduced-motion` gate (confirmed not set) - `document.hidden` gate (confirmed `false`, `visibilityState: "visible"`) - Missing/failed network assets — after separately fixing the bundled-font CORS issue (see the sibling issue I'm filing), still reproduces exactly the same way - The render loop stalling — `window.__ready` is set (confirmed true; per source this only happens after 2 completed `renderer.render()` calls), so `requestAnimationFrame` keeps running - Cross-origin `window.parent`/`window.top` access throwing — no such access exists in the bundled source ## Hypothesis (unconfirmed) Looking at `inner-green-3d.html`'s source: there's a scan-reveal state machine (`scanning`, `scanT`, `uScanR`) that's supposed to progress `e` from 0 to 1 over `SCAN_DUR = 3.4` seconds and then disable a discard-based shader (`unscanned()`) used by the bark/foliage material. The wireframe cage's own opacity formula (`uWire.value = min(1, e/0.06) * (1 - smoothstep(0.72, 1.0, e))`) only produces a *visible, non-fading* wireframe when `e` is stuck somewhere in roughly the 0.06–0.72 range — which is consistent with what's on screen. If `e` never reaches 1, `uScanOn` never gets set back to `0`, and the bark/foliage shader keeps discarding every fragment forever, while unrelated systems on the same render loop (particles, glow, butterfly) keep animating normally. I could not pin down why `e`'s progression stalls, or whether it's specific to the `sandbox="allow-scripts"` (no `allow-same-origin`) embedding `SylvaLivingWorldScene` uses. Happy to share the standalone repro HTML file directly if useful.