Develop Reference

Why does my 1D gravity simulation not act like a pendulum?

My gravity simulation acts more like a gravity slingshot. Once the two bodies pass over each other, they accelerate far more than they decelerate on the other side. It's not balanced. It won't oscillate around an attractor.
How do other gravity simulators get around it? example: http://www.testtubegames.com/gravity.html, if you create 2 bodies they will just oscillate back and forth, not drifting any further apart than their original distance even though they move through each other as in my example.
That's how it should be. But in my case, as soon as they get close they just shoot away from each other to the edges of the imaginary galaxy never to come back for a gazillion years.
edit: Here is a video of the bug https://imgur.com/PhhRhP7
Here is a minimal test case to run in processing.
//Constants:
float v;
int unit = 1; //1 pixel = 1 meter
float x;
float y;
float alx;
float aly;
float g = 6.67408 * pow(10, -11) * sq(unit); //g constant
float m1 = (1 * pow(10, 15)); // attractor mass
float m2 = 1; //object mass
void setup() {
size (200,200);
a = 0;
v = 0;
x = width/2; // object x
y = 0; // object y
alx = width/2; //attractor x
aly = height/2; //attractor y
}
void draw() {
background(0);
getAcc();
applyAcc();
fill(0,255,0);
ellipse(x, y, 10, 10); //object
fill(255,0,0);
ellipse(alx, aly, 10, 10); //attractor
}
void applyAcc() {
a = getAcc();
v += a * (1/frameRate); //add acceleration to velocity
y += v * (1/frameRate); //add velocity to Y
a = 0;
}
float getAcc() {
float a = 0;
float d = dist(x, y, alx, aly); //distance to attractor
float gravity = (g * m1 * m2)/sq(d); //gforce
a += gravity/m2;
if (y > aly){
a *= -1;}
return a;
}

Your distance doesn't include width of the object, so the objects effectively occupy the same space at the same time.
The way to "cap gravity" as suggested above is add a normal force when the outer edges touch, if it's a physical simulation.

You should get into the habit of debugging your code. Which line of code is behaving differently from what you expected?
For example, if I were you I would start by printing out the value of gravity every time you calculate it:
float gravity = (g * m1 * m2)/sq(d); //gforce
println(gravity);
You'll notice that your gravity value skyrockets as your circles get closer to each other. And this makes sense, because you're dividing by sq(d). Ad d gets smaller, your gravity increases.
You could simply cap your gravity value so it doesn't go off the charts anymore:
float gravity = (g * m1 * m2)/sq(d);
if(gravity > 100){
gravity = 100;
}
Alternatively you could cap d so it never goes below a certain value, but the result is the same.
In the end you'll find that this is not going to be as easy as you expected. You're going to have to tune the parameters quite a bit so your simulation works how you want.

Working demo here: https://beta.observablehq.com/#shaunlebron/1d-gravity
I followed the solution posted by the author of the sim that inspired this question here:
-First off, shrinking the timestep is always helpful. My simulation runs, as a baseline, about 40 ‘steps’ per frame, and 30 frames per second.
-To deal with the exact issue you talk about, I think modeling the bodies not as pure point masses - but rather spherical masses with a certain radius will be vital. That prevents the force of gravity from diverging to infinity. So, for instance, if you drop an asteroid into a star in my simulation (with collisions turned off), the force of gravity will increase as the asteroid gets closer, up until it reaches the surface of the star, at which point the force will begin to decrease. And the moment it’s at the center of the star (or nearby), the force will be zero (or nearly zero) - instead of near-infinite.
In my demo, I just completed turned off gravity when two objects are close enough together. Seems to work well enough.

Physics based 2D movement: Changing direction of an object over time

