Time acceleration vs physics

[Angezerus]

Hello!

Maybe I'm wrong, but I have noticed that in time acceleration, especially in atmospheric flight, not only the time accelerates, but the physics as well, meaning, accelerating time will make you go faster and increase the stress on air/spacecrafts. To counter this problem, I suggest to divide the physics data with the time multiplier:

tick( calculate_physics()/time_mult ) * time_mult

This way the time-relative physic values would be constant on every time acceleration level, only the time would accelerate, so parts wouldn't get crazy and break.

[Xaiier]

Technical accuracy aside, this is a good idea, but it isn't really feasible as an addition to the stock game.

The problem with your concept is that while it 'works', it also increases the already heavy physics load. In many cases this won't help the overall speed, because the extra lag will counteract the speed. This is also why the stock game can't do this, as intentionally overtaxing the physics engine and causing lag isn't a good operating procedure. As such, the stock game decreases the physics precision by the same factor of warp to maintain a constant physics load throughout. This is what causes the "crazyness" you describe, but it also severely limits the maximum warp due to overly inaccurate physics.

That being said, it's entirely possible to throw caution to the wind and do so anyways, and I made a mod specifically to do so (See my sig). It gives you the capability to toggle an alternate 'hyper-warp' mode which you can set to try to perform physics warp speeds of up to 100x, and also allows you to reduce the physics accuracy down to 0.25x like the stock 4x does, among other things. To an extent this works, and it is possible to attain physics warps well beyond the normal stock limits without any loss of precision or significant lag - assuming you have a powerful computer and a small ship.

Also, welcome to the forums!

[arkie87]

Technical accuracy aside, this is a good idea, but it isn't really feasible as an addition to the stock game.

The problem with your concept is that while it 'works', it also increases the already heavy physics load. In many cases this won't help the overall speed, because the extra lag will counteract the speed. This is also why the stock game can't do this, as intentionally overtaxing the physics engine and causing lag isn't a good operating procedure. As such, the stock game decreases the physics precision by the same factor of warp to maintain a constant physics load throughout. This is what causes the "crazyness" you describe, but it also severely limits the maximum warp due to overly inaccurate physics.

That being said, it's entirely possible to throw caution to the wind and do so anyways, and I made a mod specifically to do so (See my sig). It gives you the capability to toggle an alternate 'hyper-warp' mode which you can set to try to perform physics warp speeds of up to 100x, and also allows you to reduce the physics accuracy down to 0.25x like the stock 4x does, among other things. To an extent this works, and it is possible to attain physics warps well beyond the normal stock limits without any loss of precision or significant lag - assuming you have a powerful computer and a small ship.

Also, welcome to the forums!

I dont really think you understand his suggestion. His suggestion will not increase physics load -- the number of calculations per second will remain the same. The only difference is normalizing by the time step such that forces/stresses are not multiplied by by time acceleration factor... (unless you are implying that adding one division will significant increase the load on a cpu, even if its operating at 60 calculations per second...)

That said, i suggested this a while ago, but the way Unity physics engine works, merely dividing by the timestep is not possible/wont help because forces are applied where they are generated:

for instance, if you have a spaceplane with engines located on the wing tips, unity applies forces on the engines, which then move forward after one timestep. The displacement creates a force on the wings (i assume a linear spring constant) and drag the wings and fuselage along with it. Thus, 4x acceleration will result in 4x displacement.

However, one possible fix is to multiply everything else i.e. spring constants and stress/impact tolerances etc... by time acceleration factor so that displacement and stresses will not be affected.

Also, ive noticed that intake air calculations increase by 4x under 4x time acceleration, which isnt correct...

[Xaiier]

Ah, I see what you mean. Nevertheless, that isn't a solution, as higher forces and such won't behave even close to properly.

The wobbliness results from minor errors in calculation over the timestep period, such as two parts which have slight relative motion. Over a longer timestep (required by the physwarping) these errors become more noticeable and can compound on themselves.

[arkie87]

Ah, I see what you mean. Nevertheless, that isn't a solution, as higher forces and such won't behave even close to properly.

The wobbliness results from minor errors in calculation over the timestep period, such as two parts which have slight relative motion. Over a longer timestep (required by the physwarping) these errors become more noticeable and can compound on themselves.

The way Unity physics engine works is by applying forces to individual parts, the equations of motion integrated with time which causes acceleration parts to displace and "pull" other parts along with them. I think increasing spring constants under time-acceleration should fix displacement problem. Alternatively, using implicit integration, rather than explicit, would fix the problem as well (though I dont think Unity can do this....)

That said, I like your Time Control mod I used it to slow down time so i could crash into Kerbin at 150 km/s and see what happens