Develop Reference

N-Body Gravity / Solar System Javascript Simulation

Good day, I am trying to create a simple 2D solar system model in javascript, but am having some trouble understanding how to go about calculating where planets will be for the next frame, aswell as a few other bits which I'll go into detail with soon.
After watching this very nice video and a whole bunch of his others, I made a quick MS paint image to try and simplify my situation.
With the second scene, you can see that the new position is calulated using the velocity, gravitational pull, and the angle between these two 'directions'?
I cannot get my head around how to figure this all out.
Below is a JS fiddle of my code. You'll notice I'm trying my best to use real NASA given data to keep it accurate.
You'll want to look specifically at lines 138 which is where all the calculations for its next move are made.
https://jsfiddle.net/c8eru7mk/9/
attraction: function(p2) {
// Distance to other body
var dx = p2.position.x - this.position.x;
var dy = p2.position.y - this.position.y;
var d = Math.sqrt(dx ** 2 + dy ** 2); // Possibly correct
// Force of attracrtion
this.f = G * (this.mass * p2.mass) / (d ** 2); // Possibly Correct
// Direction of force, If you read it hard enough you should be able to hear my screams of pain
// Not sure if this is correct, most likely not.
var theta = Math.atan2(dy, dx);
var fx = Math.cos(theta) * this.f;
var fy = Math.sin(theta) * this.f;
this.velocity.x += fx / this.mass;
this.velocity.y += fy / this.mass;
this.position.x += this.velocity.x;
this.position.y += this.velocity.y;
}
The problems I'm currently facing are
If I am to use NASA values, the distance between planets is so big, they won't fit on the screen, and I can't simply scale the distances down by multiplying them by 0.0002 or whatever, as that'll mess with the gravitational constant, and the simulation will be completely off.
I have no idea how to caluclate the next position and my brain has imploded several times this past week trying to attempt it several times.
I have no idea on how to check if my configuration data of planets is wrong, or if the simulation is wrong, so I'm pretty much just guessing.
This is also my first time actually coding anything more complex than a button in javascript too, so feedback on code layout and whatnot is welcome!
Many thanks

Using NASA values is not a problem when using separate coordinates for drawing. Using an appropriate linear transfomration from real coordinates to screen coordinatees for displaying does not influence the physical values and computations.
For simulating the motion of a planet with iterative updates one can assume that the gravitational force and the velocity are constant for a small portion of time dt. This factor dt is missing in your conversions from accelration to velocity and from velocity to distance. Choosing an appropriate value for dt may need some experiments. If the value is too big the approximation will be too far off from reality. If the value is too small you may not see any movement or rounding errors may influence the result.
For the beginning let us assume that the sun is always at (0,0). Also for a start let us ignore the forces between the planets. Then here are the necessary formulas for a first not too bad approximation:
scalar acceleration of a planet at position (x,y) by the gravitational force of the sun (with mass M): a = G*M/(d*d) where d=sqrt(x*x+y*y). Note that this is indepent of the planet's mass.
acceleration vector: ax = -a*x/d, ay = -a*y/d (the vector (-x,-y) is pointing towards the sun and must be brought the length a)
change of the planet's velocity (vx,vy): vx += ax*dt, vy += ay*dt
change of the planet's position: x += vx*dt, y += vy*dt

THREE .JS raycasting performance

