Hi everyone, Felipe here. Today I want to talk about the physics of wobbling, and how we implemented (and got it under control) it in Kitbash Model Club.
[h3]
Part 1 - Wobbly Aerospace Engineering[/h3]
So here's the problem: in a game where you have breakable vehicles that are made of parts, you need to somehow simulate the strains and stresses between those parts.
Back in KSP, the way it worked was that each part was a separate rigid body. They were all connected together via PhysX joints, and with those, we could just let the physics engine do its thing and joints would snap on their own when you put enough force on them.
The problem was (still is) that when you simulate linked rigidbodies like that, the position of any one body affects the position of all the others, which in turn affects it back, so you need to run multiple iterations to solve all positions every frame.
The more iterations you do, the more solid the whole assembly appears to be, but you can probably imagine this is not going to be great for performance.
If you want an infinitely rigid construct, you have to run infinitely many iterations. There is no way to just set a 'wobble scale' value down to zero.
The end result is that even with a very large number of iterations, you can always build something complex or large enough to see instability in your joints, and that instability shows itself as overly flexible connections that should have been rigid.
So I spent a lot of time back then, thinking about how I would do this if I could start over. And over time I came up with a plan.
[h3]
Part 2 - Welding it all together, so it doesn't move.[/h3]
In KitHack Model Club, I decided very early on that I was not going to treat parts as separate bodies. Instead, there is a single rigid body for the entire vehicle, and all parts are child objects of the vehicle.
This way, the vehicle is inherently solid. It has the shape of the aggregate of parts, but there is only one physical entity being simulated.
Ok, that certainly gets rid of the wobbling... but then that creates new problems. How do we figure out whether a part should break off? What point is there in using Struts? How would anyone ever be able to pull enough Gs in a display of excellent aerobatics to shear their own wings off?
Without the joints there to flex and bend, we needed to come up with another way to do those things.
[h3]
Part 3 - Internal Wobble Physics[/h3]
My plan for this had been brewing for nearly 10 years now (wow I feel old).
The idea is to use an independent, separate simulation for the wobble alone. We use a custom physics integrator, which treats each part as a body that is connected to its neighbours via constraints, or joints.
That sounds an awful lot like the original setup doesn't it? It actually is... but the key word here is separate.
In this 'internal' simulation, the vehicle lives in an inertial reference frame. We calculate and subtract all of the vehicle's root motion from the simulation, so what you're left with is only the motion between parts, aka the wobble.
We called this Internal Physics. It gives us a place where we can cause joints to flex and bend, but here we have full control over everything that goes in and out.
What we do then is take all of the forces that happen to the external rigid body (collisions, engine thrust, wing lift/drag, wheels, etc), and we also feed them into the internal physics. The external physics causes the vehicle to move as a whole, and the internal physics causes parts to move in relation to one another.
But most importantly, we can now have coupling constants to scale down these forces we are putting in. These are the 'wobble scale' parameters I had been wishing for since the early days.
You couldn't do this with a single physics model for the entire thing. If you scaled down the forces, your vehicles would just move less. But the wobble being separate from the external physics, this doesn't affect the behaviour of the vehicle as a whole.
This all means that the internal physics can actually be a very simple simulation. It doesn't need to run a lot of iterations, because we can scale down the input forces instead. There are no collisions either, because those happen on the outside.
It doesn't even need to run on the same thread, because the internal objects don't interact with the outside world directly. We actually offload the simulation to a background thread, which means we can let it run while the main game thread does other things for the current frame.
So in a nutshell, that is how the internal physics works in KitHack Model Club. There is a lot more I could write about this thing, but I've gone on for long enough already. In fact, props to you for reading along this far!
As a little reward for making it this far, I’m happy to announce that our next Alpha Test is happening very soon! How soon? November 16th to be precise!
In Alpha Test 2, we’ll be testing multiplayer, KitHack Model Club allows for up to 16 players to get together and battle it out, or you know, just show off your models.
Players from Alpha Test 1 will automatically be enrolled into Alpha Test 2, and an additional wave of new players will also be invited to play in Test 2, so keep an eye on your emails for more information and instructions!
We’ll also be organising play sessions with the community in the Alpha Test Channel on the
Discord at specific times during the 2 week test to give us opportunities to really stress test the 16 player load! Hope to see you there!
Thanks for reading, and see you on the next one!
Felipe (aka HarvesteR)
For all things KitHack Model Club, follow us on
Twitter (X), and join us on
Discord!
