Show HN: I built a gravity simulator in pure CSS
multiplanetary.website
multiplanetary.website
They seem to fall at speed, but then de accelerate before touching the ground, then they bounce again until coming to a standstill.
The ball on the title looks accurate when bouncing, so I'm not sure if this is on purpose or not.
Running firefox under MacOS.
The stylesheet defines a single set of animation keyframes going from top to bottom at constant speed with a small bounce, and then applies the default CSS "ease" timing function to the entire animation. That results in an incorrect non-zero vertical initial velocity (making it seem like the ball was thrown downward rather than dropped), an initial downward acceleration that's vaguely in the right ballpark, and then a deceleration that's completely incorrect.
Firefox on Ubuntu: https://www.youtube.com/watch?v=5CihIHXj5HE
I'm guessing that this behaves differently on Chromium, or alternatively that OP has never seen a ball bounce before :)
The whole "feather and bowling ball dropped in a vacuum" experiment, right?
But that difference is not really measurable and probably barely calculable - though I'm sure someone on here may do that.
If you dropped them side-by-side the difference would require factoring in the curvature of the Earth and would really be way below anything you might measure... If you drop them in series then yes that does have another effect... the actual acceleration should be like g(1+m/M) instead of just g, so if a ball is 0.6 kg and Earth is 6e24 kg the fall time goes like √(2D/g) and so for a 10s (500 m) freefall in vacuum it changes the time by 0.5 yoctoseconds? Way smaller than any clock accuracy as far as I know...
No the real inaccuracy is that the drag force in air will scale like the square of the velocity,
m dv/dt = m g – ½ ρ A v² c
Where c is a dimensionless geometric constant called the Drag Coefficient, you can handwave that for these rough sphere surfaces it's maybe 0.5 or so, ρ is the density of air which of course gets lower at high elevations, at sea level it’s 1.22 kg/m³, but decreases like 0.13 kg/m³/km or so. A is the cross-sectional area of the ball π r². If you pretend that these variables are fixed instead of changing then this is a soluble equation, defining U = √{2mg/(ρ A v² c)}, dv/dt = g – g (v/U)²
v(t) = U tanh(g t/U)
U is the terminal velocity. Note that for small times tanh( gt/U) ≈ gt/U and v(t) ≈ gt becomes independent of U and hence m...So that's my pet peeve: The two things on Earth should fall side-by-side in tandem at first, then slowly the tennis ball should lag behind! That's not what we see in this simulation, unfortunately.
GDoc: https://docs.google.com/spreadsheets/d/1AnUeQ0RR7a5GA6Nrtef7...
Yes, you're partially right...if we drop both balls on Moon, they'll fall at the same time. Because there's (almost) no air on the Moon. The ball with less mass has less force of gravity to fight with air resistance on the Earth. Therefore, it falls slower.
Maybe this video can help to visualize: https://www.youtube.com/watch?v=Esa0kKECZvM
Even that is not correct. Air resistance is proportional to cross-section, and gravity is proportional to mass. A ball with less mass but much less cross section will fall faster. It has less "force of gravity", but it has much less air resistance. In other words, a marble will fall faster than a basketball when accounting for air resistance.
Note that the animation is inaccurate in any case because (assuming constant air density) the velocity of a falling ball will never decrease (until it hits the surface) if it started stationary.
I didn't realize the "Why balls fall at all" was a button.
Predefined things you can drop are basketball, bowling_ball, massive_sphere, dense_sphere, lead_sphere, pine_sphere, pingpong_ball, ant, rat, cat, person, and phone. You can add other things if you know their mass, cross sectional area, and coefficient of drag.
.pink-earth {
animation:
ballGravityEarthPink 3.3s,
sceneRotate 30s infinite linear reverse;
animation-fill-mode: forwards;
}
.orange-earth {
animation:
ballGravityEarthOrange 1.36s forwards,
sceneRotate 30s infinite linear reverse;
}
@keyframes ballGravityEarthOrange {
0% { bottom: 4em;}
40% {bottom: 0em;}
55% {bottom: .5em;}
100% {bottom: 0em;}
}
@keyframes ballGravityEarthPink {
0% { bottom: 3.8em;}
94% {bottom: 0em;}
97% {bottom: .005em;}
100% {bottom: 0em;}
}It started as a simple website to show the latest photos from Mars by fetching data from NASA APIs, then progressed into APIs to demonstrate fun space updates (e.g. people in space, space flight table).
It soon evolved into an elementary demonstration of gravity in different celestial bodies (Earth, Moon, Mars, International Space Station for now), which I call 'gravity simulation'. Currently working on more accurate animations to simulate life on different planets. Hope you'll enjoy it!
Tech-stack: React for the web app, the simulator is CSS-only. I used Manim for making explanatory videos.
Disclaimer: just to make it clear, I'm not a physicist or an astronomer, just a space enthusiast. So, I'm sure there might be some inaccuracy in my animations. Would be more than happy if any one of you notice them and let me know.
I think this might be a good example of using the wrong tool for the job. JS would work great for this use case. No need to try to force CSS to do it.
Other than that, it does seem like a neat way to present the physics concepts!
Cool stuff, thanks for sharing!
It's simple to make in JS, and it can be intractable and allow for changing the inital conditions of the simulation, rather than an animation of a simulation.
But I think this also speak to how CSS have become 'feature bloated'.