Treat each thruster as a separate entity, that accumulates behavior into the larger ship entity.

Each thruster knows:

The ship's current velocity vector.
The ship's wanted velocity vector, based on the direction of the joystick.
The ship's running "sum of forces" vector, so that individual thrusters have a place to accumulate.
The thruster's range of motion.

So, any given thruster could determine if, by pointing it's nozzle in one of its available directions (within its constraints) and firing, it would add to the current velocity of the ship and make the resulting vector closer to the wanted vector. If so, it will fire, and add itself into the "sum of forces" vector.

Then, you just run through all the thrusters (maybe in order, from largest thruster to smallest, to simulate primary and secondary thrust systems), and they'll work out what combinations to fire at any given time.

So, as I see it, the problem is that you cannot position the thrusters in any direction/orientation you please - they could be anywhere. To get the ship to turn, you want to select the thrusters that do the most to get it to move in the desired direction, while doing the least work to move it off course. For example, say you just had two thrusters, one on the front of the ship (so that, if it was perpendicular to the cubical ship, the ship would move backwards) and one on the side, and each could move 20 degrees to either side. You want to move forwards. Therefor, we want to use the side thruster most, since we can angle it so it doesn't move us backwards, like the front thruster would. Of course, the ship, if symmetrical, could just rotate itself around to use the back thruster to move forwards. So all in all, the problem is that you need to know which thrusters would be most efficient to use for movement in the desired direction, while figuring out how to use the other thrusters to cancel out undesired acceleration in other directions.

Well, I guess it would all come down to averaging out what forces you could eliminate by firing each thruster.

Say we had three thrusters (I will do the graphic in 2D, for simplicity).

      T    SSSSS   TS   ST    SSSSS  We want to move northeast, and this graphic is oriented with north ^that way^*T = thruster*S = ship boundary

We don't have a thruster in a position that will allow us to move northeast just by firing it when it is perpendicular to the ship. We can rotate the left thruster 45 degrees and fire it, and that may give us the desired effect, except for the fact that it is on the side of the ship, rather than on the center.

Therefor, we need to work out how much force doing that would use, then how much force in undesired directions would occur, and then how much more force in any particular direction we would need. Anyways, we then go through each other thruster and compare how much force they could add/cancel out. The maths are too much for me ATM, so I will leave that up to you :)

Just don't make it more complicated than it needs to be. It is already plenty complicated. However, if you did use an ANN/some sort of genetic algorithm, then you might, if you did it right, be able to move the math off your shoulders. However, it would be a pain to train, I think, and not as precise or realistic (I doubt they would train the computers to fly the rocket through trial and error at NASA). Go for the math approach if you can, otherwise figure out an alternate solution.

I've had some other problems crop up with the game, so I'm way behind where I expected to be at this point. Anyway, I think I'll have to go for simplicity at this point and take Lederhosen's approach:

Quote:

Lederhosen Treat each thruster as a separate entity, that accumulates behavior into the larger ship entity. ... So, any given thruster could determine if, by pointing it's nozzle in one of its available directions (within its constraints) and firing, it would add to the current velocity of the ship and make the resulting vector closer to the wanted vector. If so, it will fire, and add itself into the "sum of forces" vector.

Any big downsides to doing it this way?

Fostburn, I think I'll do something similar to your idea of preset thrusters. When players' construct their ships (I'm nowhere near writing this part of the game) the computer will give them the option to automatically add thrusters, this should make things easier on the players. However, the control of the thrusters will be treated the same as if the player placed them himself.

Thank you for the input so far!

Dont you only need 2 thrusters for each axis of rotation?

          ^          .          .O----C----O..vO----C----O.         ..         .v         v

For each axis of rotation. You have symetric and asymmetric thrust applied for linear and angular accelerations. From those orientations you could rotate to any 3d heading. ( heh notice the deliberate chemists approach ;) )

True, but there are an infinite number of axises (sp?) of rotation. What if you are caused, perhaps because of a collision, to rotate along an axis that does not have a thruster on it? Then it becomes necessary to calculate the thrust from other thrusters not along the axis that is needed to readjust the ship.

Others have been suggesting ideas to determine this amount of thrust required from each thruster, and the orientation desired from each thruster (within the contraints of the thruster).

Quote:

Original post by Foxostro True, but there are an infinite number of axises (sp?) of rotation.

There are 4 axis in this universe, x y z and a foward-modifying time axis.

I think when you referred to infinite axis, you meant vectors, which would be true.

Quote:

Original post by Foxostro What if you are caused, perhaps because of a collision, to rotate along an axis that does not have a thruster on it? Then it becomes necessary to calculate the thrust from other thrusters not along the axis that is needed to readjust the ship.

Why not just build redundancy thrusters into the designs/models?

Putting aside for a moment all of the answers given to the original question, I want to ask why do you want a physics sim driving the motion of the space craft and then a controller to remove much of the nonlinearity of the control problem from the player? In my opinion, you're wasting a lot of effort.

(1) If you want to give the player the sense of actually controlling a free floating body, then you don't want the control architecture between the joystick and the thrusters. You just want a set of input controls for the player that map in some meaningful way (as to cover the complete thruster state space) so that the player can learn the correct control laws; or,

(2) You don't want the player to have to deal with a full physics sim (because you expect that either control is too hard for a human or too boring for a game), in which case, don't provide the full physics sim; just program a simpler relationship between joystick commands and motion.

Having said that, if you decide to go ahead with a control architecture to simply human control with the vehicles motion, then stick with fixed thrusters with fixed thrust capacity, rather than variable orientation thrusters with variable thrust capacity. Yes, you'll need a couple more thrusters for a given level of control accuracy, but you'll greatly simplify your control architecture.

Cheers,

Timkin

I've actually been getting by just fine mapping thrusters (with fixed thrust/orientation) to the QWERTY...etc keys. It really isn't as difficult to control as I thought it would be. I'll consider Timkin first suggestion.

Quote:

Original post by Anonymous Poster Just a thought, but don't real spaceships and satellites use GYROSCOPES to alter their orientation?

Satellites maybe, but not space ships, AFAIK. The space shuttle has manouvering thrusters at least. Flywheels or gyroscopes might work, but they have that annoying tendency to resist rotation. IMHO thrusters is the way to go if realism is the goal.

@Timkin:
I'm not the OP, but these are my reasons to use thrusters:

In my game I want to use thrusters to get realistic handling of the ship, but they'll be computer controlled to make it easier for the player to steer the ship.
If the thrusters are placed differently on different ship models, or if one is destroyed then the handling of the ship will change. I could "cheat" and use matrix rotation around the center of the model or something, but it's not much harder to use forces on a rigid body so I'll do that. At this time I'm not planning on letting the thrusters themselves be rotated so the explaination I made a few posts ago shows how simple it is to map joystick movements to thruster power.

By using thrusters it's also simple to create a jet of gas from the thrusters when they're engaged, which makes it look realistic as well.

Alien ships could have another form of control and the lack of thrusters will help to set them apart.

I am trying to go for the exact same effect, frostburn.

It occurrs to me that even if I force players to control the ship's thrusters manually as Timkin said in #1, I still have to allow AI ships to figure out how to steer.

Here's an idea I had today:
Precompute a table of all combinations of thrusters that could fire and the axis of rotation (exoskeletal_ninja: some arbitrary line) about which the object would be rotated should this combination be used. When I need to steer the ship, search this precomputed table for the comination that most closely matches the axis of rotation specified by the pilot (player or AI). Then, fire the thrusters for the calculated length of time necessary to rotate the ship into the specified orientation.