I'm writing a "physics simulation" (so to speak) where using the keyboard arrows one applies forces to a sphere. In this latest iteration I added drag, like the sphere is in the air. Then, for certain values, the drag calculation starts to blow up! The number gets too big, and then Infinity and right after that NaN (cause of the Infinity / Infinity division).
You can see it happening here: http://gool.jit.su/the-drag. Open the console and start moving, left or right. In a few seconds it breaks. You can see in the console the drag value being logged until right before it becomes NaN. (we have a great force and a very small mass)
I'm really trying to understand what is happening and why it is happening, but perhaps there are already information on similar problemas that I was unable to find out or some sort of best practice to keep the number under control... Perhaps choose a value to be my MAX and test agains it every time...
Any idea, help and suggestion is very welcome. I think I am about to learn something important, but still needing a push in the right direction. :)
UPDATE 2: #Beta's test (sorta)
After #Beta's comment I did this test and indeed his calculations seems to show where my simulation breaks apart. (console log velocity in the x axis when the test returns true, false otherwise)
UPDATE 1: Some code
Most "physics" happen here:
update: function update(k, dt) {
var up = k.UP,
right = k.RIGHT,
down = k.DOWN,
left = k.LEFT;
up = up && -this.output;
right = right && this.output;
down = down && this.output;
left = left && -this.output;
this.force.x = left + right;
this.force.y = up + down;
this.calculate_drag(this.velocity);
if (!isNaN(this.drag.x)) {
console.log(this.drag);
}
// this.net_force.x = this.force.x;
// this.net_force.y = this.force.y;
this.net_force.x = this.force.x + this.drag.x;
this.net_force.y = this.force.y + this.drag.y;
this.acceleration.x = this.net_force.x / this.mass;
this.acceleration.y = this.net_force.y / this.mass;
this.velocity.x += this.acceleration.x / (1000 / dt);
this.velocity.y += this.acceleration.y / (1000 / dt);
this.momentum.x = this.mass * this.velocity.x;
this.momentum.y = this.mass * this.velocity.y;
this.position.x += (this.velocity.x * global.METRE) / (1000 / dt);
this.position.y += (this.velocity.y * global.METRE) / (1000 / dt);
this.energy += (abs(this.net_force.x) + abs(this.net_force.y)) / (1000 / dt);
}
And here:
calculate_drag: function calculate_drag() {
var c = 0.47,
a = PI * this.radius * this.radius,
rho = 1.22,
direction = function direction(velocity) {
if (velocity === 0) {
return 1;
}
return velocity / abs(velocity);
};
this.drag.x = -0.5 * c * a * rho * this.velocity.x * this.velocity.x * direction(this.velocity.x);
this.drag.y = -0.5 * c * a * rho * this.velocity.y * this.velocity.y * direction(this.velocity.y);
}
Both methods of gPrototype in gee.js.
You have a cycle in increasing the values of variables. The values will grow very fast. NaN may be the result of some float overflows.
net_force += drag;
drag = velocity * velocity;
velocity += net_force;
And so your "physics" are probably incorrect.
Related
I am seeking for some already done solution to simulate gravity interaction of n-body system, like our solar system for example, in any programming language (but preferably Javascript or C). I found this question, and it looks like exactly what I need, but, as I see, there's no interoperation between planets theyselves, only between sun and planets. I'm not so bad in JS, but really weak (more lazy) in geometry and gravity, so maybe somebody can give me an advice of how to enhance this code (or make the new one) to be able to simulate not the sun-to-planets, but full n-body gravity interaction? Or maybe you know such a software already written?
Cause as I understand, all I need is to change the code to calculate and display this:
//...
distanceTo: function(p2) {
var dx = p2.position.x - this.position.x,
dy = p2.position.y - this.position.y;
return Math.sqrt(dx ** 2 + dy ** 2);
},
attraction: function(p2) {
var dx = p2.position.x - this.position.x;
var dy = p2.position.y - this.position.y;
var d = Math.sqrt(dx ** 2 + dy ** 2);
this.f = G * (this.mass * p2.mass) / (d ** 2);
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;
}
//...
for every single body in the system, but I'm not sure is it the right way to just iterate this code over bodies, due to such an iteration will dynamically change bodies' positions, which have been used for previous calculations within the iteration. Hope I spell it clear.
Is this possible at all? Is not this related to Three-body problem exponential computation complexity increasing? If not, can you please just direct me to right formulas and spell out simply for me, what to write and how?
Thanks!
I am trying to make a client-server architecture. I am stuck at the interpolation part. Right now, I have a very naive implementation of the interpolation algorithm. I have every player given a position history and whenever I receive a position data for other player from the server I push the position in to that array. Every client frame I use the oldest position history to interpolate to a new position with a constant speed.
// when new position for other player recieved
p.stateHistory.push(data)
// Every client frame
if(p.stateHistory.length < 1)
return false
let deltaPosition = p.stateHistory[0].position.clone().sub(p.clientPosition)
let direction = Math.atan2(deltaPosition.y, deltaPosition.x)
let velocity = new Vector2(Math.cos(direction), Math.sin(direction)).scale(30/100)
let threshold = 10
if(deltaPosition.magnitude() < threshold) {
p.clientPosition.x = p.stateHistory[0].position.x
p.clientPosition.y = p.stateHistory[0].position.y
p.stateHistory.shift()
} else {
p.clientPosition.add(velocity.clone().scale(deltaTime))
}
I couldn't find way other to interpolate with a constant speed. I came to know about hermite interpolation from gafferongames. But it's sad that the article didn't have anything about its math and its implementation. I tried to go through the wikipedia article on hermite interpolation, but it didn't help. I know nothing about the math behind it. A pseudo code would be appreciated.
What I have been able to do so far: http://client-side-prediction-attempt.herokuapp.com/
Let's say say that your client receives a new position-velocity update at time currentTime. Then, you need to save the current position/velocity, the target position/velocity, the current time, and the time when you expect the next update:
function updateFromServer(position, velocity) {
startP = currentPosition; //the current position of the player
startV = currentVelocity;
endP = position;
endV = velocity;
startT = currentTime; //the current time of the game
endT = startT + 0.1; //expect the next update in 100 ms
}
Once you have stored this data, you can do your frame update using interpolation. If you are outside of the [startT, endT] interval, you might just want to continue a uniform motion:
function frameUpdate(deltaT) {
if(currentTime > endT)
//uniform motion
currentPosition += deltaT * currentVelocity;
else {
//cubic Hermite interpolation
var t = (currentTime - startT) / (endT - startT); //interpolation parameter
var t2 = t * t;
var t3 = t2 * t;
currentPosition =
(2 * t3 - 3 * t2 + 1) * startP +
(t3 - 2 * t2 + t) * (endT - startT) * startV +
(-2 * t3 + 3 * t2) * endP +
(t3 - t2) * (endT - startT) * endV;
currentVelocity = 1 / (endT - startT) * (
(6 * t2 - 6 * t) * startP +
(3 * t2 - 4 * t + 1) * (endT - startT) * startV +
(-6 * t2 + 6 * t) * endP +
(3 * t2 - 2 * t) * (endT - startT) * endV);
}
}
Note that the formulas in this snippet are not valid JavaScript code. They must be translated to whatever library you use.
I started a project using the raycasting technique GitHub Project
To find the length of the ray (distance from players pos to wall) I just increment by one. But there are several problems with that, its time consuming, inaccurate & will be difficult for texturing.
I tried to implement the daa algorithm, which doesnt just increments by 1 -> he goes through the grids and returns exact positions.
http://www.geeksforgeeks.org/dda-line-generation-algorithm-computer-graphics/
Has anyone experience with that or any tips?
No algorithm way:
for(let resolution = 0; resolution < display.width / 2; resolution++){ //every 2nd px gets scanned
let ray = this.pov + (-this.fov / 2 + this.fov / (display.width / 2) * resolution);
let distance = 0, hit = false;
/*ugly way of raycasting!*/
do{
let x = this.x + distance * Math.cos(ray * (Math.PI / 180));
let y = this.y + distance * Math.sin(ray * (Math.PI / 180));
if(map[Math.floor(x / block)][Math.floor(y / block)]){
distance = Math.sqrt(Math.pow(this.x - x, 2) + Math.pow(this.y - y, 2));
hit = true
}
distance += 1;
}while(!hit);
distance = convert / distance;
canvas.fillStyle = "#fff";
canvas.fillRect(resolution * 2, display.height / 2 - distance / 2, 2, distance);
}
You don't need DDA or Bresenham algorithm to find intersections of the ray with walls.
If you need one intersection with given border (or box edges) - just calculate it with ray equation and border position.
If you want to get intersections with grid cells - use voxelization algorithm like Amanatides-Woo
I was working on a fun project that implicates creating "imperfect" circles by drawing them with lines and animate their points to generate a pleasing effect.
The points should alternate between moving away and closer to the center of the circle, to illustrate:
I think I was able to accomplish that, the problem is when I try to render it in a canvas half the render jitters like crazy, you can see it in this demo.
You can see how it renders for me in this video. If you pay close attention the bottom right half of the render runs smoothly while the top left just..doesn't.
This is how I create the points:
for (var i = 0; i < q; i++) {
var a = toRad(aDiv * i);
var e = rand(this.e, 1);
var x = Math.cos(a) * (this.r * e) + this.x;
var y = Math.sin(a) * (this.r * e) + this.y;
this.points.push({
x: x,
y: y,
initX: x,
initY: y,
reverseX: false,
reverseY: false,
finalX: x + 5 * Math.cos(a),
finalY: y + 5 * Math.sin(a)
});
}
Each point in the imperfect circle is calculated using an angle and a random distance that it's not particularly relevant (it relies on a few parameters).
I think it's starts to mess up when I assign the final values (finalX,finalY), the animation is supposed to alternate between those and their initial values, but only half of the render accomplishes it.
Is the math wrong? Is the code wrong? Or is it just that my computer can't handle the rendering?
I can't figure it out, thanks in advance!
Is the math wrong? Is the code wrong? Or is it just that my computer can't handle the rendering?
I Think that your animation function has not care about the elapsed time. Simply the animation occurs very fast. The number of requestAnimationFrame callbacks is usually 60 times per second, So Happens just what is expected to happen.
I made some fixes in this fiddle. This animate function take care about timestamp. Also I made a gradient in the animation to alternate between their final and initial positions smoothly.
ImperfectCircle.prototype.animate = function (timestamp) {
var factor = 4;
var stepTime = 400;
for (var i = 0, l = this.points.length; i < l; i++) {
var point = this.points[i];
var direction = Math.floor(timestamp/stepTime)%2;
var stepProgress = timestamp % stepTime * 100 / stepTime;
stepProgress = (direction == 0 ? stepProgress: 100 -stepProgress);
point.x = point.initX + (Math.cos(point.angle) * stepProgress/100 * factor);
point.y = point.initY + (Math.sin(point.angle) * stepProgress/100 * factor);
}
}
Step by Step:
based on comments
// 1. Calculates the steps as int: Math.floor(timestamp/stepTime)
// 2. Modulo to know if even step or odd step: %2
var direction = Math.floor(timestamp/stepTime)%2;
// 1. Calculates the step progress: timestamp % stepTime
// 2. Convert it to a percentage: * 100 / stepTime
var stepProgress = timestamp % stepTime * 100 / stepTime;
// if odd invert the percentage.
stepProgress = (direction == 0 ? stepProgress: 100 -stepProgress);
// recompute position based on step percentage
// factor is for fine adjustment.
point.x = point.initX + (Math.cos(point.angle) * stepProgress/100 * factor);
point.y = point.initY + (Math.sin(point.angle) * stepProgress/100 * factor);
Preamble: there's an issue logged with the Google Maps API, requesting the ability to correct the roll angle of street view tiles to compensate for hills. I've come up with a client-side workaround involving some css sorcery on the tile container. Here's my rotate function:
rotate: function() {
var tilesLoaded = setInterval(function() {
var tiles = $('map-canvas').getElementsByTagName('img');
for (var i=0; i<tiles.length; i++) {
if (tiles[i].src.indexOf(maps.panorama.getPano()) > -1) {
if (typeof maps.panorama.getPhotographerPov != 'undefined') {
var pov = maps.panorama.getPhotographerPov(),
pitch = pov.pitch,
cameraHeading = pov.heading;
/**************************
// I need help with my logic here.
**************************/
var yaw = pov.heading - 90;
if (yaw < 0) yaw += 360;
var scale = ((Math.abs(maps.heading - yaw) / 90) - 1) * -1;
pitch = pov.pitch * scale;
tiles[i].parentNode.parentNode.style.transform = 'rotate(' + pitch + 'deg)';
clearInterval(tilesLoaded);
return;
}
}
}
}, 20);
}
A full (and more thoroughly commented) proof-of-concept is at this JSFiddle. Oddly, the horizon is just about perfectly level if I do no calculation at all on the example in the JSFiddle, but that result isn't consistent for every Lat/Lng. That's just a coincidence.
So, I need to calculate the roll at the client's heading, given the client heading, photographer's heading, and photographer's pitch. Assume the photographer is either facing uphill or downhill, and pov.pitch is superlative (at the min or max limit). How can I calculate the desired pitch facing the side at a certain degree?
Edit: I found an equation that seems to work pretty well. I updated the code and the fiddle. While it seems to be pretty close to the answer, my algorithm is linear. I believe the correct equation should be logarithmic, resulting in subtler adjustments closer to the camera heading and opposite, while to the camera's left and right adjustments are larger.
I found the answer I was looking for. The calculation involves spherical trigonometry, which I didn't even know existed before researching this issue. If anyone notices any problems, please comment. Or if you have a better solution than the one I found, feel free to add your answer and I'll probably accept it if it's more reliable or significantly more efficient than my own.
Anyway, if the tile canvas is a sphere, 0 pitch (horizon) is a plane, and camera pitch is another plane intersecting at the photographer, the two planes project a spherical lune onto the canvas. This lune can be used to calculate a spherical triangle where:
polar angle = Math.abs(camera pitch)
base = camera heading - client heading
one angle = 90° (for flat horizon)
With two angles and a side available, other properties of a spherical triangle can be calculated using the spherical law of sines. The entire triangle isn't needed -- only the side opposite the polar angle. Because this is math beyond my skills, I had to borrow the logic from this spherical triangle calculator. Special thanks to emfril!
The jsfiddle has been updated. My production roll getter has been updated as follows:
function $(what) { return document.getElementById(what); }
var maps = {
get roll() {
function acos(what) {
return (Math.abs(Math.abs(what) - 1) < 0.0000000001)
? Math.round(Math.acos(what)) : Math.acos(what);
}
function sin(what) { return Math.sin(what); }
function cos(what) { return Math.cos(what); }
function abs(what) { return Math.abs(what); }
function deg2rad(what) { return what * Math.PI / 180; }
function rad2deg(what) { return what * 180 / Math.PI; }
var roll=0;
if (typeof maps.panorama.getPhotographerPov() != 'undefined') {
var pov = maps.panorama.getPhotographerPov(),
clientHeading = maps.panorama.getPov().heading;
while (clientHeading < 0) clientHeading += 360;
while (clientHeading > 360) clientHeading -= 360;
// Spherical trigonometry method
a1 = deg2rad(abs(pov.pitch));
a2 = deg2rad(90);
yaw = deg2rad((pov.heading < 0 ? pov.heading + 360 : pov.heading) - clientHeading);
b1 = acos((cos(a1) * cos(a2)) + (sin(a1) * sin(a2) * cos(yaw)));
if (sin(a1) * sin(a2) * sin(b1) !== 0) {
roll = acos((cos(a1) - (cos(a2) * cos(b1))) / (sin(a2) * sin(b1)));
direction = pov.heading - clientHeading;
if (direction < 0) direction += 360;
if (pov.pitch < 0)
roll = (direction < 180) ? rad2deg(roll) * -1 : rad2deg(roll);
else
roll = (direction > 180) ? rad2deg(roll) * -1 : rad2deg(roll);
} else {
// Fall back to algebraic estimate to avoid divide-by-zero
var yaw = pov.heading - 90;
if (yaw < 0) yaw += 360;
var scale = ((abs(clientHeading - yaw) / 90) - 1) * -1;
roll = pov.pitch * scale;
if (abs(roll) > abs(pov.pitch)) {
var diff = (abs(roll) - abs(pov.pitch)) * 2;
roll = (roll < 0) ? roll + diff : roll - diff;
}
}
}
return roll;
}, // end maps.roll getter
// ... rest of maps object...
} // end maps{}
After rotating the panorama tile container, the container also needs to be expanded to hide the blank corners. I was originally using the 2D law of sines for this, but I found a more efficient shortcut. Thanks Mr. Tan!
function deg2rad(what) { return what * Math.PI / 180; }
function cos(what) { return Math.cos(deg2rad(what)); }
function sin(what) { return Math.sin(deg2rad(what)); }
var W = $('map-canvas').clientWidth,
H = $('map-canvas').clientHeight,
Rot = Math.abs(maps.originPitch);
// pixels per side
maps.growX = Math.round(((W * cos(Rot) + H * cos(90 - Rot)) - W) / 2);
maps.growY = Math.round(((W * sin(Rot) + H * sin(90 - Rot)) - H) / 2);
There will be no more edits to this answer, as I don't wish to have it converted to a community wiki answer yet. As updates occur to me, they will be applied to the fiddle.