I am currently creating a 2D space game in Java, in which you control a ship in, well, space.
The game does not use any external libraries.
The ship is supposed to move towards the cursor. However, when moving the cursor, the old force does not magically disappear; the ship changes its course, over time, to eventually move in the desired direction.
However, I have run into an issue regarding the movement of the ship.
Basically, what I want to achieve is crudely illustrated by this image:
The image shows how the ship is supposed to move during one game tick.
To explain further:
The Ship's max speed is illustrated by the circle.
The Target Angle is where the cursor currently is.
The Current Angle is the direction that the ship is currently traveling.
The Current Angle should move closer and closer to the Target Angle until it reaches the point where these two angles are the same.
The ship should change direction toward the target angle taking the shortest route possible; it can turn both left and right, not just left or right.
Now I've explained what I want to achieve, now I will instead describe what I so far have achieved and how it works.
Basically, the "ship" is an image sitting in the center of the screen. When you "move" the ship, the ship stays put; what moves is the rest of the play area.
The current "position" of the ship relative to the coordinate system that represents the play area are the integers xPos and yPos.
Now for some sample code that shows how the system works:
int xPos;
int yPos;
public void updateMovement() {
xPos += xSpeed;
yPos += ySpeed;
}
public void moveForward() {
double yTempSpeed = ySpeed;
double xTempSpeed = xSpeed;
yTempSpeed += 0.01 * Math.sin(Math.toRadians(targetAngle));
xTempSpeed += 0.01 * Math.cos(Math.toRadians(targetAngle));
double resultVector = Math.sqrt(xTempSpeed * xTempSpeed + yTempSpeed * yTempSpeed);
if (resultVector < 2) {
ySpeed += 0.01 * Math.sin(Math.toRadians(targetAngle));
xSpeed += 0.01 * Math.cos(Math.toRadians(targetAngle));
}
This code successfully sets the Ship's max speed to the desired value, however, this does not work (the ships' course does not change) in the event where the resulting "vector" is larger than 2, i.e. when the speed is already at it's maximum and the targetAngle is too close to the angle which the ship is currently traveling (+- Pi / 2).
How would I go about changing the current angle based on this implementation?