I am trying to find the closest distance from a point to large, complex Mesh along a plane in a direction range:
for (var zDown in verticalDistances) {
var myIntersect = {};
for (var theta = Math.PI / 2 - 0.5; theta < Math.PI / 2 + 0.5; theta += 0.3) {
var rayDirection = new THREE.Vector3(
Math.cos(theta),
Math.sin(theta),
0
).transformDirection(object.matrixWorld);
// console.log(rayDirection);
_raycaster.set(verticalDistances[zDown].minFacePoint, rayDirection, 0, 50);
// console.time('raycast: ');
var intersect = _raycaster.intersectObject(planeBufferMesh);
// console.timeEnd('raycast: '); // this is huge!!! ~ 2,300 ms
// console.log(_raycaster);
// console.log(intersect);
if (intersect.length == 0) continue;
if ((!('distance' in myIntersect)) || myIntersect.distance > intersect[0].distance) {
myIntersect.distance = intersect[0].distance;
myIntersect.point = intersect[0].point.clone();
}
}
// do stuff
}
I get great results with mouse hover on the same surface but when performing this loop the raycasting is taking over 2 seconds per cast. The only thing i can think of is that the BackSide of the DoubleSide Material is a ton slower?
Also i notice as I space out my verticalDistances[zDown].minFacePoint to be farther apart raycast starts to speed up up (500ms /cast). So as the distance between verticalDistances[i].minFacePoint and verticalDistances[i+1].minFacePoint increases, the raycaster performs faster.
I would go the route of using octree but the mouse hover event works extremely well on the exact same planeBuffer. Is this a side of Material issue,. that could be solved by loading 2 FrontSide meshes pointing in opposite directions?
Thank You!!!!
EDIT: it is not a front back issue. I ran my raycast down the front and back side of the plane buffer geometry with the same spot result. Live example coming.
EDIT 2: working example here. Performance is little better than Original case but still too slow. I need to move the cylinder in real time. I can optimize a bit by finding certain things, but mouse hover is instant. When you look at the console time the first two(500ms) are the results i am getting for all results.
EDIT 3: added a mouse hover event, that performs the same as the other raycasters. I am not getting results in my working code that i get in this sample though. The results I get for all raycast are the same as i get for the first 1 or 2 in the sample around 500ms. If i could get it down to 200ms i can target the items i am looking for and do way less raycasting. I am completely open to suggestions on better methods. Is octree the way to go?
raycast: : 467.27001953125ms
raycast: : 443.830810546875ms
EDIT 4: #pailhead Here is my plan.
1. find closest grid vertex to point on the plane. I can do a scan of vertex in x/y direction then calculate the min distance.
2. once i have that closest vertex i know that my closest point has to be on a face containing that vertex. So i will find all faces with that vertex using the object.mesh.index.array and calculate the plane to point of each face. Seems like a ray cast should be a little bit smarter than a full scan when intersecting a mesh and at least cull points based on max distance? #WestLangley any suggestions?
EDIT 5:
#pailhead thank you for the help. Its appreciated. I have really simplified my example(<200 lines with tons more comments); Is raycaster checking every face? Much quicker to pick out the faces within the set raycasting range specified in the constructor and do a face to point calc. There is no way this should be looping over every face to raycast. I'm going to write my own PlaneBufferGeometry raycast function tonight, after taking a peak at the source code and checking octree. I would think if we have a range in the raycaster constructor, pull out plane buffer vertices within that range ignoring z. Then just raycast those or do a point to plane calculation. I guess i could just create a "mini" surface from that bounding circle and then raycast against it. But the fact that the max distance(manual uses "far") doesn't effect the speed of the raycaster makes me wonder how much it is optimized for planeBuffer geometries. FYI your 300k loop is ~3ms on jsfiddle.
EDIT 6: Looks like all meshes are treated the same in the raycast function. That means it wont smart hunt out the area for a plane Buffer Geometry. Looking at mesh.js lines 266 we loop over the entire index array. I guess for a regular mesh you dont know what faces are where because its a TIN, but a planeBuffer could really use a bounding box/sphere rule, because your x/y are known order positions and only the Z are unknown. Last edit, Answer will be next

FYI: for max speed, you could use math. There is no need to use ray casting. https://brilliant.org/wiki/3d-coordinate-geometry-equation-of-a-plane/

The biggest issue resolved is filtering out faces of planeBufferGeometry based on vertex index. With a planeBufferGeometry you can find a bounding sphere or rectangle that will give you the faces you need to check. they are ordered in x/y in the index array so that filters out many of the faces. I did an indexOf the bottom left position and lastIndexOf the top right corner position in the index array. RAYCASTING CHECKS EVERY FACE
I also gave up on finding the distance from each face of the object and instead used vertical path down the center of the object. This decreased the ray castings needed.
Lastly I did my own face walk through and used the traingle.closestPointToPoint() function on each face.
Ended up getting around 10ms per point to surface calculation(single raycast) and around 100 ms per object (10 vertical slices) to surface. I was seeing 2.5 seconds per raycast and 25+ seconds per object prior to optimization.

how does atan2 work? which angle is actually calculated?

As you can see in the picture, I have a line and two points(p1 and p4). what I need to do is to get snapped point of p1/p4 on the line and then use atan2 to calculate the angle between (p1 and p2) and (p3 and p4). Now, I have two formulas:
var anglep1p2 = Math.atan2(p2[1] - p1[1], p2[0] - p1[0]) * 180 / Math.PI;
var anglep4p3 = Math.atan2(p4[1] - p3[1], p4[0] - p3[0]) * 180 / Math.PI;
anglep1p2 is calculated 103.66797855556482
anglep4p3 is calculated -76.74971541138642
I wonder how does atan2 calculate those values?
thanks for any help

