You may also want to try the Range Kutta 4 (RK4) for integration: http://gafferongames.com/game-physics/integration-basics/
RK4 is slower than Euler integration or leapfrog, but it is more precise.
Gravity systems?
Author
On 16/6/2017 at 8:46 PM, Kem7 said:Now, how would you model the trajectories of three arbitrary bodies doing whatever?
Trust me, I have been trying to figure something, anything, out, but I understand the difficulty / impossibility of it. For 3-body, what comes to mind is a shifting barycenter, calculated as a point all its own, according to masses around it. But I am just spitballing, I have no actual idea...
On 16/6/2017 at 9:54 PM, taby said:You may also want to try the Range Kutta 4 (RK4) for integration: http://gafferongames.com/game-physics/integration-basics/
RK4 is slower than Euler integration or leapfrog, but it is more precise.
RK4 has been mentioned before. It seems versatile, but I have to read up on it. Thanks!
On 6/19/2017 at 11:11 AM, Embassy of Time said:Trust me, I have been trying to figure something, anything, out, but I understand the difficulty / impossibility of it. For 3-body, what comes to mind is a shifting barycenter, calculated as a point all its own, according to masses around it. But I am just spitballing, I have no actual idea...
RK4 has been mentioned before. It seems versatile, but I have to read up on it. Thanks!
It's about the quantity of information involved. You can model two orbiting bodies an arbitrary amount of time into the future. No matter how far you go into the future, bodies' path take up a constant amount of storage space because they travel the perimeter of the ellipse.
Three bodies, all applying meaningful force to each other, do not follow any particular pattern. Particular configurations of three bodies may, but not arbitrary configurations. You might be able to model their trajectories, but those paths would take up an increasingly large amount of storage space, limited only by how long the simulation is run. And you'd probably need numerical integration to compute those paths to begin with.
That said, the advantage of such a solution is that, if you can simplify the orbits into repeating patterns, you can calculate a year into the future as easily as you can calculate a second. Three bodies can be simulated as long as their trajectories are are easy to represent and the error introduced by simplifying their trajectories is acceptable.
As I mentioned, the 8 planets can be modeled using ellipses. You can also model the earth-moon system orbiting the sun (3 bodies).
The disadvantage of such a solution is, of course, that calculating a second into the future is as expensive as calculating a year in the future. And in the case of ellipses it's gonna look something like:
meanAnomaly = meanMotion * (time - this.t) ;
eccAnomaly = meanAnomaly + this.e * Math.sin(meanAnomaly) * (1 + this.e*Math.cos(meanAnomaly));
var oa = 0;
do {
oa = eccAnomaly;
eccAnomaly = oa - (oa - this.e*Math.sin(oa) - meanAnomaly) / (1 - this.e*Math.cos(oa));
} while (Math.abs(eccAnomaly - oa) > 1.0e-6);
trueAnomaly = 2*Math.atan(Math.sqrt((1+this.e)/(1-this.e)) * Math.tan(eccAnomaly/2));
distanceNow = this.a * ( 1 - this.e * Math.cos(eccAnomaly));
var positionX = Math.cos(trueAnomaly)
var positionY = Math.sin(trueAnomaly);This is the bulk of converting kepler elements to cartesian coordinates. It's not fast. Even an optimized version, for a large number of objects, would be more expensive than just doing numerical integration. And this is just for an ellipse. This kind of solution is wonderfully suited for situations where you need to be able to skip forward (or backward) arbitrary amounts of time, but not well suited for real-time evaluation. Unless you are able to limit yourself to 2-bodies at a time and ellipses, parabola, and hyperbola to model trajectories (while also needing the ability to skip forward or backward), stick with numerical integration.
I cannot help thinking that a game that needs accurate simulation of star clusters or galaxies must be very peculiar: on scales of many light years, stars take at least decades to move a significant amount relative to the distance to their nearest neighbours, so concrete effects on characters in a game are going to be noticeable only at extreme time scales.
In a game that simulates a few years of space adventures moving stars at all, let alone in a correct gravity simulation, is an unnecessary luxury.
Realistic simulations might be desired for procedural generation purposes, but even in this case they offer no advantage over randomly generating the contemporary state according to realistic constraints and random distributions.
Author
16 hours ago, Kem7 said:It's about the quantity of information involved. You can model two orbiting bodies an arbitrary amount of time into the future. No matter how far you go into the future, bodies' path take up a constant amount of storage space because they travel the perimeter of the ellipse.
Yeah, I do seem to be staring at a brick wall here. I've spent the last week or so really reconsidering what I need compared to what I am doing, and maybe this isn't the hill I should choose to die on. I think some approximation will be used from here on in. As long as there is a sense of the progression of time. But right now, I feel a bit burned out by the brick wall 
10 hours ago, LorenzoGatti said:I cannot help thinking that a game that needs accurate simulation of star clusters or galaxies must be very peculiar: on scales of many light years, stars take at least decades to move a significant amount relative to the distance to their nearest neighbours, so concrete effects on characters in a game are going to be noticeable only at extreme time scales.
In a game that simulates a few years of space adventures moving stars at all, let alone in a correct gravity simulation, is an unnecessary luxury.
Realistic simulations might be desired for procedural generation purposes, but even in this case they offer no advantage over randomly generating the contemporary state according to realistic constraints and random distributions.
It's a time travel game. I really don't need this level of detail, but something just went a bit out of control. What I want is a full universe that ages and evolves, and although the focus is intended mostly on planets evolving, the astronomy part is important, too. It sets up the big stage's depth, so to speak. But yeah, as mentioned above, I have started to reevaluate what is needed and what is just me being nitpicky, because I seem to be stuck at the N-body problem....
How much time passes between consecutive featured periods and between the earliest and latest period? Many approximations seem possible.
- No star movement at all
- Simple interpolation between random states
- A different random state in each time period
Well if you want simulate stars and such, pull and push each other - there is a well known technique for that, which was originally designed for astro-physics:
https://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics
There are dozens of papers how to implement, but the core idea is always the same:
- Each Particle uses its surrounding neighbor particles to compute a density based on their accumulated weighted distances using a distance approximation (smoothing kernel).
- Based on that particle density you can compute a force to pull or push particles apart.
To get reasonable performance for that N-body simulation, you have may use a spatial grid to sort the particles into and to determine the neighbors much faster. Also you can parallelize it to improve performance more drastically, but best situation is when you can compute everything on the GPU.
Author
On 22/6/2017 at 10:27 PM, LorenzoGatti said:How much time passes between consecutive featured periods and between the earliest and latest period? Many approximations seem possible.
- No star movement at all
- Simple interpolation between random states
- A different random state in each time period
I used this up till this point, but the problem with random states (the "no movement" is really a non-option) is that A: it lacks the appearance of a system as soon as someone studies it a bit, and B: it is impossible to use back and forth scrubbing in it without filing literally millions of used random states. As a simple background element, it works fine; I already used it plenty! But I am at a point where I need to use something with a more solid structure
On 23/6/2017 at 8:16 AM, Finalspace said:Well if you want simulate stars and such, pull and push each other - there is a well known technique for that, which was originally designed for astro-physics:
https://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics
There are dozens of papers how to implement, but the core idea is always the same:
- Each Particle uses its surrounding neighbor particles to compute a density based on their accumulated weighted distances using a distance approximation (smoothing kernel).
- Based on that particle density you can compute a force to pull or push particles apart.
To get reasonable performance for that N-body simulation, you have may use a spatial grid to sort the particles into and to determine the neighbors much faster. Also you can parallelize it to improve performance more drastically, but best situation is when you can compute everything on the GPU.
Ooooooooooohhhh..... this looks yummy!! I am going to chew down on that for some time. It even has multi-purpose use, for fluid dynamics and other fancy stuff! Thanks!!
I still don't see
On 24/6/2017 at 6:15 PM, Embassy of Time said:I used this up till this point, but the problem with random states (the "no movement" is really a non-option) is that A: it lacks the appearance of a system as soon as someone studies it a bit, and B: it is impossible to use back and forth scrubbing in it without filing literally millions of used random states. As a simple background element, it works fine; I already used it plenty! But I am at a point where I need to use something with a more solid structure
I still don't get how the player of a game of typical genres can possibly
- notice that stars move, including distinguishing different starfield backgrounds
- "study it a bit" and figure out that the stars not only move, but have discrepancies with an accurate dynamic simulation (large scale gravitational simulations defy intuition)
- give any in-game consideration to short-term astronomical movements, except for exceptional situations that should be scripted (planets leaving orbit, star collisions, etc.).
- have adventures that last enough to make long-term astronomical movements significant (e.g. impactful alteration of distances).
Can you explain why the approximation of stars that don't actually move is a "non-option"? Why would you need millions of random states without millions of very long and/or very distant featured time periods? In which ways are stars more than a "background element" or a travel time between star systems?
What can't you do with planetary systems where random planets, satellites, asteroids, comets follow physically correct random orbits around randomly placed stars, without the need for an actual gravitational simulation?
Author
On 25/6/2017 at 2:18 PM, LorenzoGatti said:What can't you do with planetary systems where random planets, satellites, asteroids, comets follow physically correct random orbits around randomly placed stars, without the need for an actual gravitational simulation?
It is about time travel, across millions of years if needed. The universe changes over that timeframe, and I want it to change in a scientifically credible manner, partly because it is meant to convey science, a la 'edutainment', partly because I just want it to.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
