FreeSpace Releases > Scripting Releases

atomspheric flight

<< < (3/4) > >>

Nuke:
i dont like running with broke colision detection any more than you do. id rather replace player.Velocity with wvel, and have freespace run its collision detection and other velocity related checks. somewhere in freespace actual velocity is calculated based on velocity max, velocity desired, as well as all the damp, and accel settings. right after that is about where i need to tell the engine that player.Velocity = wvel.  then that velocity may be applied to whatever the game needs to apply it to, mainly collision detection, but some other things too like calculating your lead indicator position, ect. also id like to use that additive weapon velocity feature backslash implemented. as it stands weapons are totally unusable because they are too slow to keep up with the ship. from $simulation or $on frame seems my velocity is getting overridden after i set it, a new velocity is being computed based of freespace physics, and the velocity i want to use gets tossed.

all my flight model does this far is convert a bunch of physics data into a velocity vector. it essentially reads joystick data directly from the side, vertical and forward thrust values. checks a thrust table for how many newtons to produce, multiplies those values by toe -1 to 1 axis values and creates a force vector.

atmospheric density is computed based on y position and some atmospheric variables. angle of attack is computed based on angle relative to velocity (im assuming the air is relative to the mission grid, no wind).

that data i used to calculate force vectors for lift and drag seporately (though lift induced drag will be computed at some point and the calculations will need to cross reference eachother). some where in there a gravity force is computed based on gravitational accel * mass. the forces are added up and converted to an acceleration (force/mass).

that acceleration is then added to a vector called wvel. at this point wvel is represented in the same format freespace uses for .velocity, only it uses the old value so it conserves momentum. at this point i multiply the velocity by frame time to get the position i need to be at. id rather not do it but its the only way to test the flight model at the moment. id rather just apply the acceleration to player.velocity and if freespace's physics dont overwrite it it could be used without breaking anything.

what i need to fix it is a switch of sorts to disable freepace's physics calculation. a physics hook would be a good start. right after a new velocity is computed but before its applied to actual velocity. an override would completely kill freespace's physics calculation. that only need be done for a replacement physics model like this. alternatively you could introduce a switch concept. rather than putting a new hook everytime you want to get something to work. perhaps add a section to the scripting table for swtches. i could say perhaps $enable_freespace_physics: NO, similar to an override but independent of a corresponding hook. conditional overrides would be better, i could check if a particular mission has a physics profile, then if it does, switch off physics and use my system. otherwise lef freespace deal with it.

one thing i dont like about the new hook format is that you cant pass vars from say the $on frame hook to the $hud hook. i like outputting debug data to hud, which as far as i know can only be done through the $hud hook. also you cant access functions or vars from $on game init, so you got to put those in global hooks' $gameinit. also it seems yore not allowed to change variables defined in global hooks, you can however read them. it makes no since to have to recompute redundant data that was computed in another hook. though the namespace independence is something that can be useful. be nice if there were readGlobal("var") and writeGlobal("var", data) functions too allow passage of custom data from hook to hook, without killing the namespace feature.

Wanderer:
Hmm.. true.. But you could probably check the effect of the changes by standard trial and error method and get the needed 'tweak values' (multipliers) to get it work with your physics approach. For example 'corridor mode' uses velocity based 'movement barriers'. Sure it would have been simpler just to stick with position data but i wanted to preserve as much of the collision detection as possible.

Nuke:
its easier to put barriers in than to take them out. to build a proper flight model you need to start with newtonian physics and build up from there. but freespace likes to cap and damp your velocity. its a hard limitation to work around. il work on a solution once the physics model is fairly complete. if i get this thing to work completely it opens the door to some cool possibilities like ww2 air combat and olot of other things. a helicopter sim could be done on this model. uncomment the physics vars for the erinyes and give it a spin, i set that one up as a vtol demo. make some helicopter models and call it a mod :D

Herra Tohtori:
Looks very interesting.

But... I'm wondering.

