snowflow_demo: A WebGPU Tech Demo of Procedural Snow Rendering
A real-time procedural snow rendering demo built with WebGPU, Babylon.js and hand-written WGSL. Features GPU-generated terrain, snow deformation, procedural characters, cloth, surf wakes, water spells, atmosphere and post-processing—without textures, meshes, HDRIs or animation assets.
At a glance
- What is it?
- snowflow_demo is a real-time WebGPU tech demo of procedural snow rendering built with Babylon.js and hand-written WGSL shaders. There are no texture files, mesh assets, HDRIs, or animation clips in the repository; the terrain, snow shading, character, clothing physics, and wake effects are all generated on the GPU at load time. It is aimed at graphics engineers studying WebGPU rendering techniques and procedural generation methods.
- Who is it for?
- snowflow_demo is a reference implementation for engineers who want to study WebGPU terrain rendering, deformation buffers, procedural cloth simulation, or GPU-only scene generation. It is not a library, a game engine, or a starting template for a production project; the code is structured as a single demo and has no documented API for extension.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 65 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What snowflow_demo Is and Who It Is For
Most real-time 3D demos ship a collection of authored assets: mesh files, texture atlases, normal maps, animation rigs. snowflow_demo is an explicit counter-example. The README states that everything you see is generated on the GPU at load time and that there are no textures, no meshes, no HDRIs, and no animation data in the repository.
The intended audience is graphics engineers and researchers interested in WebGPU's compute pipeline, terrain rendering techniques, physically-based procedural animation, and GPU-driven snow simulation. The live demo at snowflow-lilac.vercel.app demonstrates the result in any WebGPU-capable desktop browser without local setup. The source code is the resource for engineers who want to read and study the implementation.
All five spells, the character locomotion, the terrain clipmap geometry, the snow surface appearance, and the surf wake are implemented in WGSL shaders and JavaScript. Nothing in the repository requires loading or parsing an external file beyond the Babylon.js and Vite packages.
The Terrain, Snow Shading, and Deformation Pipeline
The terrain is a nested-ring geometry clipmap: eight rings with 8.5 cm inner spacing, approximately 870 m radius, and 333,000 triangles, rendered in a single draw call. Vertices carry only a grid index and a ring level; the vertex shader computes world placement, level-of-detail morphing, and displacement entirely in the shader. The heightfield is layered gradient noise baked once into a 4096-square RG32F texture, which is mirrored back to the CPU so character ground contact uses exactly the same surface that is drawn.
Snow shading uses multi-scale normals over a wrapped diffuse term, a back-scatter subsurface component with depth-dependent blue tint, GGX specular, spherical harmonic ambient, and procedural view-dependent glints activated at grazing angles. Shadows are three hand-rolled cascades with world-space PCSS, texel-snapped against a rotation-invariant bounding sphere. The README notes that Babylon's cascade generator cannot be used here because the terrain has no CPU geometry matching what the vertex shader draws.
Trail deformation stores state in two 2048-square RGBA16F targets covering 80 meters (3.9 cm per texel), ping-ponged by a single full-screen pass per frame. The addressing is toroidal: a texel's UV is the fractional part of world XZ divided by the field size. This means the deformation window follows the player without any buffer copy. The four state channels are depression depth, displaced mass, compression, and ice. The mass channel separates a trail with raised berms from a flat footprint decal. The README states that approximately 71 percent of trail depth survives one minute, with anisotropic diffusion, wind-driven infill, and exponential decay all operating on the same buffer.
Running the Demo Locally
The project is a Vite application with two runtime dependencies: @babylonjs/core and @babylonjs/materials. Install and run with:
git clone https://github.com/Noniv/snowflow_demo.git
cd snowflow_demo
npm install
npm run devVite serves the project locally. Open the browser to the local URL Vite prints, typically http://localhost:5173.
The README specifies that a WebGPU-capable desktop browser is required. Supported browsers are Chrome or Edge 113 and above, Firefox 141 and above, and Safari 26 and above. The README is explicit: there is no WebGL fallback by design. If the browser does not expose navigator.gpu, the page displays an error and stops.
Controls: click the viewport to capture the pointer, then use WASD to move relative to the camera, mouse to look and scroll wheel to zoom, Shift to sprint, right mouse button held for snow-surf, and keys 1 through 5 for the five spells. F1 or the backtick key opens the settings and performance overlay, which exposes art parameters as live sliders and shows a frame-time graph with draw call and triangle counts.
The Procedural Character and Surf Wake
The character has no authored mesh, rig file, or animation clip. The README describes an 18-bone skeleton whose bind pose is a table of numbers, with geometry lofted from that table at load time. Locomotion is solved from motion state: gait phase advances with ground travelled, so stride length and ground speed are the same number by construction. Feet plant using a distance-driven stance and swing machine that writes a foot's world position on touchdown and holds it with two-bone IK, ensuring planted feet cannot slide.
Garments are Verlet cloth on four panels with distance, bending, and shape-memory constraints, plus nine body collision capsules and a hem that tracks the snow surface. The 36-by-12 solve is upsampled to a 72-by-32 surface through Catmull-Rom reconstruction in the vertex shader, decoupling simulation cost from tessellation quality.
The surf wake is a swept mesh, not a particle effect. Its spine is the path the board has taken, resampled every 30 cm into a 96-by-3 data texture; the static vertex lattice is indexed by column, row, and side, and every vertex position is computed in the shader. A 19-metre wake and a 2-metre one cost the same buffer and the same 4.6 KB upload per frame.
Comparison with Three.js
Three.js (threejs.org) is the most widely used JavaScript 3D library. It runs on WebGL (with a WebGPU renderer under development) and provides a scene graph, PBR materials, shadow maps, and a large ecosystem of loaders and tools. A typical Three.js project uses authored geometry files (GLTF, OBJ), texture images, and possibly skeletal animation clips loaded from disk.
The contrast with snowflow_demo is in approach. Three.js is designed around authoring assets in a 3D tool and loading them at runtime; its abstractions handle the common case of authored content well. snowflow_demo inverts this: all content is computed in shaders from mathematical descriptions, bypassing the loader and asset pipeline entirely. WGSL compute shaders handle the deformation buffer and the terrain bake; vertex shaders handle character geometry and wake mesh placement.
For an engineer who wants to build a snow terrain in a production app, Three.js offers faster iteration with authored assets. For an engineer studying how to implement GPU terrain deformation, procedural cloth, or toroidal deformation buffers, snowflow_demo provides a complete, running reference in around 3,000 lines of WGSL and JavaScript with no asset loading to abstract the pipeline.
Licence, Maintenance, and Performance Overlay
The project is MIT-licensed, allowing unrestricted use, modification, and redistribution including commercial applications. The last push to the repository was on 2026-07-28. There are no GitHub releases and no changelog file.
The settings overlay (F1 or backtick) is an engineering tool as much as a visual feature. It exposes every art parameter as a live slider: sun angle, wind bearing, subsurface scattering radius, deformation depth, tone-mapping curve, and exposure. The overlay also provides a frame-time graph with median, 95th percentile, and 1 percent low frame times, plus draw call count, triangle count, and a per-system CPU breakdown. Every rendering system can be toggled off individually. Debug views are available for normals, depth, cascade coverage, the deformation buffer, and the raw shadow map.
This level of debug instrumentation signals that the project was built as an engineering research artifact rather than a polish demo. A graphics engineer studying any one of its systems can isolate it in the overlay without modifying code.
Editorial conclusion
snowflow_demo is a reference implementation for engineers who want to study WebGPU terrain rendering, deformation buffers, procedural cloth simulation, or GPU-only scene generation. It is not a library, a game engine, or a starting template for a production project; the code is structured as a single demo and has no documented API for extension. Before opening it, verify that your browser supports WebGPU: the README states there is no WebGL fallback and the page halts with an error if navigator.gpu is missing. The last push was on 2026-07-28.
Frequently asked questions
What browsers and hardware does snowflow_demo require?
The README requires a WebGPU-capable desktop browser: Chrome or Edge 113 and above, Firefox 141 and above, or Safari 26 and above. A discrete or recent integrated GPU is required. The README states there is no WebGL fallback: if navigator.gpu is missing in the browser, the page stops with an error.
Does snowflow_demo include any authored 3D assets like meshes or textures?
No. The README explicitly states there are no textures, no meshes, no HDRIs, and no animation data in the repository. The terrain heightfield, snow shading, character geometry, cloth panels, and surf wake are all computed on the GPU from procedural definitions at load time.
How does the trail deformation system in snowflow_demo persist across movement?
Trail state is stored in two 2048-square RGBA16F render targets covering an 80-meter window. Addressing is toroidal, meaning the UV of each texel is the fractional part of the world position divided by the field size. The window follows the player without copying the buffer; newly exposed texels are zeroed by the same ping-pong pass that scrolls, relaxes, and splats new deformation.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/noniv-snowflow-demo)