Hard Light Productions Forums
Off-Topic Discussion => Programming => Topic started by: Nuke on January 21, 2010, 09:55:15 am
-
i kinda hit a roadblock while working on my atmospheric script. by adding conservation of angular momentum, i made flying in the atmosphere almost impossible because drag forces arent stabilizing the flight model (in other words i need to simulate a tail). there are a whole bunch of other forces/torques i want to consider as well, control surfaces, pitching moment and so on. right now all the forces act on the center of gravity, and the only way i have of changing my angular momentum is with a set of assumed rcs torques. this works for space flight, but in the atmosphere it doesnt work so well. what im thinking of doing is specifying multiple sets of airfoil properties (one for each wing, horizontal and vertical stabilizer, canard and whatever else) per ship each with their own properties. using those properties to computing lift, induced drag, pitching moment and other forces/torques i forgot to mention. these fores would act upon the center of the airfoil. for each airfoil i intend to produce a total force produced by that foil's interaction with the atmosphere, as well as a pitching moment.
what i dont know how to do is apply all those force vectors of varying origin to the whole model as a single ridgid body, and then figure out how much of theese forces become linear force, and how much becomes angular force (torque). once i have theese forces i can convert them to accelerations and apply those to the momentum (angular and linear) of the ship every frame. ive been reading info on physics for at least a week and i still havent made any headway. physics gurus unite!
-
I could give you some information based on my best guesses, but you are likely best served by Thaeris. Other than that, I cannot provide you with actual physical stuff with respect to airflow (I don't bother to learn them for this occasinon), but I can probably help you with forces and torques coming from different positions. However, they might not be related to actual physical properties, as I'm not educated in aerodynamics.
-
Well, uh, each force can be divided into two components, one that is directed towards the center of gravity and causes linear acceleration, and one that acts rectangularly in relation to the direction to the center point and works as moment and causes angular acceleration.
Like this:
(http://img62.imageshack.us/img62/6895/forceisstrongwiththison.png)
But, because you have forces that affect different points in the model, you can't immediately combine the forces and then calculate their sum. You have to first separate each force into angular and linear component, THEN combine linear and angular components to the net linear force and net moment affecting the body.
EDIT: And, of course, you should probably break each moment force into three components (pitch, roll, yaw) for easier handling. Since pitch, roll and yaw moments of inertia tend to be very different in most non-symmetric objects, directly lumping all moment forces together would be mathemathically annoying and wouldn't probably give correct results unless you were working with a perfect sphere.
-
I could give you some information based on my best guesses, but you are likely best served by Thaeris. Other than that, I cannot provide you with actual physical stuff with respect to airflow (I don't bother to learn them for this occasinon), but I can probably help you with forces and torques coming from different positions. However, they might not be related to actual physical properties, as I'm not educated in aerodynamics.
I'm glad to know I'm so highly thought of. Unfortunately, I've still got a rather long way to go in terms of the sciences and programming.
...What I can do, should you be interested, is try to get you in touch with some former professors of mine... who happen to be doctors of engineering. However, I'll certainly look into what I can. :nod:
-
I could give you some information based on my best guesses, but you are likely best served by Thaeris. Other than that, I cannot provide you with actual physical stuff with respect to airflow (I don't bother to learn them for this occasinon), but I can probably help you with forces and torques coming from different positions. However, they might not be related to actual physical properties, as I'm not educated in aerodynamics.
the airflow mechanics i pretty much have worked out to the point where i have the forces ready to go, my problem is what to do with them. my only aerodynamic problem right now is dealing with supersonic flight, but i dont think thats something i cant figure out. ive already written functions to determine all major forces dealing with aerodynamics.
Well, uh, each force can be divided into two components, one that is directed towards the center of gravity and causes linear acceleration, and one that acts rectangularly in relation to the direction to the center point and works as moment and causes angular acceleration.
Like this:
(http://img62.imageshack.us/img62/6895/forceisstrongwiththison.png)
But, because you have forces that affect different points in the model, you can't immediately combine the forces and then calculate their sum. You have to first separate each force into angular and linear component, THEN combine linear and angular components to the net linear force and net moment affecting the body.
EDIT: And, of course, you should probably break each moment force into three components (pitch, roll, yaw) for easier handling. Since pitch, roll and yaw moments of inertia tend to be very different in most non-symmetric objects, directly lumping all moment forces together would be mathemathically annoying and wouldn't probably give correct results unless you were working with a perfect sphere.
thats the best explanation ive seen so far (in that i understood it and it didnt make my neurons screem in terror at me to take more asprin). computing forces by plane kinda fits into the way im already doing things. so i can have x torque, y torque, and z torque about orthagonal axes in the models frame of reference. this kinda also lets me do complex thruster modeling, though i kinda want to keep it simple on the modding side, so that modders dont need to have a degree in aerospace engineering to setup their ships to fly.
-
...And then you need to take into account that torques that cancel each other will actually become a linear force (as in airplane's wing tips both torque the wing upwards, but since it's a rigid structure it ends up becoming upward force).
-
now my brain hurts
-
Hmm.
Actually, refreshing my memory, you can just pretty much sum all the force vectors together to determine the linear net force. Haven't done rigid body dynamics in a while.
ou still need to dissect the torque out of each individual vector in relation the three major rotational axes, and then you have the necessary details for determining the necessary values for the simulation; linear and angular acceleration around pitch, roll and yaw (which probably all have different specific moment of inertia values) at the time.
When you know the original position, linear and angular velocities at t0, you can then predict the state of the motion of the body at t+dt, and so forth...
Determining a suitable dt value would be problematic. The smaller the value, the more accurate and CPU intensive simulation you get.
...So, are you going to take propellant/fuel mass loss into account in the simulation? :drevil:
-
i figure once i have figured out the torque about the 3 major axes, can i just stick those in a vector and transform it by the (inverse)moi matrix that is determined when a model is converted? linear forces would be compared against mass. i dont want to convert the forces to acceleration immediately, as i still have gravity to consider. frametime pretty much covers the time dimension. accelerations are multiplied by the length of the frame (technically the previous frame) before being added to the momentums. the momentum and angular momentum are also multiplied by the frametime to determining the new position and orientation. so pretty much all i need to do is simplify the forces before doing that.
as for fuel, maybe. i kinda also want to also consider ordinance weight. every weapon has a mass value, so i can just look at the number available and multiply. the mass would be added to the ship's dry mass. im not sure how i will modify the moment of inertia based on that though. engine modeling is also something i want to do, have different types of engines or different engine performace in the atmosphere than in space. perhaps by supplying booster fuel or air breathing engines for atmospheric flight that would produce more power than usual, sort of a "launch configuration". performance for air breathing engines would relate to the atmospheric density, speed and other factors.
another idea is to compute recoil forces as well, get that a-10 stall when firing effect. supersonic modeling is one more idea. drag reaches a peak around mach 1.2, then begins to fall at around mach 1.3, because once a shock cone is established, a local wind velocity begins to manifest. i definately want to do this for weapons, since supersonic bullets and missiles slow down too rapidly due to extreme drag, producing a fire backwards effect.
-
i figure once i have figured out the torque about the 3 major axes, can i just stick those in a vector and transform it by the (inverse)moi matrix that is determined when a model is converted? linear forces would be compared against mass. i dont want to convert the forces to acceleration immediately, as i still have gravity to consider. frametime pretty much covers the time dimension. accelerations are multiplied by the length of the frame (technically the previous frame) before being added to the momentums. the momentum and angular momentum are also multiplied by the frametime to determining the new position and orientation. so pretty much all i need to do is simplify the forces before doing that.
For the sake of this purpose, gravity is one of the vectors that you should already be taking into account when determining linear acceleration. It just always happens to have uniform direction and no torque effect on a body, so it's an easy addition.
Stuff like velocity dependant air resistance forces in non-standard flight attitude (flying sideways, or belly-first, or backwards), and transition from lift to stall condition would probably be the most challenging things to get right, and that's practically required for any semblance of accuracy for aerobatic maneuvers like sideslips, tailslides, autorotation (spins and flat spins) or negative stalls like the ones you can get in IL-2 when you pitch down and cross the rudder and aileron controls to either direction, depending on the propeller rotation direction, which results in a fairly controllable negative stall, and a negative flat spin which means you're flying the cockpit canopy first, with about -90 degrees angle of attack. It's an excellent maneuver for quick energy bleed, and a purely evasive/aerobatic one. With good timing you can almost make a hammerhead maneuver with some planes, which is all sorts of awesome....
as for fuel, maybe. i kinda also want to also consider ordinance weight. every weapon has a mass value, so i can just look at the number available and multiply. the mass would be added to the ship's dry mass. im not sure how i will modify the moment of inertia based on that though.
Apply a multiplier to the torque to achieve desired effect based on the configuration. That way you would require a pre-determined multiplier table for each possible loadout configuration.
On the other hand that doesn't allow real-time fuel consumption weight loss and such effects. You'll need real time tracking of mass and it's distribution for that, so you can take the model's empty weight as the base value, and then do a simple MOI calculation real-time to see how much each piece of loadout increases the MOI of the total ship. Calculating MOI is not that hard if you just use distance to center of gravity and use a simplified model where each piece of loadout is attached to a single hardpoint in the model.
engine modeling is also something i want to do, have different types of engines or different engine performace in the atmosphere than in space. perhaps by supplying booster fuel or air breathing engines for atmospheric flight that would produce more power than usual, sort of a "launch configuration". performance for air breathing engines would relate to the atmospheric density, speed and other factors.
If I may suggest, make the basic physics work first before you start fiddling with HOW the thrust vector is produced... that kind of thing would be easy to add later on as it doesn't have too much to do with the flight dynamics model.
another idea is to compute recoil forces as well, get that a-10 stall when firing effect. supersonic modeling is one more idea. drag reaches a peak around mach 1.2, then begins to fall at around mach 1.3, because once a shock cone is established, a local wind velocity begins to manifest. i definately want to do this for weapons, since supersonic bullets and missiles slow down too rapidly due to extreme drag, producing a fire backwards effect.
The A-10 doesn't stall when it's firing. At low speed the combustion gases from the gun can end up in the jet engines which can cause an engine flameout or stall, but really, the recoil force of the GAU-8 Avenger is greatly exaggerated - it doesn't notably slow down the jet. Besides, stall is not a condition that depends on air speed, it's only dependant on angle of attack (and wing profile). The reason why slowing down too much can result in a stall is that the lift is a result of airspeed and angle of attack; when airspeed is decreased, angle of attack must be increased to produce the required amount of lift for level flight. If the stall threshold angle is surpassed, then the wing stalls and lift is lost, but stall itself doesn't depend on airspeed.
The rest, though, is interesting. Truely ballistic primaries would be incredibly awesome. I'm just beginning to worry about how many vectors and objects can modern computers handle during one frame time, and how will the collision detection work.
-
right now im cleaning up the code trying to make everything more organized. functionizing a lot of complex code thats repeated for both weapons and ships. i also have to idiot proof some functions so they will not crash the game if something important is omitted from the physics.tbl. also want to add some features from the cockpit demo (mainly advanced input tweaks). then i will try to implement simple drag and control surface modeling. once thats done il post a teaser release and then work on advanced thruster and airfoil modeling.
-
you know angular representations are not going to work very well, you should be using a matrix, a 4X4 matrix. otherwise you are going to get gimbal lock.
-
that usually not a problem unless the rate of change for a frame is insanely large. gimbal lock will always manifest with matrix multiplication if any axis wants to rotate more that 90 degrees in one step. while in a per second format this would cause issues, but youre usually dealing with a period of time roughtly 1/60th of a second (the actual number depends on the return value of the frametime function). so that 90 degrees change every second is reduced to 1.5 degrees every frame. you could probibly rotate as fast as 2 or 3 rotations a second without gimbal lock. of course the faster you go the lest precise the rotation. i could simply cap the maximum, make it so that thrusters wont fire in a specific direction if the rotation rate in that direction is more than x degrees per second. only forces, accelerations and momentum will be stored in a euler format. a force is usually converted to an acceleration and then scaled by frametime before it gets applied to momentum, so the change every frame is small. momentum is what you cap, the "flight computer" simply locks you out if you try to do something stupid, like turn the ship beyond its "structural limits". when this is applied to the orientation of the ship, it is again multiplied by frametime, so the rate of change is small. here is where its converted to a 3x3 matrix and the current orientation matrix gets multiplied by it.
ive already implemented angular momentum and it works fairly well, even at insane rotation speeds. once i implement my virtual fly by wire system, this will be capped, and moving the joystick will indicate the desired rate of rotation (in relation to a specified frame of reference, which for now is the center of the level) instead of how much thrust to apply. the capped rotation rate will probibly be settable in a per ship basis, it would definitely want to be higher on an interceptor (ship with low mass) than a bomber (ship with high mass). some would argue that capping the rotation rate is not newtonian, but it is a common practice in high end military aircraft to lock out the pilot when they try to exceed the maximum angle of attack (b2), maximum g load (dont kill the pilot), or some other design tolerance. the imortant thing is that its a pilot lockout, and not a violation of the laws of physics.
-
You may be able to gander some code in these sources for clues about how to handle the moments of intertia (keeping in mind we're talking about Java in one case and C++ in the others, presumably). All this stuff is open source, I believe.
http://www.flightgear.org/features.html (http://www.flightgear.org/features.html)
http://code.google.com/p/exoflight/ (http://code.google.com/p/exoflight/)
Good luck! :yes:
-
Heard of FlightGear before, but never used it as I've got X-Plane.
...Exoflight though... that's a new one. :nod: I know Herra's brought up Orbiter several times (I've only been mildly interested in getting into that one, but perhaps I should at some point), but this is something I've never, ever, heard of...
...I'm downloading this now, actually. Hopefully it's more moddable than Laminar Research's "Space Combat," thus allowing me to get that realistic spacecraft performance I crave... ;7
-
for some reason I can't help but think there will be some artifacts, but if you say it's working then I guess I'm just overly paranoid
-
for some reason I can't help but think there will be some artifacts, but if you say it's working then I guess I'm just overly paranoid
theres not a doubt in my mind that there are artifacts. its just for now they appear to be very small. there will be situations however where a frame will run much longer than expected, and this is where the biggest of those artifacts will occur. you could probably get around this with efficient use of graphics so that slowdowns are less common. or detect situations where gimbal lock will occure and deal with it for that frame, perhaps cut up the rotation and apply it over the course of several frames.
-
theres not a doubt in my mind that there are artifacts. its just for now they appear to be very small. there will be situations however where a frame will run much longer than expected, and this is where the biggest of those artifacts will occur. you could probably get around this with efficient use of graphics so that slowdowns are less common. or detect situations where gimbal lock will occure and deal with it for that frame, perhaps cut up the rotation and apply it over the course of several frames.
In my opinion, it would be far better to use a fixed dt value and interpolate the results to the next frame position from that than using the time between frames as dt value. Frametime is after all dependant (and correct me if I'm wrong) on not only the physics running smoothly, but also all the other stuff on the screen. At 1/30 s dt the simulation could be quite imprecise already in certain conditions, not to mention occasions where frame rate drops to 10-15 FPS. If you set dt to 10 ms, it would give a 100Hz fixed precision on the physics regardless of the actual frame rate on display, and it would be more consistent and logical in handling responses.
-
that would make the program structure very complicated, assuming its even possible at all. the clock is where it is when the lua simulation hook runs, which may be every 1/60th of a second or 1/10th of a second since the last time it was run. you could maybe handle it with a timestamp, if the time since the last time physics was handled is larger than the 10ms interval then physics would run, but theres no guarantee it would be exactly 10ms, it could be 12 ms, and dt would be just as variable. in a multithreaded engine that would be a very good idea, physics would run independant of the rest of the game, and the time it takes to run physics is usually proportional to the number of objects, so a flat dt could be possibly be established. if that was the case then interpolation would be easy. its a good idea, but im not sure how to pull it off with the current engine.
-
Here are a couple of things to check if you haven't already:
http://en.wikipedia.org/wiki/Flight_dynamics#Lateral_modes
http://en.wikipedia.org/wiki/Directional_stability
No doubt you have considered them. What I would like to point out is the surprising amount of components, sometimes hard to notice, but obvious after it has been noted. Wind with a small deviation angle with respect to aircraft velocity vector can for example, make tail to work as a wing and to push aircraft sideways. This is somewhat different from perpendicular wind that works on the whole exposed aircraft hull. Depending on the aircraft mass distribution, moments will cancel each other, or a yaw will develop. It will also add perpendicular component to airframe's velocity vector. End result is the same, but mechanics are slightly different.
Note that the component properties may depend on the local velocity, like spin or inverted spin. Be advised that the wing profiles cause different lifts (and drags!) depending on the velocity. Higher velocity adds lift and aircraft has to apply compensate with the tail. One of the most glaring examples is the Valkyrie bomber which had to change its wing profile quite drastically after certain speed (Mach 2?).
Is your simulation supposed to work as an ideal airplane or as a more conventional airframe with all flight dynamics included? Phogoid motion or automatic trims?
But again, this is after brief reading of the subject by somebody who has never read a book of aerodynamics.
-
Other really fun things to consider:
-shockwaves - anything moving at trans-sonic speeds will already encounter Mach+1 airflow velocities at some points on their wings and fuselage, even if the indicated airspeed is less than Mach 1. Propeller blades are a good example of this; it's also the reason why helicopters are fundamentally limited to velocities lesser than Mach 0.5. Thankfully, FreeSpace doesn't have propellers... so propeller torque will not need be taken into account. :p
-compressibility
-buffeting
-vortices (induced drag/wing tip vortices/wake turbulence), and I'm not talking about the difficulty of modeling turbulent airflows. As an example, a very large portion of lift generated by the Concorde's wings is due to large stable vortices on top of the wings reducing the air pressure there. So lift is not exactly always just a function of angle of attack and airspeed in laminar airflow...
-shifting of aerodynamic balance (center of pressure) in different velocities. For example Concorde dealt with this by shifting it's center of gravity accordingly by fuel transfers.
-stress factors depending on flight state; overspeed and pulling over-g's comes to mind first. You'll likely also want to implement blackouts and redouts somehow. For example, even if the ship itself can handle re-entry, it's unlikely that the pilot can handle the rapid deceleration if the ship were to, say, turn sideways or enter uncontrolled spin.
Have fun. ;)
-
lots of things to model. right now im working on basic flight dynamics. seeing as this is an attempt at an aerospace engine, i will most likely need to consider transonic physics, otherwise it may be impossible to reach orbital velocity (not that you would have enough space without the ability to translate the entire scene, keeping the player in the "happy zone" of floating point math). i dont want the flight model to be too simple, but on the other hand i dont want to get too complicated.
ive given some thought to dealing with tail physics. my aoa computation also figures out the aoa of the tail, which is essentially a neutral airfoil with a Cl of 0. for every degree an airfoil is rotated in relation to oncoming wind (regardless of its level flight Cl), its Cl increases or decreases by about 0.11 (until the upper or lower stall angle is reached), so i should be getting a lateral lift force from the tail if i choose to simulate one. a control surface on that thail could also change the Cl. of course i dont want having a rudder be the only possible way to induce yaw, you could accomplish the same kind of motion by inducing drag or with a tail rotor for example.
-
you could recenter the 'happy zone' every time the player's center gets too far away from the origin.
-
that was the idea. something like that would best be implemented at engine level though. you would have to transform every object's position, and its old position so you dont screw up collision detection. of course then youd have to make sure this doesnt confuse the ai or weapons (missile homing position would change too so that would need to be translated) or cause artifacts in gauges and such. it doesnt take a stretch of the imagination to think of things it could potentially screw up. script doesn't (and shouldn't) have enough access to tie up all the loose ends. as it stands im gonna end up taking a good look at the engine physics anyway, in order to make physics more moddable. modularization would be a good start. once a translate scene function is implemented, then the scripting or events system should be able to use it. im sure there would be uses for this kinda thing other than physics.