These answers do make sense. You are sort of calculating a the angle of a single line, starting from the positive x-axis. The way you calculate anglep1p2, it corresponds to the line drawn from p1 to p2.
If you plunk the origin of a coordinate system at the starting point p1 (you put it at p2 in your diagram), then the number you get should be the rotation from the positive x-axis to the line you drew - a bit over 90 degrees makes intuitive sense.
Your second result is flipped from your first (notice you used p4/p3 in the same order as your variable name, whereas you reversed this order in the p1/p2 case). To avoid confusion, I'd use the p1/p2 case to gain understanding, then apply it the same way to the other case once you know what you want.
If you have a specific geometry/relationship problem you need to figure out, you can provide the details and I might be able to help more specifically.

Find the better intersection of two moving objects

I would like to optimize dramaticaly one of my algorithm, i will try to explain it the best way that i can.
The subject
We are in a 2D euclidian system at the time t = 0.
In this system there is two object : O1 and O2.
O1 and O2 are respectively situated at the point PA and PC.
O1 moves at a constant and known speed in direction of the point PB. The object will stop when it reach PB.
O2 can move at a constant and known speed different or not of O1's in any direction. At the time 0, O2 has no direction, we will need to find one for it.
The knowns parameters:
O1 : Position, direction, speed
O2 : Position, speed
Here is a little diagram of the system.
We would like to find the point PI and the time ti for which : Position of O1 at the time ti = Position of O2 at the time ti = PI. Then we will make the object O2 move to the point PI to get the O2 direction.
When the direction of O2 (the point PI) is chosen and both objects O1 and O2 are on the move, the objects will never stop or wait for each other.
In this case, the result would be something like this (PI is noted D on this picture).
The algorithm
You can find the working algorithm written in JS at this jsfiddle, it is also a great way to understand the problem.
At this time i use a simple algorithm who works, but can take a lot of operations, i will get the best intersection time, and get the intersection position afterwards.
To get this time, i will check the position of O1 at a moment, and check if O2 could possibly go to this position at this time. If O2 could not reach the object in time, we will increase the time by 150%, however if O2 could cross the O1-B line at the time, we will decrease the time by 50%.
Eventually, after many approximations, we will find the perfect time where both objects could meet.
PseudoCode
function getOptimalIntersectionTime time
if distance between O1 and O2 at the time `time` < 1
return time
else if O2 could not reach the object O1 at the time `time`
return getOptimalIntersectionTime time * 1.5
else
return getOptimalIntersectionTime time * 0.5
Why am I concern ?
My algorithm works, but in some case (e.g. the "Reverse Case" in the jsFiddle) it will take a large amount of calculus to find the best point.
In this jsFiddle, we are using little values for position (-1000 to 1000) and speed (1-200) but this algorithm is dramaticaly slower with bigger numbers.
I know that premature optimization is a bad idea, but I'm at the end of the project (which consists on databases insertions / selection and data analysis, including this algorithm called many many times) and this algorithm take up to 80% of the project system ressources in certain cases so an improvement could really improve the stability and the responsiveness of the system.

