Or “once again, curse my rudimentary knowledge of mathematics!”.
Basically, I’ve wanted to try my hand at making a small 6DoF space sim with newtonian physics. Obviously, that includes a reaction control system for turning the spacecraft (sets of small thrusters mounted all over the hull at various angles). I’ve decided to go for a fly-by-wire solution for this, as it’s a general solution that will allow me to modify RCS thruster placements without much hassle, and it would be far easier for players to pick up the game and play.
The problem is this: I have no idea how to even start writing a fly-by-wire system. Thankfully, the RCS thrusters are fixed; there is no thrust vectoring/gimballing to account for, which should make it easier? If someone could point me in the right direction, it would be much appreciated.
Fly-by-wire is basically taking simple user input, in this case mouse movements, and in this case translating it into spacecraft rotation by applying the right amount of force at each RCS thruster. It’s the amount of force for each thruster that I want to calculate.
6DoF (six degrees of freedom) basically means the game’s going to have 3D movement and you can move/rotate on all axes infinitely.
Well, if you want to test your spacecraft framework first, (depending on whether you want destructible spacecraft), I would make a test body with a vehicle seat, (for easy reading of speed and strafe controls) and bind them all together in a physics friendly manner (weld constraints should work). As for 6DoF, which I’ll call mouse control from now on, you may need to come up with a complicated system of figuring out how much thrust to apply to each thruster to rotate the spacecraft to PlayerMouse.Hit
It might be a bit more complicated than that - there will be maximum values for pitch/roll/yaw rates (explained as flight assist, so the player doesn’t turn too fast and tear the craft apart or “oversteer”), and the camera will be coupled to the craft in a kind of “third person” mode, so just using PlayerMouse.Hit probably wouldn’t work.
I am thinking about some degree of damage modelling, though - thrusters will be able to be shot out or otherwise destroyed, impacting the flight performance of the craft, among other things.
Another method to look into may be additional keys on the keyboard besides wasd (GTA uses some keys on the numpad for keyboard only flight, and I find that very comfortable)
Huh? This is about calculating the force that needs to be exerted by each thruster to perform a task requested by the user, like translating or rotating the craft. The input’s simple enough and already nailed down, I just need to figure out how to actually rotate the craft using only a bunch of fixed-point thrusters.
Oh. Sorry. I thought you were saying you didn’t want to use the PlayerMouse. I can’t think up a math equation to figure out how much thrust to apply to each thruster off the top of my head, but I know it’s possible.
Personally, I’d do it backwards from what you’re thinking of. Calculate the possible torque by summing up the torque that each thruster can apply by multiplying the distance from the center of mass with the magnitude of the thruster’s force. The easiest way to do this would probably be to group thrusters by the axis of the torque they cause and just sum within those groups. You should have six groups, -X/+X, -Y/+Y, -Z/+Z.
Then apply the torque according to user input up to the max torque of the thrusters. Then you can simply render the effects by figuring out the fractional contribution to the desired torque that each thruster is giving by dividing that thruster’s max torque by the group’s max torque, then you get a number between 0-1 to multiply with the fraction of applied torque divided by max torque for that axis.
By only ever applying torque directly, you’re simplifying the work for the physics engine and also making it more predictable. You also avoid the need to actually make sure the torques balance out, which would probably add an unnecessary art load that no one will notice anyway. You should still try to mostly ensure they balance out for plausibility, but now they don’t need to be perfect.
Aha, that’s perfect! Only one question: by a “group”, do you mean all the thrusters required to rotate around each axis, or just the ones mounted on the same area of the craft?
All the ones required to rotate around each axis. I guess this means you may have some overlap in your groups, since a thruster might be able to rotate the ship in more than one axis when combined with different thrusters. Still, I think you could probably overlook that complication for the most part.
If you wanted to be really correct, you could generate three torque values for each axis at runtime: the desired input torque, the actual torque, and the max torque. Then you can just add up the torque values from each thruster normally, but if a thruster is already at its max, then you’ll have to divide its torque by the number of axes that it’s involved in at that moment. That’s how you’d get from input torque to actual torque.
It’s a pretty complicated problem, I suppose. I’m planning on doing this in my own project soon, so I’ll let you know how mine goes.
If it sounds frustrating, just remember you’re taking the easy way compared to real life. In real life, thrusters don’t even respond linearly and usually have a non-zero minimum throttle too! And you probably also have to worry about the system’s total feed pressure if the thrusters aren’t fed from independent propellant tanks…
One more thing I just thought of: you could even autogenerate the thruster force values based on their distance from the center of mass given the ship’s torque capabilities on each axis. That makes designing a new ship even easier.
In real life, thrusters don’t even respond linearly and usually have a non-zero minimum throttle too! And you probably also have to worry about the system’s total feed pressure if the thrusters aren’t fed from independent propellant tanks…