Jump to content

The Physics Glitchers: a case study of KSP's rigidbody breakdowns


SkyRender

Recommended Posts

physics_glitcher.jpg

As we all know, KSP's rigid-body physics are currently a bit... wonky, shall we say? And by "a bit" I of course mean "a lot". Some very strange things happen when you distribute mass across certain parts. In particular, a number of structural parts are so rigid that they cause fluctuations when conditions are right. But what conditions? I decided to do !SCIENCE! on the subject, and here are my results. You can try out any and all of them here.

Test 1: Physics Glitcher

The classic (pictured above): 8 long girders with FL-T200 tanks attached. Invariably, it shakes itself apart in seconds. Delightful.

Test 2: Physics Glitcher Bi-Symmetrical Edition

In the interest of fairness, I decided to test symmetry first. And the results... were surprising. The first test put a lot of weight on those girders, and they behaved more or less how they should.

Test 3: Physics Glitcher Tri-Symmetrical Edition

But what if we added more? Still no breakdown.

Test 4: Physics Glitcher Quad-Symmetrical Edition

But what if we added more? Now we get both a breakdown and a breakdance as the rocket does the electric slide across the launchpad. Excellent.

Test 5: Physics Glitcher Hex-Symmetrical Edition

But what if we added more? Yep, we're back in familiar self-destructing territory. Conclusion this far: higher symmetry levels are all affected.

Test 6: Physics Glitcher Pocket Edition

So are the Pocket Edition I-Beams also affected? You bet your booties they are!

Test 7: Physics Glitcher Jumbo Edition

How about the huge thick girders? Oh yes they are.

Test 8: Physics Glitcher Jumbo Pocket Edition

And the third-size thick girders? Well...! No. They don't seem to be affected, or at least not to the degree that the others were since I didn't observe any fluctuations. In fact, they behave swimmingly.

Test 9: Physics Glitcher Hardpoint Edition

Surely hardpoints aren't affected! It seems like they aren't, so that's a bullet dodged.

Test 10: Physics Glitcher Micro Edition

One last test: Cubic Octagonal Struts. Other than when you do part-clipping, they seem to actually hold up just fine.

Conclusions: The biggest conclusion we can draw from all of this is that high symmetry levels plus long girder segments plus heavy weights on the end equals problems. But some other fun stuff came out of these experiments, like the quad-symmetry version that shuffled off to Buffalo. These were all very short tests, however. Further long-term tests need to be run to see how stable objects are when left in orbit for a time with girders attached, as well as when they're left on the surface for some time in the same state.

Link to comment
Share on other sites

The classic (pictured above): 8 long girders with FL-T200 tanks attached. Invariably, it shakes itself apart in seconds. Delightful.

Is it just me or did you forget to post actual screenshot?? Because I dont see any..

Link to comment
Share on other sites

These test results are consistent with the PhysX documentation tips about joint stability. The problem with wonky joints comes from a single source. The rigidbody solver has issues converging (finding a stable solution within the allowed iteration steps) when you have very high mass objects constraining low mass objects. On the test here, this was happening with the base of the test craft, which was constrained between the ground and an ever increasing load from the top of the craft.

Try this for confirmation. Have the base object of the rocket be heavier, say, a large tank. Then stack the same test rig on top, and check the stability of the system in the same way. My prediction is that it will either take a lot more mass to make it start to wobble, or that the wobble will be happening between other joints.

Lastly, there is another situation which we can already say will be wholly cured with the new joints system. When you have long objects linked together, like a long truss or tank, up until now, that meant attached objects would end up creating a long joint between their attach point and the long object's center of mass. That means you'd see on many occasions, objects dancing around on top of each other. With the new joints system, we have solved that. Now the attachment points are linked node-to-node, or in case of surface attachments, node-to-wherever-the-node-is-relative-to-the-surface... That means the joint itself is kept as short as possible, so that 'dancing wobble' effect is gone now.

There are a few cases still where we see flexing in the current state of the new system, some of those are intended, because we do want attachments that look flimsy to behave flimsy. We're still working to ensure those are the only cases where attachments are allowed to bend, but in any case, from what we can test here, there's already been a very noticeable improvement over the old system.

Cheers

Link to comment
Share on other sites

These test results are consistent with the PhysX documentation tips about joint stability. The problem with wonky joints comes from a single source. The rigidbody solver has issues converging (finding a stable solution within the allowed iteration steps) when you have very high mass objects constraining low mass objects. On the test here, this was happening with the base of the test craft, which was constrained between the ground and an ever increasing load from the top of the craft.

Try this for confirmation. Have the base object of the rocket be heavier, say, a large tank. Then stack the same test rig on top, and check the stability of the system in the same way. My prediction is that it will either take a lot more mass to make it start to wobble, or that the wobble will be happening between other joints.

Lastly, there is another situation which we can already say will be wholly cured with the new joints system. When you have long objects linked together, like a long truss or tank, up until now, that meant attached objects would end up creating a long joint between their attach point and the long object's center of mass. That means you'd see on many occasions, objects dancing around on top of each other. With the new joints system, we have solved that. Now the attachment points are linked node-to-node, or in case of surface attachments, node-to-wherever-the-node-is-relative-to-the-surface... That means the joint itself is kept as short as possible, so that 'dancing wobble' effect is gone now.

There are a few cases still where we see flexing in the current state of the new system, some of those are intended, because we do want attachments that look flimsy to behave flimsy. We're still working to ensure those are the only cases where attachments are allowed to bend, but in any case, from what we can test here, there's already been a very noticeable improvement over the old system.

Thanks for the clarification, Harv! I suspected it was PhysX at fault, as I've actually observed variants of this behavior in other games that use the PhysX engine. I also knew that it wasn't something that could easily be addressed, or it would have been by now since it's been a problem pretty much from day one (and of course you guys knew; how could you miss it when it seems like half the fixes involve fixing problems with PhysX limits?). It'd be a lot of trouble to model parts that aren't rigid-body for the girders, making it so that they can actually bend. I don't think I've ever seen a game that allows for dynamic part flexing of that variety, in fact!

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...