Without loss of generality, let O2 be located at (0,0).
Let s and v the location and velocity vectors of O1, v2 the speed of O2, and t the time to intercept. We then have:
|s + v * t| = t * v2
By the definition of distance:
(sx + vx * t) ^ 2 + (sy + vy * t) ^ 2 = (t * v2) ^ 2
Multiplying this out and reordering terms gives:
sx^ 2 + 2 * sx * vx * t + vx^2 * t^2
+ sy^ 2 + 2 * sy * vy * t + vy^2 * t^2
- v2^2 * t^2
= 0
i.e.
sx^2 + sy^2 + (2 * sx * vx + 2 * sy * vy) * t + (vx^2 + vy^2 - v2^2) * t^2 = 0
\--- ---/ \------------ ----------/ \-------- ------/
\ / \ / \ /
c b a
As you can see, this a quadratic equation in t. We can simply apply the quadratic formula to find the two possible values for t (if the equation has no solution, that's because no interception is possible). You'll probably want to use the earliest future interception, i.e. the smaller t that is > 0.
Once you have computed the t, finding the interception point and from that the interception direction should be easy.
To summarize, this problem can be solved in constant time, no iteration is necessary.

You appear to be over-thinking the problem, it should just be simple geometry.
Leaving aside the problem of how you define the nearest point, let's solve for the situation where the desired point is midway between PA and PB.
We have to assume a time period for the entire cycle, let's call that T.
PI = (PB - PA) / 2; // simplified
TI = T / 2; // simplified
[decompose all formulae for the x and y coordinates separately].
There are relatively simple formulae for determining the closest intersection of a point (PC) with a line (PA -> PB), although how that's defined is complicated when that line isn't infinitely long.
Then you need:
V1 = (PB - PA) / T; // O1's velocity
V2 = (PI - PC) / T; // O2's velocity
These last two lines don't depend on the earlier assumptions - if you know the interception point then the velocity is simply the distance travelled divided by the time taken.
Hence unless you impose some additional constraints on V2, there is always a solution and it's calculated in a few trivial math operations.

Update: #Meriton's later answer is better than mine. I recommend trying his first.
As you realize, we have three, simultaneous equations in the three unknowns vx2, vy2 and t -- respectively the x and y velocities of 02, and time. The equations unfortunately are not all linear:
x1o + vx1*t == x2o + vx2*t
y1o + vy1*t == y2o + vy2*t
vx2*vx2 + vy2*vy2 == vy*vy
(Here, x1o, y1o, x2o and y2o are coordinates of the initial positions.)
If there is a way to linearize the problem, I don't see it. You can however solve iteratively, and quickly, by the same Newton-Raphson technique GPS uses to work out your position from satellite signals. Of course, to fill in the details and implement this will demand some work!
Update: I think that #Alnitak may have linearized your problem rather neatly. Perhaps a combination of his approach and mine therefore would prosper. (I still think that you'll want to use a Newton-Raphson iteration to converge on #Altinak's T.)

Since the speeds are fixed, this should be solvable using the idea of parallel navigation. Think of it this way. At time 0, there is a line between O1 and O2 (the LOS, or line of sight). If O2 follows the optimal intersect path, then at time 1, the line between O1 and O2 will be parallel to the time 0 LOS. Since you have O2's speed, you can calculate the distance it will travel between time 0 and time 1, and from that can calculate where that intersects the time 1 LOS. Think of scribing a circle around O2's original position with radius equal to the distance it will travel in that interval of time. The intersection(s) of that circle with the second LOS will contain the solution. If there is no intersect, there is no solution. The beginning of this online book has a diagram and formulas that show the concept:
http://www.crcnetbase.com/doi/abs/10.1201/9781420062281.ch2
This problem has real world applications where you may also find this solution talked about. For instance submarines can use this to plot and maintain an intercept course with their target by keeping the LOS bearing to their target constant as they close on their target.
Edit:
This diagram shows what I'm talking about. This can be solved using trigonometry except for the special case where the target O1 is moving directly towards or away from the missile O2 (which can be solved trivially).
In the diagram above we can take some arbitrary small amount of time. During that time t1, O1 will have traveled distance b, and O2 will have traveled distance f. The line between O1 and O2 at time t0 is parallel to the line between O1 and O2 at time t1. Since we are given the initial positions of O1 and O2 we know distance d, and since we are given O1's direction, we can simply calculate the angle A.
So given A, b, f, and d, using the law of Cosines,
a = sqrroot(c^2 + b^2 - (2cb * cos(A)))
and
B = arccos((a^2 + c^2 - b^2)/2ac)
Using the law of Sines
E = arcsin((a * sin(B))/f) or the ambiguous value of 180 - that value
and with that
BC = 180 - E (because C = 180 - B - E so C+B = 180 - E
with BC we have the solution, and the any other aspects of the triangle of the initial locations of O1 and O2 and the intersection point can be similarly calculated.
It's been many years since I used my high school trig, so there may be a simplification of this that I've missed, but this hopefully explains the solution approach I initially described.

Scripting a players position (moving a object around on the screen)

Im looking into a small javascript game and is currently making a tool for testing "sqeuences" (game scenes where i want the script to move the player around thru waypoints, gonna call it actionscenes :D).
I think I almost got it right, but as you can see if you copypaste the code to a html the logic is broken. I need help with the trigonometric calculations:
http://pastebin.com/TfGU85ru
Any helpful tips? :D
It uses JQuery.

Depending on the quadrant you will also have to rotate the values a and b in the degree calculation. If the quadrant rotates 90 degrees, a and b have to be exchanged.
Also why use
var a = Math.pow( waypoint_x-player_x, 2);
var b = Math.pow( waypoint_y-player_y, 2);
and not
var a = Math.abs( waypoint_x-player_x);
var b = Math.abs( waypoint_y-player_y);