Just one question for SQUAD

[TheCanadianVendingMachine]

Hello all, I am asking just one question:

Have you actually tried to simulate physics at time warp? Or did you just assume that it would lag. I am assuming you did, but just to make sure I must ask basic questions

Thanks!

[Artophwar]

You can already do 4x physics warp by pressing ALT and the warp key. I can tell you from experience that at 4x physics warp it can get a bit laggy and big things tend to break apart.

[Crown]

You would need huge computers to calculate the physics during time warp with more than 4x. In case you want to try the influences on a space ship (on your computer), just start a new save and build a huge ship. Anything you ever wanted, with 500+ parts (maybe best build in the SPH).

With 4x physics having this big ship on the runway the computer load is very high. It lags as hell.

Well, this doesn't tell you what happens inside the computer during time warp but it tells you what happens to a ship in fast physics time warp.

To answer the question: Yes, I think they tried. And made the decision to limit physics time warp to 4x.

[HarvesteR]

We did try, of course. If that had been possible, it would have been a lot easier for us too.

When you speed up a physics simulation, you can do two things, one, increase the time that elapses during a single frame of the game. This is known as the 'time step'. You increase the time step so that on each frame, more time in the simulation goes by.

This has an issue though. Increasing the time step means you're also decreasing the amount of 'detail' on your simulation. Take the case of an object thrown upward ito the air. Where at 1x you'd get a nice and detailed arc with the object in freefall, if you warp time too fast, you get to a point where on one frame you're at the upward leg of that arc, and on the next, you're already coming down, and all that happened in between is simply non-existant.

So what this means is that increasing the time step causes inaccuracy on the simulation. You can see it happening in game, even at 4x warp, how the joints flex and bend far beyond their normal limits. 4x is about the most we can reasonably allow that won't cause complete mayhem in the sim.

The second option then is to correct for this loss of accuracy by adding more "frames" in between each game frame. These are called physics steps in unity. Essentially, you increase time, but you run more physics steps for each frame so that the time in between each frame was indeed simulated. In the case of the falling object, that would mean that even if you only did see two frames, one with it going up and another with it going down, the game internally did all the calculations, step by step, to figure out the position and velocity of the object at each point on its trajectory.

As you can imagine then, this second approach has a very severe impact on performance. The more you accelerate time, the more physics calculations the game needs to do to ensure it's accurate. If then at 4x you have to do four times as many calculations, imagine what warping at 100,000x would do to your computer.

