What problem does it solve?
Choosing and implementing GPU-accelerated rendering for dense or spatial data is error-prone: teams often pick decorative 3D, the wrong WebGL library, or architectures that fail on mobile GPUs, accessibility, and export. This Skill guides when WebGL is analytically justified and how to build scenes that remain readable, performant, and testable.
Core Features & Use Cases
- Renderer Selection: Decision guidance across Three.js, deck.gl, luma.gl, raw WebGL2, regl, PixiJS, Sigma.js, Plotly WebGL, ECharts GL, MapLibre/Mapbox, CesiumJS, and Babylon.js, with explicit criteria for when SVG, DOM, or Canvas2D are better.
- Scene Architecture: Patterns for BufferGeometry, instancing, typed arrays, shader contracts, GPU picking, camera states, DOM/SVG overlays, and single-renderer ownership with fallbacks.
- Particle and Flow Encodings: Rules for using particles, trips, arcs, pulses, and glows as honest data encodings with reduced-motion and static fallbacks.
- Use Case: A user asks to visualize hundreds of thousands of GPS trips on a map; the Skill recommends deck.gl TripsLayer over raw WebGL, defines the animation clock, picking model, and mobile DPR budget before implementation.
Quick Start
Ask the assistant to design a WebGL visualization for your dataset, for example: "Build a deck.gl flow map of 500k trips with GPU picking and a reduced-motion fallback."
