# Understanding constant acceleration in terms of game physics simulation

There are various integration methods that can be used for games. I am trying to write a simple physics engine deciding between semi-implicit Euler and Verlet variants.

What I don't understand is where most information says that they work well for constant acceleration. Say more than one force acts on a body, and acceleration is calculated using force/mass. Velocity and position are derived from this. This means that the acceleration is not constant surely?

Am I incorrect in my understanding that applying a force in one step, and a different force at another step, is variable acceleration? Is it simply that the error amount is small enough to be ignored. So semi-implicit Euler, with fixed time-step but variable acceleration, for example, will be a good approximation?

I'm very confused, I've read so many different things. I'd appreciate any insights. Thanks!

• I think constant acceleration here means constant during a single time step, but the acceleration can change between time-steps. – Ken Apr 17 '19 at 7:11

In your context, I think constant acceleration refers to acceleration's like Earth's gravity. This is lengthy because you are not specific about how you are using the model. Are you trying to simulate gravity, space travel, bullet riccochet, etc?? I'm kind of a math-nerd and would be happy to reply with more specific detail if you are more specific about your application. I chose gravity for my explanation because I'm also a space-nerd, but understand that everything below is generally applicable to all forms of physics interaction.

In general, unless acted upon by an additional force, any two objects will accelerate toward each other, in proportion to their masses. Since most objects' masses are trivial compared to a planet, the impact of the object on the planet itself is usually ignored. Since the mass of planets does not frequently vary, acceleration due to gravity is considered a "constant".

Integration for motion of an object:

Velocity += (Acceleration * elapsedSeconds);
Position += (Velocity * elapsedSeconds);


To model a stationary object free-falling to Earth from any starting distance:

Acceleration = (0, -1, 0) * 9.8f; //Earth's "constant" gravity at sea level


When Position.y falls below 0, the object has landed. The position is at or below the surface and may need to be corrected to the actual ground height. While correcting the location, you need to do something with the remaining velocity at the time of impact. You can just discard it by setting Velocity to 0 or, using the objects' mass and velocity, calculate the specifics of the impact and apply the resulting accelerations to the objects for the next Update().

# Short term

In terms of precision/error, you will have no problem drawing something believable and glitch-free on the screen. If you need even more precision, you can store and transform your vectors using double-precision, and casting the resulting (more precise) vector to a regular Vector3 only when you actually need to feed it to DirectX.

# Long term

Even with a custom DVector3 (Double-precision Vector3) structure, if you digitize an epoch and then run any significant amount of time, eventually divergence manifests and your model becomes incorrect. This actually happens in real life, as well; each epoch defined and used as a basis for measurement, (with our current level of technology) ALWAYS has an expiration date for the very reason you are facing.

Velocity += (Acceleration * elapsedSeconds);


When you do this, you are summarizing all of the billions of billions of interactions that happened within elapsedSeconds to a single "most-significant" value.

# For orbital motion

Acceleration = PullFromSun;      //=
Acceleration += PullFromMoon;    //+=
Acceleration += PullFromMercury; //+=
...
Velocity += (Acceleration * elapsedSeconds);
Position += (Velocity * elapsedSeconds);


# For bullet travel

When first fired,

Velocity = {arbitrary bullet speed vector};
Acceleration = Gravity;  //bullet drop


Then,

Velocity += (Acceleration * elapsedSeconds);
Position += (Velocity * elapsedSeconds);


until colliding with an object (including the terrain) and/or a new position is calculated that is out-of-bounds/off-the-screen/out-of-range.

# Multiple interactions

This is as difficult as you want. You could integrate all colliding objects' Accelerations until the collision is mathematically complete and the system comes to rest with all objects having Acceleration equal to Gravity and Velocity equal to 0. This is what the universe does.

Instead, just summarize (with as much complexity as you require) the entire collision at the time that it occurs. Minimally, an object that hits another object should impart a portion of its Velocity to the object(s) that were hit.

Velocity += (CollidingObjectsMass * CollidingObjectsVelocity) / (Mass + CollidingObjectsMass)


# Summarizing interactions

This will provide realistic results for most mass-dependent transfers (collisions):

AnyFactor += (InteractingObjectsMass * InteractingObjectsAnyFactor) / (Mass + InteractingObjectsMass)


When that isn't good enough, the inverse-square law is probably more relevant. To model the gravitational force the Sun(Object2) exerts on the Earth(Object1):

Direction = Object2Location - Object1Location;
Magnitude = GravitationalConstant * (Object1Mass * Object2Mass) / (Direction.Length ^ 2);


When calculating the first (or only) object, use '='. This is the same as the free-falling-object calculation above with Direction pointing to Earth's center and Magnitude being explicitly specified as 9.8.

Acceleration = Normalize(Direction) * Magnitude;


Because the Sun is soooooo far away, its pull on an object on earth at sea level, is negligible, compared to that of the Earth, itself, so in earth-gravity-only models, it is ignored. If you wanted to model the solar system, though, for each object after the first, use '+='

Acceleration += Normalize(Direction) * Magnitude;


Then, the usual

Velocity += (Acceleration * elapsedSeconds);
Position += (Velocity * elapsedSeconds);


To accurately model just Earth's trajectory, you would need to digitize the entire universe and be able to time-integrate the entire thing, precisely. Instead, when simulating the universe, it is divided into compartments called barycenters. Our solar system is usually thought to be centered on the sun. Although effectively true, that is technically false. If you averaged the mass, density, location, velocity, and every other property of everything within our solar system into a single mass, it's location would be near the surface of the sun, not at its' center. An hour later, the barycenter's center has moved.

# Barycenter's are as infinitely-scalable as the universe is deep

Consider that the earth is composed of many different materials with many different properties, but all of those materials move and rotate around a common center point, a barycenter by definition. We are affected by every individual particle that comprises the earth, separately, yet we refer to Earth, mathematically, as a single entity with a single, constant gravity value. That's because, over time and, on average, all of Earth's properties continually produce a "constant" amount of gravity at sea level. We average particles into planets, planets into solar systems, solar systems into galaxies, etc, etc.

If you calculate the barycenter for our solar system but leave Earth out of the calculations, you can accurately model Earth's orbit with one calculation.

EarthsVelocity += (AccelerationCausedBySolarSystemWithoutEarth * elapsedSeconds);


The problem is that your model will not remain technically accurate unless you recalculate the barycenter each frame, defeating the time saved by using them. Recalculating everything every time would produce truely variable acceleration.

If you forego technical accuracy right off the bat, it's trivial to recalculate the Earth-less barycenter using time-integrated distance and Euler angles for everything, every frame. Interacting the Earth with the resulting barycenter will produce an accurate, albeit made-up, gravity-based, orbit. Using Euler's prevents a lot of error from accumulating in the solar system, itself, while allowing the Earth to actually traverse it based on "real gravity". All of which can be used to produce cyclical weather, temperature, etc. patterns.

• I don't see how does this answer the question. Suppose there is a drag along with gravity. Then acceleration is not constant. – Yola Aug 18 '18 at 12:34

Notice how accelleration is just assigned every frame independantly. Thats as good as saying the physics engine doesnt bother with accelleration as a kept register, its just the bin you apply the forces to.