How is the glide done in BtRL? Scripting or in-engine code?

If it's in-engine code, isn't that a way to disable FS2_physics calculations (or, well, part of them anyway) right there? The problem seems to be that FS2 tries to make it's own non-newtonian calculations on the background and you're trying to override them in the script with changing the position vector manually. But isn't the glide system already a possibility to enable effectively newtonian physics? Without the speed limit the BtRL currently has, that is. It has the ability to change ship's vector in the glide mode with thrusters, up to the velocity limit.

If it's done by scripting as well... well, perhaps adding atmo flight to that script would be a good place to start?

You will need to add control surfaces to enforce stability in that case, though, so that yawing doesn't make your ship fly sideways, since the FS2 physics won't be helping with keeping the ship flying towards where it's pointed at any more. Or have you done something else already to avoid ships flying sideways? I'm not so good at reading the scripts but I didn't notice anything like that.

The thing is, to add stabilizers realistically you would need to already put control surfaces onto them, and that would force you to include a way to change their lift coefficients with input controls, and a way for them to change the ship's attitude. Also, you need to take into account that the ship can have sideways AOA as well as pitch-oriented, and it affects the hull and control surfaces... essentially it affects drag also, because flying sideways increases the cross-section of the ship in the airflow, causes turbulence and other nasties like that... And even though I don't really know theg scripting system I can see it's not going to be a very coder-friendly process... :shaking:


Other thing I was wondering. Why don't you calculate the lift, drag and propulsion force vectors in relation to ship, bunch them all together and then convert that net force vector to velocity change vector (ie. acceleration) and only after you have the net force vector calculated, convert it to global reference frame co-ordinate system. That way you'd only need to do that conversion once. Gravity is done in general reference frame anyway so it doesn't need to be converted at any phase according to my understanding.

Of course, if the engine can get acceleration values from LUA directly, that would be the easiest way of doing this. Is that possible? It would make all the conversions from acceleration to velocity change (not to mention position change) redundant, the only thing you'd need to worry is changing the ship-related acceleration to global reference frame.


As to the physics of the equations, I don't see anything fundamentally wrong with them so far... apart from them being rough approximations of aerodynamics, that is. But in a game like this, calculating the airflow based on the model mesh is not really necessary, tabled aerodynamic values will do very well (MS Flight Simulator uses them as well, so you're in good company). If we want accurate aerodynamics we need to port the FS2 media to X-Plane. ;7 But for example, drag coefficient changes somewhat when you enter sub-sonic, supersonic and hypersonic areas of velocity, what with compressed shockwaves going on around the ship bouncing to and from the surface, and changing the viscous properties of the air a bit. But I daresay that's a bit more advanced physics modelling and should perhaps wait until you get the fundamental stuff working properly with the rest of the game.


I might add that I know next to nothing about the scripting system and what it allows so I'm just kinda spewing ideas around. They might not be possible at all, but then again, they might have some value. :rolleyes:

Nuke:

--- Quote from: Herra Tohtori on December 18, 2007, 09:17:52 am ---Looks very interesting.


--- End quote ---
thanks :D


--- Quote ---You will need to add control surfaces to enforce stability in that case, though, so that yawing doesn't make your ship fly sideways, since the FS2 physics won't be helping with keeping the ship flying towards where it's pointed at any more. Or have you done something else already to avoid ships flying sideways? I'm not so good at reading the scripts but I didn't notice anything like that.

The thing is, to add stabilizers realistically you would need to already put control surfaces onto them, and that would force you to include a way to change their lift coefficients with input controls, and a way for them to change the ship's attitude. Also, you need to take into account that the ship can have sideways AOA as well as pitch-oriented, and it affects the hull and control surfaces... essentially it affects drag also, because flying sideways increases the cross-section of the ship in the airflow, causes turbulence and other nasties like that... And even though I don't really know theg scripting system I can see it's not going to be a very coder-friendly process... :shaking:

--- End quote ---

