Physics engine - Only simulate physics on crafts undergoing a change in acceleration

[Kyarao]

Currently, the physics engine runs on a part by part basis constantly. I propose changing this to a whole craft approach unless specific conditions are met. This will ease the current load on the physics engine and still provide a high level of realism.

Also, I haven't seen the code behind the physics engine so I'm not sure if it checks every part every game step or switches through parts each step. I also propose a dynamic step through of parts checking to reduce physics load at low fps.

Overall, this should result in a higher part count before the terrible kraken raises it's ugly head.

The physics engine should treat all craft as rigid structures unless the rate of change of acceleration ( This is called "Jerk" ) is greater than the integrity of the weakest part.

How I propose the engine does this:

Firstly, the acceleration on the craft as a whole is measured against the acceleration of the previous game step. The engine then steps through part connections in the order of weakest to strongest. If the jerk applied to a connection is enough to cause that connection to break, it will give that connection a flag indicating that it is to be treated by the full physics engine. As soon as a connection is found that will not break, all remaining connections in the entire craft are treated as rigid.

For example. When a spaceship is generated on the launchpad, its initial acceleration is 9.81m/s^2. The next game step, this acceleration has not changed. Since there is no change in acceleration, the entire craft is treated as rigid.

This has the problem of allowing players to put heavy weights on long arms, since the whole craft is treated as rigid until sufficient jerk is applied to break a connection.

To counteract this, the physics engine should check if the ship has been newly generated. New ships should be effected by the full physics engine.

Since the physics engine may only come into effect during a change in acceleration, eliptical orbits, mad SAS units and user input will all cause the engine to start checking connections; bases and rovers will be able to have many more parts.

Unfortunately, this means that full physics still takes effect during most normal gameplay. (it's pretty much impossible to get a perfectly circular orbit). This is why I proposed the tolerance above. Treating ships as rigid until a significant jerk will allow space stations and ships in space to have many more parts than they currently do.

If the tolerance I suggested seems too easy, it could be changed to checking if a jerk will cause a flex of 20 degrees (for example).

How does the engine know if a component will break/flex under a certain jerk?

When the craft is first generated on the landing strip or launchpad, the engine should stress test each component in all 3 directions, recording the jerk required to break each connection (or cause a flex).

Why use jerk? Why not acceleration?

Constant acceleration induces a constant strain on all connections. If the connections have survived one instant, then they will survive the next.

Jerk is the EXTREME CONDITIONS version of acceleration, like when you slap into your docking port at 10 m/s instead of 0.1 m/s, or when you nosedive into the ground 'cos you let SAS wobble your spaceship to oblivion.

What's your problem with SAS?

SAS can't drive. it overshoots constantly and can't control its own oscillations, leading to wobble and dead kerbals.

It keeps applying force until it's beyond its target point then reverses the direction of force applied, instead of reversing direction of force before reaching the target.

-------------------------------

There are still some situations where the physics engine will come under high load in the engine change I proposed. During these extreme situations, framerates will drop and the physics engine will come under extreme load. I suggest changing the physics engine to reflect the current FPS. As the framerate drops, the engine should go from checking all connections per game step to checking a few, to checking only one connection per game step and in EXTREME fps loss, there should be an increasing number of game steps between each connection being checked.

This could result in some parts being destroyed when they were not supposed to be, due to the physics engine's part checking lagging behind current events. If the physics engine has to reduce its part checks per game step, it should necessitate each part NOT breaking (or flexing) for 2 continuous checks before reverting to treating the craft as a whole, rigid structure.

Hope this post wasn't too hard to follow! Also hope it leads to an improved physics engine that allows spaceships, bases and rovers with thousands of parts each

[thereaverofdarkness]

I think this is a good idea. I'd also like the ability to see distant craft (10km - 2.5km) without loading their physics at all, and maybe load a very simplified version of the craft's appearance at 50km - 10km. Great for seeing things a long ways away, especially very big things. Could be useful if anyone every constructs a Mün city.

[Kyarao]

I'm not sure how the game handles location data, but I suspect that is the reason for the 2.5km limit at the moment. Computers are innacturate with precise numbers on large scales (hence the old kraken when you go too fast or fly too far)

also, I think cutting down on lag rather than giving it more opportunity to arise is the direction beta development should go.

Alpha is more for pumping features into the game engine until it resembles the full version with less assets, more bugs and no optimization

[AngelLestat]

This is similar to what I suggest in the "hibernation instead warp drive" topic, I said that there is not point to calculate all the physsics if there was a constant acceleration (this was to solve the problem of high time warp with constant acceleration)

You only need to calculate for the fist instant like Kyarao said and then take the whole ship like rigid in case that first instant pass the test.

But I dont think that this can be apply it inside the atmosphere, because the drag is not constant.

[Kyarao]

Due to inconstant drag, changing isp and changing gravity, acceleration will not be constant in atmosphere.

Acceleration is not constant in nearly all cases, which is why I propose the flex or break tolerance.

So long as the change in accelerarion is small enough, craft should be treated as rigid.

Once the change in acceleration of the craft as a whole is high enough, the tolerances would be passed and parts will begin to flex and break.

This is a much better alternative to having full physics simulation on all parts all the time.

[allmhuran]

It's a good idea for the most part, and there have been several suggestions like it. But it does have a couple of issues: when objects collide (including landings) the engine would have to switch from simplified to full physics. This would cause the game to pause at those moments like it does at launch or when coming within a couple of km of a large vessel. The same would be true when making adjustments to throttle. The re-initialization "lag" caused at these times might be more annoying than a constant but at least consistent loss of framerate.

[oggylt]

You did a nice work, writing all that information about your suggestion which to me seems rational enough. Will be following this thread

[NeilC]

I understand the idea behind your suggestion - reduce the load on the physics engine. It's been suggested many times before in many ways, like treating anything in a fairing as a single rigid body or treating anything placed symmetrically as a single body. Conceptually, it's a good idea. Conceptually, jerk is a good heuristic to use.

Unfortunately I don't think your concept can work in practise, for two reasons:

1) The physics solver takes as inputs: the forces acting on all bodies, and the positions of all bodies. It then models all connections between bodies as springs, solves f=ma for the whole craft to get accelerations for each part, and then does it all again for the next timestep. Accelerations (and jerks) for each part are not known until you've solved the system - they are the outputs. To know the jerk is too low to bother solving a part, you must first solve the part.

