# Viselora DOM WebGL Giving web pages depth and motion while preserving their structure. A DOM-first WebGL coordination runtime for React 19 and Next.js. Public APIs connect semantic DOM with one React Three Fiber scene, sharing measurements, progress and fallback state. R3F and Three.js own rendering, materials, models and motion. [Website source](https://zzzxc.com/projects/viselora) ## When web content enters a 3D scene Text, images, links and reading order are already organized by the web page. When they enter a WebGL scene, layout, coordinates, pointer hits, scroll responses and resource disposal must work together too. Maintaining those relationships separately for every visual effect makes later composition and changes increasingly difficult. Viselora starts from the DOM. The page keeps the foundation for content, layout and accessibility, while the runtime connects targets that need visual treatment to WebGL. Version 0.2 focuses on DOM coordination and lets applications express scenes directly with R3F components, reducing a separate layer of rendering abstractions. ## Connecting content and visuals through declarations Semantic elements register through WebGLTarget. Applications read live geometry, visibility and content revisions with useDOMTarget, and use text measurement and texture utilities to connect DOM typography. Images, video and models use Three.js, R3F or Drei loaders. Web content stays in children and native R3F components go in the same host’s scene. Meshes, materials, cameras and lights use ecosystem APIs directly, with frame updates in useFrame. Applications create and dispose their own resources without the previous object and material facades. ## Keeping lifecycle management in one place Each runtime hosts one R3F Canvas; R3F owns rendering and the frame loop. Viselora coordinates DOM measurement, shared inputs, offscreen visibility and observer cleanup. Applications own textures, model instances and materials, with a separate disposal boundary for shared loader caches. Visuals replacing DOM paint explicitly report readiness with the target identity captured at load time, preventing stale results from affecting a new node. Unavailable WebGL restores semantic content. Offscreen policy controls fallback visibility; applications decide whether to retain or unmount visual resources. ## Using shared inputs for scrolling and interaction Viselora provides progress signals, timelines and scroll adapters. It can follow native scrolling or integrate with Lenis, GSAP and ScrollTrigger. Multiple visual objects can use the same progress source to express stages such as approaching, rotating, unfolding, reading and retreating. R3F handles mesh picking and pointer events; ordinary links and keyboard controls keep DOM events. Applications handle interaction priority, touch alternatives and reduced motion. Frame updates modify native objects directly without passing per-frame progress through React state. ## Bringing the runtime into a real website This personal website is one application of Viselora. A tetrahedron approaches as the page scrolls; content on its faces gradually aligns with the screen, then hands off to readable, interactive prose. The profile model, article sheets and project room continue to use the same public runtime capabilities. The site owns web layout, links and mobile reading, while native R3F components express 3D projection, materials and motion inside the shared scene. As an independent project installing the published 0.2 npm packages, it tests the smaller public interface in an actual application. ## Turning specific effects into reusable examples The example application combines native R3F scenes with DOM targets, text textures, models and scroll progress. Developers can read public API examples and migration guidance, then organize their own visuals with the familiar Three.js/R3F ecosystem. These modules are application-level examples whose visuals and content are organized by the caller. Runtime packages continue to provide general capabilities. API documentation, capability status records and agent-facing guidance help users distinguish public entry points, available evidence and their own application responsibilities. ## Current stage and scope The project is at 0.2.0-alpha.0, with the core runtime and scroll adapters distributed separately through npm. Its public scope focuses on one Canvas host, DOM registration and measurement, fallback visibility, shared progress and text texture utilities. Scenes, loaders, picking, physics and postprocessing use the R3F/Three.js ecosystem. The current version requires React 19, R3F 9 and Three.js 0.184, and no longer supports framework-independent consumers or the previous managed APIs. Applications provide semantic descriptions, fallback content and resource lifecycles. Real-device behavior, complex-scene performance and final visual quality still need verification in each product. ## From web content to spatial expression ### Organize the DOM Keep content, links, layout and reading order in semantic elements. ### Declare visual targets Register semantic DOM targets that need a visual replacement. ### Measure & project Connect DOM geometry and scene coordinates through the runtime. ### Connect shared inputs Use scroll progress, timelines and pointer state to drive effects. ### Render the scene Apply materials, lighting and motion in native R3F components. ### Handle lifecycle Report visual readiness and handle caches and cleanup by resource ownership. ## Explore the project - [Source & project documentation](https://github.com/agenticnoob/dom-webgl-workspace) [Contents](https://zzzxc.com/agent/en/index.md)