@depthly/core

The vanilla-TypeScript WebGL engine and data-landscape visuals. Framework-free; wrapped as web components by @depthly/elements. three is a peer dependency.

Layout

src/
  engine/stage.ts                 renderer + scene + camera + lights + render loop + resize + dispose
  tokens/resolve.ts               read --depthly-* values (computed CSS, falling back to @depthly/tokens)
  data/heightField.ts             bin (x,y,weight) rows -> normalized height field (+ peak summary)
  visuals/density-terrain/        the flagship visual: DataTexture + shader displacement
    DensityTerrain.ts
    shaders.ts                    GLSL (vertex displacement + height-ramp + lighting)
    types.ts
  a11y/fallback.ts                visually-hidden table + one-sentence summary
  index.ts                        public surface
  density-terrain.ts              subpath entry (@depthly/core/density-terrain)

Status (PR-3)

The engine is implemented as the canonical foundation but has not yet been run in a browser or type-checked against an installed three — that happens in PR-4 when we add the build, the @depthly/elements web component, and the in-browser visual test. For a runnable preview today, open examples/density-terrain.html (self-contained, CDN Three.js). The pure data math is shared with that demo and is node-tested (examples/terrain-core.test.mjs).

Documented decisions (interim)

• GLSL ShaderMaterial first, TSL later. CLAUDE.md names TSL (compiles to WGSL+GLSL) as the eventual shader path. For the first visual we use a classic GLSL ShaderMaterial on the WebGL2 path so we get a verifiable, running visual fast. Migrating Density Terrain to WebGPURenderer + TSL is tracked for when CI tests both render paths. No data/token/API changes are implied.
• No hardcoded style. Colors and 3D parameters are read from --depthly-* tokens (via tokens/resolve.ts), defaulting to @depthly/tokens' resolved values — never literals.