shadowmage45 / KerbalFoundries2

KerbalFoundries - Continued
19 stars 8 forks source link

Suspension Problems #37

Open ConCon2 opened 5 years ago

ConCon2 commented 5 years ago

There is an issue with the suspension system for the wheels and tracks. Under certain circumstance(s), which I was unable to identify, the suspension for any of the wheels or tracks will shake shaking or throwing the craft into the air and causing the wheel stress to spice up and down rapidly. But the simplest craft that does this fairly reliably is just a Mk2 cockpit with two RBI inverting tracks on the sides. This effect can be amplified by increasing spring and damper, using the offset tool on the tracks, and the rotate tool on them (I made sure the tracks always laid flat in my testing). I only run a few other mods (KSPI-E, KAS, KIS, and Ground Construction (now Global Construction technically)) I only found this after updating Global Construction but I'm not sure how the update would cause this but I not a coder so...

shadowmage45 commented 5 years ago

I'm unable to reproduce this issue -- seems stable to me with default configuration. Just slapped some tracks on the cockpit.

screenshot10

Any specific steps needed to trigger this problem?

(and yes, playing with spring/damper can cause oscillations; it can also solve them; it is one of the main reasons that control is exposed to users -- to work around issues in Unity's physics stability code)

ConCon2 commented 5 years ago

This, I find, will just hop around on its own. image image

shadowmage45 commented 5 years ago

Have you tried adjusting the spring/damper settings? (the reason those sliders exist is so that you can fix problems like this)

If I set the 'spring' value to 0.2, and damper to 0.4 I get no issue with these tracks:

screenshot11

And yes it is intended that you need to adjust spring/damper to fix Unity simulation stability problems.

I cannot fix issues in the Unity Engine, all I can do is provide a work-around.

(it is a large portion these same issues you are seeing that have plagued the stock wheel system ever since the upgrade to Unity 5+ -- the physics simulation is simply not intended to be used in the way that KSP uses it)

shadowmage45 commented 5 years ago

I guess I should go into a bit more detail on why this is (still) a problem.

Unity does updates to physics in discrete 'ticks', at a set rate of 50 per second. I only have access to physics interactions during during each of these 'ticks'. (Internally, Unity breaks these ticks down into smaller timesteps which allows for much smoother simulation).

Suspension output force is, as a simplification, dependent entirely on how far the suspension is compressed.

Imagine four wheels at an arbitrary starting position on a vehicle. Resting state should be 50% compression. At the first/initial physics tick, the state and outputs are: Wheel 1 = 45% compressed, outputs 45n, moving downwards (becoming more compressed) Wheel 2 = 55% compressed, outputs 55n, moving upwards (becoming less compressed) Wheel 3 = 50% compressed, outputs 50n, stable, not moving Wheel 4 = 50% compressed, outputs 50n, stable, not moving

At the second physics tick, the state and outputs might look like this: Wheel 1 = 50% compressed, outputs 50n, still moving downwards Wheel 2 = 50% compressed, outputs 50n, still moving upwards Wheel 3 = 50% compressed, outputs 50n, stable, not moving Wheel 4 = 50% compressed, outputs 50n, stable, not moving

At the third physics tick, the state and outputs might look like this: Wheel 1 = 55% compressed, outputs 55n, starts moving upwards Wheel 2 = 45% compressed, outputs 45n, starts moving downwards Wheel 3 = 50% compressed, outputs 50n, stable, not moving Wheel 4 = 50% compressed, outputs 50n, stable, not moving

At the fourth physics tick, the state and outputs might look like this: Wheel 1 = 50% compressed, outputs 50n, still moving upwards Wheel 2 = 50% compressed, outputs 50n, still moving downwards Wheel 3 = 50% compressed, outputs 50n, stable, not moving Wheel 4 = 50% compressed, outputs 50n, stable, not moving

Repeat, ad naseum.

Basically the physics ticks are too 'large' in order to facilitate smooth simulation of such a numerically touchy system as spring/dampers. Not shown in the example, but often present in the appearance of the problem, is that wheels on opposite sides of the vehicle will 'feed-back' into the other wheels instability.

Most studies say that you want >1000hz for a 'stable' spring/damper simulation. I only have access to 50hz. <1/20th of the resolution and stability that I should have.

If I had access to Unity's physics sub-step integration, I could alleviate much more of the issue, as it would effectively increase the simulation to 200hz -- which tests have shown to be much more stable than the existing 50hz.