Very nice! I made a version of this effect for a little NYE thing years ago [0] (source here [1]). I first saw this effect in Iguana's Blastersound BBS intro [2]. I always thought that intro looked slick!
Every year during snow season I try to make it faster/more flakes. After this year though in chrome, I think it'd be whiteout conditions ;-) (it'll auto-scale to try to match your system performance. Best effects in a clean browser with not too much else running/open at the same time)
Cool toy! As an avid snow enjoyer, I would like to point out that wind and snow interact in all kinds of interesting ways, and it would be super cool to see some of those captured in future iterations of a toy like that.
One of those is that snow doesn't necessarily get packed onto the wind-exposed side; those features tend to stay bare. The lee side is where the snow will accumulate, but with that too depends on the features. Tall / steep / abrupt features will tend to generate areas with no snow at all directly behind them. Gentle downwind slopes will accumulate massive snow drifts. This all of course depends on the quality of the snow itself, roughly related to the air temperature at the time of precipitation but not solely that.
A quick little tweak to add to the control panel could be "stickiness" - how much the snow pours vs sticks to itself. Cheap one and would give the toy some behavioural variation.
Seeing this really makes it hit home how rarely you find this sort of joy in tech anymore. This reminds me of when computers still seemed fun and I wanted to learn more about them
Oh, that's something I also did in QBasic ages ago. I since lost the source code, but it basically worked by querying the screen from bottom to top, finding snow pixels (white) and moving them down, unless there was an obstacle. The initial snow on the ground (and the snowman) were using a different color that was almost white so it wouldn't detect as snow. It worked fairly well in 320×200 at the time.
I've tried the same approach in Turbo Pascal with BGI in the hopes of having a faster language and higher resolution available. It turned out to be quite a bit slower, likely because drawing and querying pixels was a bit more involved when using an adapter layer like BGI.
A few weeks ago I tried rewriting all that in TypeScript for fun and also trying to integrate it as an easter-egg with our graph drawing library (which renders with SVG) and first had to figure out how to efficiently support arbitrary obstacles that are initially SVG as well as a potentially changing viewport of the whole scene. I got sidetracked and didn't finish it, but proper collision handling was so easy back then (just look at the pixel color), but now with vector graphics and reading pixels being a very slow operation in many cases, it was surprisingly complicated.
Neat to see and it takes me back years when I needed to make a similar effect for a Christmas greeting for Canon in Flash. It needed to be able to run in Flash and on sluggish office computers of the time (16 years ago - 2010).
I eventually settled on a pooled particle system with three bitmaps:
Display bitmap - the visible output
Collision bitmap - a grayscale heightmap tracking accumulated snow
Snow sprite - the particle graphic with soft/transparent edges
When a particle hit the collision bitmap (simple pixel check), I stamped its graphic onto both the display bitmap and added it to the collision bitmap. Using grayscale for collision meant soft-edged sprites contributed proportionally to the heightmap, preventing the soft/transparent edges from causing unrealistic fast accumulation. Using stamping meant that we did not have to keep all the collided particles in memory and so the user could spam away snow particles with their mouse to their hearts content (few 100's at a time).
Edit: even more fun to see all the different ways to solve the same 'problem'. From simple to quite complex!
I did something similar[0] in JS on a Christmas eve eve a while back - needs to run via a server now as Web Workers cannot be loaded from file:// anymore.
I never did the collision physics, but I used to love making graphical demos with "falling sand"-type simulations.
One of the first was "rain" [1] by semi-randomly walking blue pixels down the screen and not clearing the buffer. But then the screen would go all blue, so I made them pop up to the top and do the same walk but as black pixels. It came out as a rain-on-the-window effect:
Eventually, I started just using one pixel and moving it really fast to render scenes. This is basically what raster rending does anyway, but instead of doing every pixel, the random walk will only hit a subset of pixels every frame and will make a really cool scratchy effect.
As a bc skiier though, an actual snow simulator, on real topos, with wind/rate/quality/temp/sun sliders would be useful for the study of snowpack formation and avalanche conditions.
The nostalgia is real. Reminds me of the 'Falling Sand' game era.
For anyone trying to scale this in JS: the bottleneck usually isn't the rendering, but the object overhead/GC.
If you switch from an object-per-flake model to a single flat Float32Array for positions/velocities (Data-Oriented Design), you can typically push 10x more particles before hitting the frame budget. Keeping the memory layout cache-friendly makes a massive difference even in a high-level managed environment like V8.
Snow Simulation Toy
(potch.me)172 points by surprisetalk 20 January 2026 | 44 comments
Comments
[0] https://www.horsedrawngames.com/nye
[1] https://bitbucket.org/izzo/hdgnye
[2] https://youtu.be/qPOoU44GU50
https://vps.kimbruning.nl/snow/2025/snow_singlecore_scalable...
Every year during snow season I try to make it faster/more flakes. After this year though in chrome, I think it'd be whiteout conditions ;-) (it'll auto-scale to try to match your system performance. Best effects in a clean browser with not too much else running/open at the same time)
One of those is that snow doesn't necessarily get packed onto the wind-exposed side; those features tend to stay bare. The lee side is where the snow will accumulate, but with that too depends on the features. Tall / steep / abrupt features will tend to generate areas with no snow at all directly behind them. Gentle downwind slopes will accumulate massive snow drifts. This all of course depends on the quality of the snow itself, roughly related to the air temperature at the time of precipitation but not solely that.
A quick little tweak to add to the control panel could be "stickiness" - how much the snow pours vs sticks to itself. Cheap one and would give the toy some behavioural variation.
I also rate the author's slogan: "make things, not too much, mostly crap". A reference to Michael Pollan's "eat food, not too much, mostly veg".
I've tried the same approach in Turbo Pascal with BGI in the hopes of having a faster language and higher resolution available. It turned out to be quite a bit slower, likely because drawing and querying pixels was a bit more involved when using an adapter layer like BGI.
A few weeks ago I tried rewriting all that in TypeScript for fun and also trying to integrate it as an easter-egg with our graph drawing library (which renders with SVG) and first had to figure out how to efficiently support arbitrary obstacles that are initially SVG as well as a potentially changing viewport of the whole scene. I got sidetracked and didn't finish it, but proper collision handling was so easy back then (just look at the pixel color), but now with vector graphics and reading pixels being a very slow operation in many cases, it was surprisingly complicated.
Display bitmap - the visible output Collision bitmap - a grayscale heightmap tracking accumulated snow Snow sprite - the particle graphic with soft/transparent edges
When a particle hit the collision bitmap (simple pixel check), I stamped its graphic onto both the display bitmap and added it to the collision bitmap. Using grayscale for collision meant soft-edged sprites contributed proportionally to the heightmap, preventing the soft/transparent edges from causing unrealistic fast accumulation. Using stamping meant that we did not have to keep all the collided particles in memory and so the user could spam away snow particles with their mouse to their hearts content (few 100's at a time).
Edit: even more fun to see all the different ways to solve the same 'problem'. From simple to quite complex!
python3 -m http.server 8080
[0] https://github.com/benperiton/SnowCam
One of the first was "rain" [1] by semi-randomly walking blue pixels down the screen and not clearing the buffer. But then the screen would go all blue, so I made them pop up to the top and do the same walk but as black pixels. It came out as a rain-on-the-window effect:
https://x.com/Rendello_/status/1231426590380318729
Eventually, I started just using one pixel and moving it really fast to render scenes. This is basically what raster rending does anyway, but instead of doing every pixel, the random walk will only hit a subset of pixels every frame and will make a really cool scratchy effect.
In PICO-8: https://x.com/Rendello_/status/1258243668626063361
In TempleOS: https://www.youtube.com/watch?v=W-wpUcDFZaI
Did anyone else ramp up all the settings to try and fill the screen with snow?
I saw a cool "bubbling" effect. Some of the air gaps by the trees would bubble up as the snow pilled on.
Is there a neural/positive term to describe this kind of website? (beside call it "old school" or "good old day"?)
As a bc skiier though, an actual snow simulator, on real topos, with wind/rate/quality/temp/sun sliders would be useful for the study of snowpack formation and avalanche conditions.
https://www.shadertoy.com/view/tfKfRw
But no snow piling up which is nice!
For anyone trying to scale this in JS: the bottleneck usually isn't the rendering, but the object overhead/GC.
If you switch from an object-per-flake model to a single flat Float32Array for positions/velocities (Data-Oriented Design), you can typically push 10x more particles before hitting the frame budget. Keeping the memory layout cache-friendly makes a massive difference even in a high-level managed environment like V8.