2) The KSP devs did not write the physics engine they are using. It's the Unity RigidBody solver, built in to the toolchain. They cannot make the changes you are suggesting to calculate only some joints without writing a new physics engine from scratch (not going to happen).

It would be possible to combine collections of strongly-connected parts into "super-parts" so they only use one rigid body and run this modified craft through the Unity solver instead - that's what people have suggested doing for parts within fairings. In your idea, however, this would have to be done on the fly and would involve a load/unload of the modified craft into the Unity scene. By the way, that load/unload is what makes it take so long to switch between the VAB and the launchpad. It's really not a good idea to do that every frame - it would hurt performance instead of helping it.

Edited September 3, 2013 by NeilC

[AngelLestat]

Kyarao

Due to inconstant drag, changing isp and changing gravity, acceleration will not be constant in atmosphere.

Let's get something clear, because as you wrote it, sounds confusing.

There are only 2 different foces that we need to take into account in atmosphere and only 1 in orbit.

Atmosphere: Drag and Acceleration

Orbit: Acceleration.

Acceleration is a vector, is the add of all accelerations forces such as gravity, centripetal force, acceleration due engine thrust, etc.

Drag is also a vector, are usually forces opposing to the movement

NeilCThey cannot make the changes you are suggesting to calculate only some joints without writing a new physics engine from scratch

I think that we can have different modes or time warp modes, where some accelerations or drag values may be ignored.

[Kyarao]

Acceleration is the result of the vector sum of forces acting on a mass. It is not a force.

The forces acting on a craft in atmosphere are: Gravity. Thrust. Drag. Lift.

All of these values change constantly while flying in atmosphere resulting in a constant change in acceleration.

In space, there is merely gravity and thrust. Gravity is constantly changing in any non-circular orbit. This results in a constantly changing acceleration

[Kyarao]

Thanks for letting me know about the limitations of the Unity Physics engine. Shame there's no plan for Squad writing their own physics engine.