@UberGaf Tell Us More About the Physics Engine

Great videocast! I loved the explanation of the celestial physics engine. I was wondering if UberGaf would mind expanding on that a little.

The problem of erratic behavior when the acceleration of the body is changing faster than the tick time of the engine is a problem I've faced before. How did you overcome it?

As always, it's fun to watch such great work in progress, keep it up!

...thinking about it a little more, I'm guessing that moving to a conical section based, 2-body simulation side-stepped that problem since the orbit is essentially predefined, right?

Of course, that would still leave the problem when the n-body physics switch is flipped on, so I'm still thinking you have some other approach. I've used a fail safe method before that looks for wacky behavior and tries to cope, but you probably have a more elegant solution.

Anyway, just geeky curiosity. Cheers!

DOUBLE POST FAGGOT GET OUT MODERATORS BAN BAN

No but seriously now, if the acceleration of a body is changing so fast that the engine can't handle it, you are going too fast.

If you're talking about collisions, I know some engines implement a rollback system that allows the engine to break down a collision and 'roll back' the position of each colliding body to the exact moment of collision, and calculate the proper response based on that moment. Some other engines, like Bullet, just roll with any inconsistencies, making them better for floatier, cartoonier games.

Considering that it's just spherical collisions we're talking about here, Uber probably doesn't have to skimp on planetary collision, at least in terms of initial collision detection. Once you get down to the nitty gritty of asteroids smashing into planets, you have to start worrying about narrow-phase detection, but until then it's just trying to get it accurate.

Or did I entirely misread your query and have made myself look like an idiot trying to look smart?

I think the question was relative to the problem demonstrated in the livestream with the n-body dynamic system acceleration was too fast and escaping the orbit.

I honestly don't understand why they are talking of n-body systems when it's so easy to do exactly the same by applying the kepler equation, solving any issue (n-body gravitational interactions that they are are dismissing by isolating systems and making independent n-body system, the escaping problems, and of course, computing fairly easily the interception point for asteroids).

There is probably something I'm missing, but it look like they are over-doing it. I would like some explanations about that choice.

A) It is less real, which is sad panda
B) There are things you can do in real life that don't work in 2 body/kepler sim, like Lagrange points, the interplanetary transport network and so on.
C) Who knows what cool crazy thinks modders/gamers will do if we give them the tools too.

From what I've understand, it's really a 2 body system as they are ignoring all others interactions, hence my question. Because :

A) Ignoring interactions is not "more real"
B) Would be the same as asteroid trajectories, you can always found a specific way to compute them in a believable manner.
C) Yes, that's true. But it's maybe an over-kill for now seeing how much still need to be done.

The problem is not the N-body simulation in itself, it is that there is no nice (analytic) solution to N-body problems for N>=3, so you have to calculate the trajectory step-by-step, while for N=2 the trajectory is set once and for all and it's a nice conical trajectory: ellipsis or parabola essentially.

When you make a step-by-step simulation, you accumulate floating point numbers and matrix calculation errors, especially when accelerations are too high with respect to the chosen time-step, which essentially lead to increased chaotic behavior with respect to real-life physics, and a trajectory like an ellipsis can become a spiral or whatever.

It's entirely possible that they aren't actually able to increase the timestep. However, I will also remind you guys that the simulation in the video was running at a much faster pace than in-game simulations; planets were doing whole orbits around the sun in a matter of seconds. That wouldn't make for very good gameplay, or very believable gameplay for that matter.

If they slowed down the simulation as a whole, the timestep would increase and they shouldn't encounter the acceleration problems they did. Alternatively they could implement an error correction system than ran in parallel with the simulation that kept planets "on the rails", but that would be kinda lame.

A) I was referring to a full n-body simulation, much more real than
B) asteroid trajectories can be within the 2-body problem, it just becomes a timing issue of 2x 2-body problems, Lagrange points require a 3 body problem, yes you can cheat though, but that brings in the issue of where is the line for cheating/not cheating in game, is it going to cause issues/etc. And for every n-body problem feature you want to bring into your 2-body problem you need another cheat.
C) I think it's already done, both systems are implemented I thought. (at a basic level I thought)

I do honestly prefer a 2 body for gameplay btw. I'm just trying to answer the 'Why would we consider n-body?'question

