most of the maths are implemented already. granted there is room for refinement, but at some point it becomes overkill. the main thing that i need to implement is the multiple solid body simulation model (right now only a single solid body per object is allowed) which is just doing the same things on multiple objects and then do a summation of the forces on those solid body objects to get the forces for their representative object. this will provide the framework for things like angular physics control surface simulation.
a craft's physics model will be composed of multiple solid bodies (which can be setup as anything, fusalage, lifting bodies, wings, canards, stabilizers, control surfaces, props, rotor blades, engines, thruster quads etc). it is important to note that the solid body data structure is not geometry but the physics model of a part of a ship. they will each have mass, dimensional cross sections, coefficients of lift and drag and other parameters. they can be bound to subobjects and inherit their rotations, combined with an animation system this will allow for props, variable geometry, canards, and vectored engines. every solid body will have the basic aerodynamics properties, and possibly optional data for things like thrusters (though i may make this a different structure entirely) and control augmentation.
engine simulation should be something else entirely. it will likely be engine technology specific. i want to simulate performance regimes for air-breathing, rocket, and hybrid (engines with atmospheric and vacuum operational modes, like sabre) engines, perhaps also props and rotary wing propulsion (both with torque effects, and variable pitch, and the latter with retreating blade stall and swash) as well. i will probably simulate multiple engines as well. on top of all this id like to simulate a fly by wire system to make flying a ship with a multitude of thrusters and lifting surfaces a little bit easier.
its a lot of work and im not really sure i can commit any time into it. theres also the issue with the collision detection not playing nice with the flight model, and the other one with the ai not knowing how to fly in such a physics rich environment. this has brought up the issue of practicality. while the physics model is sound the interfaces with the other aspect of the game (collision detection and physics) are not so much. the engine likes to do its things in a set way, and when a script tries to change that it can have many unforeseen consequences.
for example the game likes to see the velocity in a pre-defined range, exceeding this will likely cause the actual velocity to be capped in the engine. there are reasons why such a cap are desirable. for example doing an operation on a very small number and a very large number may result in a floating point error. if you load the tethys mission with my atmospheric flight mod, the moon in question is very large for the freespace grid. it displaces almost the entire area of useable space. while a low orbit is possible any large impulse of thrust will throw you out to a point where the physics really start to get shakey. your ship shakes a lot because the accuracy has gone to distances of greater than a meter. so while orbital mechanics works on very small scales, it is not really all that playable. flight confined to the atmosphere is far more playable because velocities are kept well within a sane range.
of course you got games like orbiter that use moving frames of reference to allow the current state of physics variables to remain within acceptable limits, and when they exceed them, the frame of reference is altered to compensate. not quite sure how to implement something like that into freespace. it may actually pay off to come up with a new game engine entirely.
