improve introduction

This commit is contained in:
Cat Flynn 2024-04-26 20:34:42 +01:00
parent bb92ba25c1
commit 0ea2ae92ca
1 changed files with 42 additions and 11 deletions

View File

@ -1,23 +1,54 @@
# Interactive Astrodynamics # Interactive Astrodynamics
Kepler's laws of planetary motion describe the elliptical path of a object in a stable orbit. _“Space is big.
This includes the paths of objects like the Moon and the International Space Station around the Earth, or the path of the Earth around the Sun. You just won't believe how vastly, hugely, mind-bogglingly big it is.
I mean, you may think it's a long way down the road to the chemist's, but that's just peanuts to space.”_
Newton used his own laws to derive Kepler's, showing that celestial objects moved according to the same physical rules as those closer to home. ---
Indeed, it is trivial to [implement an _n_-body simulation](https://youtu.be/Ouu3D_VHx9o?t=403) of gravity using Newton's law of gravitation.
However, this approach works only for very simple scenarios.
Physics calculations in games are done with floating-point arithmetic, of which a limitation is that [numbers may only be approximately represented](https://www.youtube.com/watch?v=PZRI1IfStY0).
Limited precision poses a subtle and hard to solve problem which is present in any iterative algorithm, such as an _n_-body simulation based on universal gravitation. Say you're in a simulation, and you want to throw a ball.
Easy enough, you take what you know about classical mechanics and impart some force to your ball to give it an initial velocity.
Then you take little steps forward in time, applying some force due to gravity at every one.
You consider applying forces from air resistance too, but then remember you're a physicist, and think better of it.
Next, being in a simulation, you want to throw it a bit harder.
Like, superhuman hard - let's throw this thing into orbit.
You add a few zeroes to your initial throw and throw it straight ahead.
To your dismay once the ball gets more than a few kilometres away it does something funny.
It stops moving smoothly and instead begins to jitter.
Before long it's a complete mess, jumping from place to place and not really looking like it's been thrown at all.
Digging into your simulation, you find you've been using single-precision floats.
A rookie mistake!
You change them all to double-precision, and throw again.
This time, the ball sails smoothly away, and you watch it disappear over the virtual horizon.
Satisfied, you pivot on the spot to await the ball's return.
You estimate it should take 90 minutes or so, but dinner is in an hour, so you decide to hurry up and wait by speeding up time by a factor of a hundred.
At this rate, the ball will only be gone for a few seconds.
You take these few seconds to recollect what you know about objects in orbit.
Accelerating only due to the force of gravity, such objects move along elliptical trajectories.
Every orbit, they pass through the same points, and every orbit, they take the same amount of time to do so.
Checking your watch, you predict to the second when the ball will arrive, and slow things back to normal just in time to watch the ball appear in the distance.
You hold your hand out in exactly the position you released the ball, since that position is on its orbit.
You smile smugly, proud of your creation, and are just thinking of dinner when the ball arrives, hitting you squarely in the face.
---
It is straightforward enough to [implement an _n_-body simulation](https://youtu.be/Ouu3D_VHx9o?t=403) of gravity based on Newton's law of gravitation.
Unfortunately, physics calculations in games are done with floating-point arithmetic, of which a limitation is that [numbers may only be approximately represented](https://www.youtube.com/watch?v=PZRI1IfStY0).
Besides scale, a limited precision presents a subtle and hard to solve problem which is present in any iterative algorithm, such as an _n_-body simulation based on universal gravitation.
As part of its operation, the state at the end of one discrete [frame](https://gameprogrammingpatterns.com/game-loop.html) forms some or all of the input for the next. As part of its operation, the state at the end of one discrete [frame](https://gameprogrammingpatterns.com/game-loop.html) forms some or all of the input for the next.
This means that error due to the lack of precision accumulates over time, resulting in larger discrepancies from reality the longer the simulation is run for. Due to the missing precision, error accumulates over time, resulting in larger discrepancies from reality the longer the simulation is run for.
Unfortunately, floating points are a fact of life in game physics, and we are not going to escape them here. Floating points are a fact of life in game physics, and we are not going to escape them here.
So how does Kerbal Space Program do it? So how does Kerbal Space Program do it?
![ksp.jpg](ksp.jpg) ![ksp.jpg](ksp.jpg)
Kepler's laws make a simplification known as the two-body problem. Kepler's laws make a simplification known as the two-body problem.
Kepler's laws of planetary motion describe the elliptical path of a object in a stable orbit.
This includes the paths of objects like the Moon and the International Space Station around the Earth, or the path of the Earth around the Sun.
More complex systems, such as Sun-Earth-Moon or the entire Solar System can be modelled as a composition of several two-body systems, rather than the _n_-body systems they really are. More complex systems, such as Sun-Earth-Moon or the entire Solar System can be modelled as a composition of several two-body systems, rather than the _n_-body systems they really are.
This conveniently sidesteps the requirement to use approximate forces and therefore accumulate error over time. This conveniently sidesteps the requirement to use approximate forces and therefore accumulate error over time.
The two body problem describes the motion of one body around another, or more precisely a common barycentre. The two body problem describes the motion of one body around another, or more precisely a common barycentre.
@ -36,8 +67,8 @@ Depending on the platform, target frame rates can vary from as low as 30Hz, for
This means most games have about 10ms to compute each frame. This means most games have about 10ms to compute each frame.
Processing limitations are of particular interest in games, which are severely constrained in the amount of processing they are able to complete in a single rendered frame. Processing limitations are of particular interest in games, which are severely constrained in the amount of processing they are able to complete in a single rendered frame.
In practice, each sub-system comprising a game has significantly less than 10ms, since it must use its budget conservatively to allow other sub-systems to use the same resources. In practice, the physics sub-system in a game may have significantly less than 10ms to work with, since other sub-systems could be competing for the same computational resources.
An astrodynamics physics simulation may be allowed only a single millisecond or less in which to calculate the paths of objects, due to constraints imposed by resourcing requirements of other sub-systems. An astrodynamics simulation may have a single millisecond or less in which to make its calculations.
Simulating physics to a high degree of accuracy with an iterative model requires high-resolution time steps. Simulating physics to a high degree of accuracy with an iterative model requires high-resolution time steps.
Interactive physics simulations will often run at many times the rendered framerate to maintain stability. Interactive physics simulations will often run at many times the rendered framerate to maintain stability.