And plannihilator, yes you could do dynamic time stepping, but that does require there always be some overhead room available in case you have a very long period of craziness, otherwise your game starts slowing down, might as well just use the smaller timestep by default then. And as someone who writes his own basic sims, the suggestion of switching integration techniques during sim is terrifying.

I do not understand most of the discussion to be honest, but i think i can contribute a little bit with this :

Taken from this topic.

Yes, yes, i know. You can be afraid. I read EVERY single post in the PA forums.
(well, except from Modders & German sub-forums, lack of technical & linguistic knowledge... Shuch a shame for me)

I am now angry at myself for missing that discussion

So here's a brief history of the evolution of the celestial simulation.

1) Build a general purpose N Body simulator
2) Refine the N body simulator to be a system of 2 body simulations
3) (I actually did this work just yesterday, so it wasn't mentioned in the live stream) Realize that if I'm reducing everything to 2-body systems, I might as well just implement an iterative numerical solution to the Kepler equation and have 'perfect orbits'.

So that's pretty much where I am today. I'm pretty happy with 3). It allows stable predictable orbits, which is a requirement for any kind of fun gameplay. It allows you to trivially throw, say, 10 moons in orbit around a planet and have it 'just work'; something that would be impossible in a simulator and very difficult even in the real universe.

A few words about simulation:
As demonstrated in the livestream, the math breaks down under a variety of circumstances, the most obvious being when you are dealing with highly elliptical orbits.

However there is another, more broad, problem: the game solar system simply doesn't reflect 'real space'. For example, if the Sun were the size of a basketball, the earth would be the size of a pea about 100 feet away. Because of the sheer scope of this scale, it's hard to reflect it in a fun, game-friendly, way. In the game solar system, any kind of a moon around a planet is going to experience far more gravitational influence from the central star or neighboring planets than would be the case in a 'real solar system'; which in turn means that everything is fundamentally less stable right out of the gate.

Now, there might be way to compensate for this. You could implement a physics model where gravity falls of with an inverse cube instead of inverse square. But in my opinion, this would be just making my life harder than it needs to be.

First, thanks for the insight.
I'm sitting here and I have no ideas how to deal with it. You at that point have to decouple the planet radius units from the orbit distance units (ewww...), but you do loose that sense of scale. Although at that point I'd imagine it's just a matter of scaling mass and orbit size to get what you want. Although the huge jump in orbital period as you get farther out still becomes an issue.


hrrrrm....
thanks for the food for thought!

Hey,

I was working on orbit transfer optimization as a students job last year. There the company didnt use kepler elements, but the so called equinoctial elements. They do not have singularities (if I remember correctly, keplerian equations do have som 1/sin(x) in there, where sin(x) could become 0...)
Maybe you can use them too, or maybe that doesnt help, just wanted to mention it^^
http://www.cdeagle.com/pdf/mee.pdf

You can't, inverse square law and proportional law (spring/elastic law) are the only two laws that produce closed trajectories in a flat euclidian space.

Maybe a tricky combination of both...

Another way would be to terminate the influence of gravity at a certain radius depending on the mass ratio between objects. (ie: Moon only feels earth, Earth only feels Sun etc.)

which would then be nothing else than a special form of 2 body problem^^

Out of interest, has a "too scale" or relative scale build been tried? I quite like the idea of a pea size planet to a huge star - I think it would actually just look better in game & give a better sense of awe.

it would look better, but it would result in either super tiny planets, or super big suns and sssssssssuper big orbits, which again would lead to ultra long "years" and a asteroid would need real time months until it could hit a planet^^

I think the best way to give a sense of real scale would be to...

A: Scale down all distance, speed and acceleration-related parts of units by about 0.2x
B: Scale up the sun by maybe 10x, 20x

And that's all you'd really need to do. The close planets kinda adds to awe, I looked at the system editor and it made me think I was fighting over a proto-starsystem.

I'll read through this, thanks for the tip!

I did not know that! Do you have a reference/citation I can look at?

I agree, and watching a planet pass in front of a massive sun is pretty cool from a system standpoint. However, when you're focused on managing troops on the planet and the entire border of your screen turns yellow because you happened to put the camera in just the right (wrong) place, that's pretty distracting. I think that the likely thing will be to leave some flexibility up to the user, and limit/expand it based on user feedback.