Normal RNGs only allow you to run forward in the sequence (cause that normally all you’d want to do). These let you run in either direction.
Yea, like if you are on a train and throw a ball with 50J of KE (10m/s) why does the guy at the station think you added 10m/s to 100m/s for a grand total of 110m/s there by adding over 2kJ of KE?
Okay, but I don´t think I need to be able to reverse it… xd
Still kind of unsure what you mean… =P Yes, a ship can shoot a projectile which from the point of view of the ship has a low amount of kinetic energy but which might have high kinetic energy from another view (just like your train and station example). Everything will use the same frame of reference, namely the sun (which “stands still”).
It does not matter what the frame of reference is. The rules are the same… Really i was asking to more or less derail the thread into a physics discussion.
Spot the really cool guy who loves physics! 
Lets start with a train traveling at 100m/s. In one carriage a dude (or dudette) throws a 1kg ball at 10m/s. He/She calculates that the ball has 50J of Kinetic energy. Thus they spent 50J of energy throwing the ball. However at the station dude B who sees that the ball is accelerated from 100 to almost* 110m/s which gives .5*m(110^2-100^)=1050J, wow that one heck of an arm you got there. In fact since you know the max energy from an arm is 50J it looks like you have got some free energy!
However dude B has forgot something. Conservation of momentum. If we are in the train frame, momentum is not conserved since it is transferred to the train, ie we are pushing on a infinite sized mass. Note this is not a inertial frame of reference.
So now we need to add an assumption. The train is in zero acceleration mode on a perfectly flat surface. ie thrust perfectly balances drag. When someone throws a ball forward they push back on the train. Momentum is conserved and the train will slow down just a little. Lets assume that the ball is throw at 110m/s in the stationary frame (it is really slightly slower). That is an extra 10kg m/s of momentum. The train weights 100T so to gain the opposite amount of momentum it needs to slow down by .0001 m/s with a reduction in KE of 1000J (within 6sf). And we just found the missing KE!
Note that the real speed of the ball is 110-.0001, but that is close enough since its only 1kg.
Being able to change the frame of reference is really important for many calculations as it will make them much easier and more accurate. Almost certainly using the suns frame of reference is a bad idea. NASA simulations switch between the local planets frame to the sun once the spacecraft is far enough away. Typically defined as the distance where both bodies give the same gravitational pull.
Okay, I get the energy part, but what frame of reference(s) am I supposed to use for something simulating the solar system, or even a very small part of the galaxy? Let´s assume that all stars are static and unmovable and that all large natural satellites (therefore excluding small asteroids, debris, e.t.c) is not affected by smaller bodies. In what case would switching the frame of references improve any calculations? This is the first time I´ve heard about using multiple frames of references, so you have my permission to derail the thread to your liking. I also find mechanical physics really interesting. =D
Well the problem with space is that it is really really big. You may think its a long way down the road to store, but that is peanuts compared to space. For example from earth surface to the moon is about 400000km, while from earth to the sun is about 150000000 km! So even though there are many things affecting everything, most of the time only one thing is the important one.
Generally in physics we choose whatever frame of reference that makes the math easy. Or more accurate. In orbital mechanics there are a number of simplifications that can add a lot of accuracy.
The basic simplification is to assume the mass of the primary body is much larger than anything else. This means it does not move and is not affected by the other bodies. This is true for say a spaceship and earth, but not for the earth moon system. But you could still use this approximation. It would be accurate enough for a game. But not for real astronavigation. Using this approximation the obvious coordinate frame is earth centered and you can even get analytical formula for the orbits. Then adding perturbations say from the moon, and then the sun. You don’t need to change the frame of reference since the strongest forces are still earth centered.
However if our space ship now starts traveling to mars, once its a fair distance from earth we are better off using a sun centered coordinate system. Again now the largest force in centered and this helps reduce round off errors. Finally once we get close to mars, we can switch to a mars centered coordinate system.
You get the idea. Basically it is about “framing” the problem in a way that makes it easier to solve. For some value of easier.
Forgot to add that if you are doing a galactic simulation i would galaxy centered coordinates, almost all the mass is in the center. But you can’t then also simulate solar systems on each star without some difficulty. For a solar system sun centered works well enough for many things, but don’t forget that say Jupiter moons will have issues if you don’t deal with numerical errors.
…and when you’re traveling through a nebula cloud, you fudge it. ;D
For somebody who loves physics, you ought to write your units right… ‘ms’ is milliseconds, ‘m/s’ is meters per second. :point:
Call me simple, but until I realized that ‘the respected physics guy’ used incorrect units, I had no clue what you were trying to say and how to calculate anything with the provided numbers.
Well typos and bad spelling go hand in hand with physics…
Except that in nearly all your post you write ‘ms’, so well, it’s a… consistent typo. I’ll give you that.
I wish my old teachers were that lenient
I typically am lenient if its clear what the units are and its clearly a typo except for mock exams (mark does not count). Don’t get me wrong… it was wrong and unlike gramma ****s its something that should be pointed out since it can/does change the meaning. But also i want to write ms^{-1}
Think i fixed all my posts now.
FWIW i said i love physics. That is not really the same as good at it 
these days its not really my day job anymore.
I know how big space is. >_> Like I said I have (had T_T) a simulation running with a few planets placed at their correct distances from the sun + their moons.
Numerical accuracy isn´t going to be good enough even with 64-bit floating point variables, so I plan on using fixed point ints/longs evenly distributed over the simulation area plus floats/doubles for positions relative to the fixed points to get the same numerical accuracy everywhere. I would also use them for velocity. Would that eliminate the need for changing the frame of reference per object? I´m afraid that the numerical accuracy of even doubles will be too low to handle collisions in some cases. For example it´s possible to put something in orbit around the sun (not a planet). That could mean problems if for example two objects collide while in orbits around the sun in the outer parts of the solar system (same distance as Pluto? xd), right? Since the sun is the body with the biggest gravitational pull on the objects they woud use the sun as frame of reference, which is insanely far away. Another problem that fixed precision solves is rendering things with OpenGL. With only 32-bit floats and matrix multiplications things at the same distance as the Earth from the sun cannot be rendered accurately. I think fixed precision for velocity also improves collision detection/handling for objects travelling at very high speeds in almost the same direction.
I suppose this would mean changing the point of reference to the nearest point in an even grid, so maybe we´re even talking about the same thing? =P
We are talking about mostly the same thing. Numerical accuracy is really about cumulative errors. Even a plain old double with 53bits of precision is accurate to microns (about 17 microns) with a baseline from the sun to the earth. The problem with floating point is that the errors depend on the distance from the origin. This is compounded by the use of Cartesian coordinates. Typically spherical coordinates are used. Coordinate transforms then use tensors since these are curvilinear coordinates. That is the basis vectors change depending where you are.
Thing is that these small errors means that your simulated system could eject planets and that sort of thing all the time.
But all of the this is a bit moot for a lot of things. How accurate do you need it to be? What is it for? Faking it will probably get the job done without instabilities. ie just use parametric equations of motion for the planets. This is what Celestia and other orbital tracking software uses. There are tables that are accurate for the next 1000 years.
Also Celestia is open source and does all its visualization in opengl and they have dealt with the scale problem. You could check out their source.
Why not use BigDecimal(MathContext.DECIMAL128) to solve all these accuracy problems.
Yeah, the code verbosity sky rockets and you’ll produce quite a bit of garbage, but at least the calculations remain easy to grasp.
I want more than one planet… xd It’s horribly slow, right? Might have to benchmark that, but I’m not gonna hold my breath… Maybe I can write a less flexible class myself instead?
You lost me after you mentioned spherical coordinates…
I agree that using equations for immovable bodies is a good idea, but not for smaller bodies (ships, missiles. asteroids, etc). Let’s say they have to be able to remain stable for 100 years in game time (=100 days of running the simulation at 30 “FPS”).
Numeric instability could add some nice flavor to game. If you use too much time weird things start happen. The moon escape from the earth and jupiter start slinging deadly moons toward everything and other things that plaey can concider as apocalyptic events.
If the large bodies use parametric equations, this will make pretty much everything quite stable. Space ship etc are only affected by the large bodies and bobs your uncle you have a pretty stable system. Using big int will be very slow, I would just use longs or scaled doubles. For a game its going to be good enough.
I believe that doubles will be insufficient in extreme cases. I also think that using floating precision numbers for something that needs evenly distributed precision (like position and to some extent velocity) is simply bad manners, so allow me to hijack back the thread and instead derail it into even precision variables. I did som math on 64-bit longs and found that a 2D position can represent 2 light years with 1mm precision. Sadly the closest star system to the sun is 4 light years away. >_> Oh, 128-bit ints, where arth thou?
What´s the best way of doing this? I think using integer math is a good idea, but it seems to be really complicated and slow to emulate 128-bit ints. I´m sure that velocity is fine with 64-bit longs and a fixed decimal point since it´ll only be used to accumulate acceleration and I´m fine with limiting the max velocity to a few times the speed of light. xD
One idea is to use a 64-bit long to represent position in meter plus either a 32-bit int or a float as a fraction. This would give a range of 2000 light years with micro or nanometer (10^-9) precision. However, I it seems hard to do basic math with such variables, especially handling overflow and underflow in the fraction variable.
My idea is therefore to store position in >64-bit precision and velocity as a 64-bit decimal long. Acceleration is calculated as doubles since forces benefit from the floating precision.
As an example, here´s gravitational force:
//SuperDecimal = what position is stored in
//Calculate deltaPosition with fixed precision
SuperDecimal deltaPosition = largestBody.position - smallBody.position;
//Convert values to doubles since from here on precision matters less the higher the value is (=perfect for floats)
double dx = deltaPosition.xToDouble(), dy = deltaPosition.yToDouble();
double distanceSqrd = dx*dx + dy*dy;
double distance = Math.sqrt(distanceSqrd);
double dirX = dx / distance, dirY = dy / distance;
double acceleration = GRAVITATIONAL_CONSTANT * largestBody.mass / distanceSqrd;
//Velocity is also fixed precision, but an acceleration is a double. Round if needed
DecimalLong velocity = smallBody.velocity;
velocity.add(dirX * acceleration, dirY * acceleration);
//Later add velocity to position (add a DecimalLong to a SuperDecimal)
smallBody.position.add(smallBody.velocity);
The only problem is handling the subtraction to calculate deltaPosition and adding velocity. Am I insane? Thoughts?