public void moveForward() {
ySpeed += 0.01 * Math.sin(Math.toRadians(targetAngle));
xSpeed += 0.01 * Math.cos(Math.toRadians(targetAngle));
double currentSpeed = Math.sqrt(xTempSpeed * xTempSpeed + yTempSpeed * yTempSpeed);
if (currentSpeed > maxSpeed) {
//the resulting speed is allways <= maxspeed (normed to that)
ySpeed *= maxSpeed/currentSpeed;
xSpeed *= maxSpeed/currentSpeed;
}
hope this is what you needed... although it is quite unrealistic, that a spacecraft has a maximum Speed, but in terms of "playability" i would do the same.

What about normalizing speed of the ship, not to let it actually exceed your speed limit (=2):
//it's good to put all constants out of a function in one place
//to make it easier if you ever wanted to change it
private final int MAX_SPEED = 2;
private final double ACCEL_FACTOR = 0.01;
public void moveForward() {
ySpeed += ACCEL_FACTOR * Math.sin(Math.toRadians(targetAngle));
xSpeed += ACCEL_FACTOR * Math.cos(Math.toRadians(targetAngle));
//normalize ship speed, i.e. preserve ratio of xSpeed/ySpeed
//but make sure that xSpeed^2 + ySpeed^2 <= MAX_SPEED^2
//your code goes here
//...
}
Read about vector normalization. This way, the changes of ship speed will be applied normally (at this moment speed can be >= MAX_SPEED), but after normalization it will never get greater than MAX_SPEED, so your if instruction is not even needed.

You may find the following (Swift) code useful, although you would need to handle the per-frame integration of the ship's linear and angular velocities yourself:
func moveShipTowards(location: CGPoint) {
if let ship = shipNode? {
let distanceVector = CGVector(origin: ship.position, point: location)
let targetAngle = distanceVector.angle
let shipAngle = ship.zRotation
var dø = targetAngle - shipAngle
// convert to shortest arc
if dø > π {
dø -= 2.0 * π
} else if dø < -π {
dø += 2.0 * π
}
// resulting angular velocity
ship.physicsBody.angularVelocity = 12 * dø.clampedTo(π)
var velocityUnitVector = CGVector(cosf(ship.zRotation), sinf(ship.zRotation))
var magnitude = distanceVector.length.clampedTo(400)
ship.physicsBody.velocity = velocityUnitVector * magnitude
}
}
It handles having the ship deccelerate as the target point is approached. Looking at it just now, it doesn't appear to handle acceleration properly though.

A* algorithm that takes account velocity

I'm developing a racing game like http://harmmade.com/vectorracer/ and I have implemented the A* algorithm to use for the AI players. The algorithm is working fine for 1-tile movements, but I don't want the AI players to only move 1 tile at a time (by using only their adjacent points), I need them to be able to accelerate and decelerate when they are closing in on a turn. Their next positions should depend on their previous one, just like Vector Racer.
public boolean createRoute() {
// The list where the points will be added in reverse order (from finish_point)
ArrayList<Track_Point> path = new ArrayList<>();
// The list where the unchecked points will be stored
ArrayList<Track_Point> open = new ArrayList<>();
// The list where the checked points will be stored
ArrayList<Track_Point> closed = new ArrayList<>();
// The starting point is always added as the first point to be checked
open.add(starting_point);
Track_Point current;
while (true) {
current = null;
// If all points from the open list have been removed (be being checked), it means that there isn't a possible path from the starting to the finish point
if (open.isEmpty()) {
System.out.println("no route available");
return false;
}
// Selects the point with the lowest F value from the open list
for (Track_Point temp : open) {
temp.show();
if (current == null || temp.getF() < current.getF()) {
current = temp;
}
}
// If the current point has reached the finish point, break the loop to construct the path
if (current.equals(finish_point)) {
break;
}
// Removes the current point (with the lowest F value) from the open list
open.remove(current);
// Adds the current point (with the lowest F value) to the closed list
closed.add(current);
ArrayList<Track_Point> possible_points = createNextPossibleTrackPoints(current);
//Sets the parent of the possible points
for (Track_Point tp : possible_points) {
if (!tp.equals(current)) {
tp.setParent(current);
}
}
for (Track_Point possible_point : possible_points) {
double nextG = current.getG() + current.distance(possible_point);
if (nextG < possible_point.getG()) {
open.remove(possible_point);
closed.remove(possible_point);
}
if (!open.contains(possible_point) && !closed.contains(possible_point)) {
possible_point.setParent(current);
open.add(possible_point);
}
}
}
//Track_Point current = finish_point;
while (current.getParent() != null) {
path.add(current);
current = current.getParent();
}
// optimalRacingLine is the list where all the points will be held in the correct order
optimalRacingLine.add(starting_point);
for (int k = path.size() - 1; k >= 0; k--) {
optimalRacingLine.add(path.get(k));
}
return true;
}
createPossiblePoints(Point current) so far returns a list of the current point's adjacents.
Each point's H value is calculated in their constructor, as I'm passing the finish point there and it calculates the distance between them.
Each point's G value is calculated when I set a parent to it, the G value is the distance from the new point to their parent + the parent's G value.
How do I modify this code to allow acceleration/deceleration?
The code of Track_Point:
package model;
import javafx.geometry.Point2D;
public class Track_Point extends Point2D {
private Track_Point parent, velocity;
private double f, g, h;
public Track_Point(double x, double y) {
super(x, y);
}
public Track_Point(double x, double y, Track_Point f) { // f is the finish point
super(x, y);
h = distance(f);
}
public void setParent(Track_Point tp) {
parent = tp;
g = distance(tp) + tp.getG();
f = g + h;
velocity = new Track_Point(getX() - parent.getX(), getY() - parent.getY());
}
public Track_Point getParent() {
return parent;
}
public double getG() {
return g;
}
public double getH() {
return h;
}
public double getF() {
return f;
}
public Track_Point getVelocity() {
return velocity;
}
#Override
public String toString() {
return "( " + (int) getX() + " , " + (int) getY() + " )";
}
public void show() {
System.out.println(toString());
}
}
Added some screenshots of my failed attempt and the working simple A* version
http://tinypic.com/r/zlakg2/8 - working version
http://tinypic.com/r/2e3u07o/8 - modified version (uses velocity as a parameter in the createNextPossiblePoints method)

Firstly, don't use an integers for the x/y position. There should be no such thing as '1 tile' in a racing game. Your game world and output can be completely different. For example, consider using doubles to store x and y. Ssh, don't worry, your JFrame doesn't need to know.
Heuristics
You are using A* to run your AI? Consider these additional heuristics:
Prefer high velocities; cost = max velocity - current velocity
Stay near inside edge of turn (imagine the turn as the outside edge of a circle); cost = distance_from(focus of turn)
Avoid walls; cost = isMovable(x, y) ? 0 : infinite/high
EDIT Prefer shortest path to avoid taking unnecessary moves as your second image does (Breadth First search not Djikstra); cost = steps from first node
The way A* works is as follows:
Use Djikstra (distance from origin) + Greedy (distance to target)
Insert your heuristics here
Add them all together and choose the lowest number
There's no such thing as f, g, or h; it's just mathematical nonsense you don't need to know.
Velocity
velocity = Math.abs(position1 - position2); so... position1 + velocity = position2.
You'll need to add the following variables:
int xVelocity
int yVelocity
Each moment, x += xVelocity; y += yVelocity.
The next position will be xf = x + xVelocity; yf = y + yVelocity. Then, you draw a ring around that position as follows:
+yVelocity
\|/
-xVelocity -0- +xVelocity
/|\
-yVelocity
So the center retains the same velocity, any adjacent side changes one velocity, and any diagonal side changes both velocities.
As for using A* the solution space of a turn is small enough that you can brute force it; don't add TrackPoints to the open list if you bump into a wall and prefer the highest velocity.
Really, that's all there is to it; simple stuff, but it can be tedious and difficult the first few times you need to do it.
EDIT: Just played vector racer and it's actually a lot simpler than I expected. I thought you were making a full blown 2d racing game. What I've told you is still very applicable, but you'll need to make a few adjustments, particularly to the way you handle rotation. You'll definitely want to look up the racing line. I don't have the time at the moment to go over the mathematics of the racing line, but this should help you calculate it.
EDIT2: Updated Velocity section. I'll do some calculations to figure out a faster heuristic, but what is present is enough to check 3-10 moves ahead without major performance issues.

How can I make a method repeat itself? Java

I have a method that fills an array and I need to find a way to make it repeat a number of times. The purpose is to iterate and reiterate the density of a planet to narrow its mass,gravity and densities at specific points which are concentric shells. This is my first program but, I have learned a decent amount while working on this I think. Thanks everyone
Here is my code sample of the density calculation. I probably included too much but oh well. So I need to make this iterate selected number of times. Each iteration needs to be put back into the mass calculation which will then be put back into the gravity calculation. And then the show starts again.
public class ItrDensityGrid {
public double itrrho[];
double b = InitialConditions.bmod;
// Iterating grid of densities
public ItrDensityGrid(int shells, double radius, double mass){
GravityGrid gg = new GravityGrid(shells, radius, mass);
for(int k = shells; k >= 0; k--){
itrrho[k] = (itrrho[k]*(1+(gg.alpha[k]*(1.0 / 2)))*(1 / (1-((gg.alpha[k])*(1.0 / 2)))));
}
}
}

This can be achieved with the help of Recursion, or looping.
In recursion, you call the method again from inside of the method itself. Make sure to call (or return) conditionally, otherwise, it may lead to infinite loop!
Here is an example with recursion:
public planetMars (double density, double mass) {
// do your calculations
density = density / 10.05312;
mass = mass / 7.2378;
myArray[] = density; // or whatever you want
// if calculations have not narrowed enough, call recursively
if ( density > 5.2)
planetMars (density, mass);
}
alternatively, with loop, you may do something like:
public planetMars (double density, double mass) {
// loop unless the calculation is not cool
while ( density > 5.2) {
// do your calculations
density = density / 10.05312;
mass = mass / 7.2378;
myArray[] = density; // or whatever you want
}
}

you could make a function which checks if the tolerances of your calculations are already good enough, here is some "pseudocode"
while(toleranceIsGood(planet) == false)
{
planet = calculatePlanet(planet);
}
planet would be the array. of course you can implement things like Endless loop detection etc

Minimising cumulative floating point arithmetic error

I have a 2D convex polygon in 3D space and a function to measure the area of the polygon.
public double area() {
if (vertices.size() >= 3) {
double area = 0;
Vector3 origin = vertices.get(0);
Vector3 prev = vertices.get(1).clone();
prev.sub(origin);
for (int i = 2; i < vertices.size(); i++) {
Vector3 current = vertices.get(i).clone();
current.sub(origin);
Vector3 cross = prev.cross(current);
area += cross.magnitude();
prev = current;
}
area /= 2;
return area;
} else {
return 0;
}
}
To test that this method works at all orientations of the polygon I had my program rotate it a little bit each iteration and calculate the area. Like so...
Face f = poly.getFaces().get(0);
for (int i = 0; i < f.size(); i++) {
Vector3 v = f.getVertex(i);
v.rotate(0.1f, 0.2f, 0.3f);
}
if (blah % 1000 == 0)
System.out.println(blah + ":\t" + f.area());
My method seems correct when testing with a 20x20 square. However the rotate method (a method in the Vector3 class) seems to introduce some error into the position of each vertex in the polygon, which affects the area calculation. Here is the Vector3.rotate() method
public void rotate(double xAngle, double yAngle, double zAngle) {
double oldY = y;
double oldZ = z;
y = oldY * Math.cos(xAngle) - oldZ * Math.sin(xAngle);
z = oldY * Math.sin(xAngle) + oldZ * Math.cos(xAngle);
oldZ = z;
double oldX = x;
z = oldZ * Math.cos(yAngle) - oldX * Math.sin(yAngle);
x = oldZ * Math.sin(yAngle) + oldX * Math.cos(yAngle);
oldX = x;
oldY = y;
x = oldX * Math.cos(zAngle) - oldY * Math.sin(zAngle);
y = oldX * Math.sin(zAngle) + oldY * Math.cos(zAngle);
}
Here is the output for my program in the format "iteration: area":
0: 400.0
1000: 399.9999999999981
2000: 399.99999999999744
3000: 399.9999999999959
4000: 399.9999999999924
5000: 399.9999999999912
6000: 399.99999999999187
7000: 399.9999999999892
8000: 399.9999999999868
9000: 399.99999999998664
10000: 399.99999999998386
11000: 399.99999999998283
12000: 399.99999999998215
13000: 399.9999999999805
14000: 399.99999999998016
15000: 399.99999999997897
16000: 399.9999999999782
17000: 399.99999999997715
18000: 399.99999999997726
19000: 399.9999999999769
20000: 399.99999999997584
Since this is intended to eventually be for a physics engine I would like to know how I can minimise the cumulative error since the Vector3.rotate() method will be used on a very regular basis.
Thanks!
A couple of odd notes:
The error is proportional to the amount rotated. ie. bigger rotation per iteration -> bigger error per iteration.
There is more error when passing doubles to the rotate function than when passing it floats.

You'll always have some cumulative error with repeated floating point trig operations — that's just how they work. To deal with it, you basically have two options:
Just ignore it. Note that, in your example, after 20,000 iterations(!) the area is still accurate down to 13 decimal places. That's not bad, considering that doubles can only store about 16 decimal places to begin with.
Indeed, plotting your graph, the area of your square seems to be going down more or less linearly:
This makes sense, assuming that the effective determinant of your approximate rotation matrix is about 1 − 3.417825 × 10-18, which is well within normal double precision floating point error range of one. If that's the case, the area of your square would continue a very slow exponential decay towards zero, such that you'd need about two billion (2 × 109) 7.3 × 1014 iterations to get the area down to 399. Assuming 100 iterations per second, that's about seven and a half months 230 thousand years.
Edit: When I first calculated how long it would take for the area to reach 399, it seems I made a mistake and somehow managed to overestimate the decay rate by a factor of about 400,000(!). I've corrected the mistake above.
If you still feel you don't want any cumulative error, the answer is simple: don't iterate floating point rotations. Instead, have your object store its current orientation in a member variable, and use that information to always rotate the object from its original orientation to its current one.
This is simple in 2D, since you just have to store an angle. In 3D, I'd suggest storing either a quaternion or a matrix, and occasionally rescaling it so that its norm / determinant stays approximately one (and, if you're using a matrix to represent the orientation of a rigid body, that it remains approximately orthogonal).
Of course, this approach won't eliminate cumulative error in the orientation of the object, but the rescaling does ensure that the volume, area and/or shape of the object won't be affected.

You say there is cumulative error but I don't believe there is (note how your output desn't always go down) and the rest of the error is just due to rounding and loss of precision in a float.
I did work on a 2d physics engine in university (in java) and found double to be more precise (of course it is see oracles datatype sizes
In short you will never get rid of this behaviour you just have to accept the limitations of precision
EDIT:
Now I look at your .area function there is possibly some cumulative due to
+= cross.magnitude
but I have to say that whole function looks a bit odd. Why does it need to know the previous vertices to calculate the current area?