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:

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

If you take it to the max (rate, speed) with 0 melt, let it fill up, then turn melt to the max - you get reverse snow falling up.

I'm learning about shadertoy so immediately went here:

https://www.shadertoy.com/view/tfKfRw

But no snow piling up which is nice!

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.

Here's my variant on the same toy idea, using a CA, generated trees, and a few other tricks.

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)

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.

python3 -m http.server 8080

[0] https://github.com/benperiton/SnowCam

Love everything about this. The idea of just do something because it's enjoyable for yourself, the retro style, the toyish-aspect...

Love it :)

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".

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

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!

[0] https://www.horsedrawngames.com/nye

[1] https://bitbucket.org/izzo/hdgnye

[2] https://youtu.be/qPOoU44GU50

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.

Brilliant!

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.

I feel like playing lemmings now!

Harkens back to https://boredhumans.com/falling_sand.php

I liked this! Very fun to play with when ignoring meetings.

Why do some snowflakes stop in mid-air?

Addictive

I had to check if the author was Alphapapa

This is fun to see :) thanks!

Powder toy deserves a mention here

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.