alot of the quirks are due to a lack of rotational physics in my model. the intense slide you get when banking is due to the fact that there is no force resisting the turn. in a real aircraft, the rudder is really incapable of turning you due to the pressure forces around the fuselage. in a medium sized airfraft you could jam full rudder and only get a degree or two of yaw out of the plane a second. let go of the rudder and you instantly snap back to straight ahead as far as lateral angle of attack does. the aircraft wants its nose to the wind. its actually rather difficult to get a large lateral aoa in an aircraft.

pitch is a much more responsive because of the massive forces the lifting surfaces produce. i learned of a force known as the pitching moment which makes the front wing want to pitch down in response to airflow. so the horizontal stabalizers tend to produce a down force to compensate.   theres also the added leverage and the fact that the horizontal stabilizer has more control surface area than the rudder, main reason is pitch control is so much more important than rudder. the rudder is only useful in a coordinated turn, which is used mostly when you need to turn by a wide angle in a small amount of space. most of the force that contributes to the turn is from that force you see when you bank in my model. they call it your horizontal lift component. you use a combination of pitch and yaw to get the nose of the aircraft along the vector of the horizontal lift component. this allows faster turning than either yaw or pitch by itself.

so those are some of the things i must simulate. i could probibly calculate the yaw resistance based on the lateral aoa value and the yz cross section area. pitch resistance can be computed from the xz plane and roll resistance off of the wing and rudder area. rather than simulate control surfaces directly, il generate a rotational torque with force proportional to a percentage of the lift force produced by the wing. for yaw the force will be based on rudder lift (il probibly compute it in the same way i compute wing lift). a neutral airfoil always has a lift coefficient of 0 and 0 angle of attack. pitch force can be computed the same way. so i need to compute 6 and more forces in total, and turn the ship accordingly. so the torque model will be even more complicated to say the least. il probably start with basic conservation of angular momentum and newton force from rcs thrusters, then add in atmospheric interaction.


--- Quote ---Other thing I was wondering. Why don't you calculate the lift, drag and propulsion force vectors in relation to ship, bunch them all together and then convert that net force vector to velocity change vector (ie. acceleration) and only after you have the net force vector calculated, convert it to global reference frame co-ordinate system. That way you'd only need to do that conversion once. Gravity is done in general reference frame anyway so it doesn't need to be converted at any phase according to my understanding.

--- End quote ---

thats actually how i did it, if you go to external view there are lines which draw the force vectors. im using force vectors and not acceleration vectors because most of the equations give force values, thrusts are direct force values. gravity is the exception. i have to multiply it by mass to get a force. they are summed up as forces, to a combined force vector, which is devided by mass to become an acceleration vector which may be applied to velocity.


--- Quote ---As to the physics of the equations, I don't see anything fundamentally wrong with them so far... apart from them being rough approximations of aerodynamics, that is. But in a game like this, calculating the airflow based on the model mesh is not really necessary, tabled aerodynamic values will do very well (MS Flight Simulator uses them as well, so you're in good company). If we want accurate aerodynamics we need to port the FS2 media to X-Plane. ;7 But for example, drag coefficient changes somewhat when you enter sub-sonic, supersonic and hypersonic areas of velocity, what with compressed shockwaves going on around the ship bouncing to and from the surface, and changing the viscous properties of the air a bit. But I daresay that's a bit more advanced physics modelling and should perhaps wait until you get the fundamental stuff working properly with the rest of the game.

--- End quote ---

theres really no such thing as a simple aerodynamic model. there are alot of forces we know about and many we dont. also this is really the first time ive done anything with physics. i am not formally physics educated. so its gonna be crude. none the less ive impressed myself with how far its come, and i seem to have a natural aptitude for physics. i rather enjoy seeing what my ship is gonna do next. ive seen some rather comical flight characteristics thus far. things like considering geometry are out of the question. not with my skill level. im happy with crude cross sections and fantom airfoils :D

Navigation

[0] Message Index

[#] Next page

[*] Previous page