So the best solution for us was to do what we did, which is to allow as much physics warping as we can, but for higher warp rates, turn physics off altogether and put all objects "on rails". That restricts us to 2-body systems (even outside of warp, since otherwise we'd have a discrepancy), but it allows for warp rates as high as what we have, without compromising accuracy.

Cheers

Edited August 19, 2013 by HarvesteR

[TheCanadianVendingMachine]

Right then, thanks Harv!

[The Jedi Master]

Indeed, putting things on rails is the best solution. I don't see how we could simulate physics in any recognizable way at X100,000 time warp.

[Zeblote]

We did try, of course. If that had been possible, it would have been a lot easier for us too.

When you speed up a physics simulation, you can do two things, one, increase the time that elapses during a single frame of the game. This is known as the 'time step'. You increase the time step so that on each frame, more time in the simulation goes by.

This has an issue though. Increasing the time step means you're also decreasing the amount of 'detail' on your simulation. Take the case of an object thrown upward ito the air. Where at 1x you'd get a nice and detailed arc with the object in freefall, if you warp time too fast, you get to a point where on one frame you're at the upward leg of that arc, and on the next, you're already coming down, and all that happened in between is simply non-existant.

So what this means is that increasing the time step causes inaccuracy on the simulation. You can see it happening in game, even at 4x warp, how the joints flex and bend far beyond their normal limits. 4x is about the most we can reasonably allow that won't cause complete mayhem in the sim.

The second option then is to correct for this loss of accuracy by adding more "frames" in between each game frame. These are called physics steps in unity. Essentially, you increase time, but you run more physics steps for each frame so that the time in between each frame was indeed simulated. In the case of the falling object, that would mean that even if you only did see two frames, one with it going up and another with it going down, the game internally did all the calculations, step by step, to figure out the position and velocity of the object at each point on its trajectory.

As you can imagine then, this second approach has a very severe impact on performance. The more you accelerate time, the more physics calculations the game needs to do to ensure it's accurate. If then at 4x you have to do four times as many calculations, imagine what warping at 100,000x would do to your computer.

So the best solution for us was to do what we did, which is to allow as much physics warping as we can, but for higher warp rates, turn physics off altogether and put all objects "on rails". That restricts us to 2-body systems (even outside of warp, since otherwise we'd have a discrepancy), but it allows for warp rates as high as what we have, without compromising accuracy.

Cheers

So how do you increase the ammount of physics ticks? Is there a way to do this yet or do we need a hack plugin?

[Cartz]

So how do you increase the ammount of physics ticks? Is there a way to do this yet or do we need a hack plugin?

Given that the Unity engine is generally horrible at physics on the scales which KSP requires, increasing the amount of physics calculations would just cause time dilation.

As far as I can see 4x timewarp is about the practical limit in KSP.... I don't know of a computer that can handle that without redlining the CPU on anything but the simplest crafts.

[Zeblote]

Given that the Unity engine is generally horrible at physics on the scales which KSP requires, increasing the amount of physics calculations would just cause time dilation.

As far as I can see 4x timewarp is about the practical limit in KSP.... I don't know of a computer that can handle that without redlining the CPU on anything but the simplest crafts.

A 150 part craft runs at 20% cpu on my computer - so I'm sure it could be sped up a little - atleast for one craft at a time.

[M5000]

A 150 part craft runs at 20% cpu on my computer - so I'm sure it could be sped up a little - atleast for one craft at a time.

Is that on x1 warp? If not, try putting it up to x4 physwarp.

Even so, you said it yourself, that would only work for one craft at a time, there's no way to just jump between physwarp "policies" based on the number of craft you have. They left it the way they did for that reason..

[Zeblote]

Is that on x1 warp? If not, try putting it up to x4 physwarp.

Even so, you said it yourself, that would only work for one craft at a time, there's no way to just jump between physwarp "policies" based on the number of craft you have. They left it the way they did for that reason..

Wait, there's physics warp already? Does it increment the number of frames or raise the simulated time between them?

[TheCanadianVendingMachine]

Zeb, it was there since timewarp was implemented. It just speeds up physics to 4x. You can use this in atmosphere and in space.

[Cartz]

A 150 part craft runs at 20% cpu on my computer - so I'm sure it could be sped up a little - atleast for one craft at a time.

Unity is not load balanced particulairily well, so a simple CPU reading does not suffice. Physics can't be offloaded to other cores, its a single thread.

That said, assuming a linear increase in cpu usage with physics timewarp your system would hit 80% utilization on 4x physics warp, which is available now, and 100% on 5x physics warp.

So even if the optimal case was the realistic case you're looking at a 25% speedup over what is available? In reality I bet if you enable 4x physics warp on that 150 part craft, you redline your physics thread and the game scales back to 3x to 3.5x warp anyways. The devs have, in all likelyhood, provided you with all your system (and most systems) can handle.

[Zeblote]

Zeb, it was there since timewarp was implemented. It just speeds up physics to 4x. You can use this in atmosphere and in space.

I used it and my rocket exploded. Oh well, it's not that important

[Cartz]

Use ALT + . (faster) and ALT + , (slower) to adjust physics timewarp.

[Mattasmack]

HarvesteR, it sounds like forces and collisions between parts make up the bulk of the physics calculations (and they're certainly the ones that go wrong at high physics warp!). Have you considered a sort of intermediate physics warp in which the ship is treated as a single rigid body? The ship would be 'frozen' in it's current shape, so there would be no need to calculate forces between parts or check for collisions, and the number of physics frames that can be calculated per second should go up significantly. It would make things much easier for the folks who want to use ion engines. The warp could be disabled automatically whenever the ship is in atmosphere, has acceleration above some low limit, or comes close to another ship -- all cases where inter-part forces and collisions should be calculated. It seems plausible to me from a computational standpoint, but I don't know how much freedom Unity gives you to do things like that.