Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Backslash on May 02, 2007, 05:56:24 pm
-
Anyone remember my "The poor man's substitute for Newtonian Physics (http://www.hard-light.net/forums/index.php/topic,40547.0.html)" test build last year?
It is finally done! :) Committed to CVS and uploaded as a build here:
http://files.fringespace.org/bs/build20070430.rar
So for the people who don't know what this is... I've rewritten Gliding so that thrusters will slowly change the vector of gliding. This gives a semi-Newtonian feel which gives quite a new interesting experience. Go read the linked post for how to get it to work, if you don't already know how to make ships glide and have lateral thrusters.
There's also a new table entry (under Glide: YES) called +Max Glide Speed:
It caps the maximum speed while Gliding so that you're not going at ludicrous speeds. It defaults to max afterburner speed, but try higher values if you want ;7
Try it out, and please let me know what you think!
P.S. Please note that this is a HEAD build, and any HEAD build can corrupt your pilot file, and only that particular build will be compatible with that pilot. So make a new pilot for just HEAD builds! (And don't worry, it won't destroy pilots you don't load.)
-
oh goodie. this should hold me off while i wait for real newtonian physics. hint hint
any changes to the controlability? such as being able to work the throttle while in glide mode?
-
So wait.
If you don't have +Max Glide Speed: in the table, does it still cap the speed?
-
Is this compatible with BtRL?
:drevil: :mad2:
->goes to try...
...well, it doesn't seem to work with it, but this will definitely make things more interesting with normal FS2_Open...
-
For testing purposes, perhaps.
You'd be a fool to try actually running the game on it though.
-
any changes to the controlability? such as being able to work the throttle while in glide mode?
Yes, throttle works during glide now. :)
If you don't have +Max Glide Speed: in the table, does it still cap the speed?
Yes, it defaults to a cap of your maximum afterburner speed.
Is this compatible with BtRL?
Well it's a HEAD build... I've gotten it to work with BtRL by commenting out all the $Max Debris Speed lines in objecttypes.tbl . But it won't work in multiplayer unless all players have the build (afaik), and it's missing something about cap_object_updates which will make it more laggy.
You'd be a fool to try actually running the game on it though.
:confused:
-
Yes, it defaults to a cap of your maximum afterburner speed.
Shouldn't it default to no cap?
-
I thought about that (and discussed it with the BtRL team) and my reasoning ended up as this:
In what situations is Glide enabled for ships? 1. in a campaign designed for it, and 2. when people add it themselves for fun.
For 1, the mission/mod designers can set the cap and design the mission to accommodate. Most (so far) are designing their missions with the generally accepted notion that Alpha 1 isn't going to be able to hit relativistic speeds :D ...imagine The Romans Blunder otherwise. So max afterburner speed fits best with the rest of Freespace accepted 'realism', as silly as that sounds (not exactly sure how to say it). Now that this option is available, maybe we'll see missions/mods/campaigns with it in mind, someday.
And of course, for 2, people can set the caps to whatever they feel like, since they're already editing the tables anyway. ;)
Oh, and just thought of this -- AI can't use glide, so that makes things a bit more tricky... unless "it's Alpha 1 vs the world", or multiplayer-only, missions are designed with wings in mind. I mean, sure, you usually take off on your own anyway, but IDEALLY... :p you know what I mean?
-
a force glide option would be cool. probibly better as a fred flag because missions in newtonian will need to be designed for it. a ship flag for using thrusters would probibly e a good idea too, so that you wont break the original glide functionality for mods that might perfer it (fringespace for example). also for screwing around's sake, can you make it so that the cap is unlimited if the flag is set to say -1.
are you using force to mass conversions to determine proper acceleration rate or are there just some arbitraty numbers being thrown int? i only ask because my piss poor lua implementation of newtonian assumed ship thrust to be in newtions and mass in kilograms, which didnt work too well because it takes thousands of newtones to accelerate a fighter aty a resonable rate. i thought of going to a newtons to grams aproach, which whould assume the force output of the engines was read as kilonewtons . the mass was actually read directly from the pof. it didnt really work out because i actually had to set the position manually, which broke collisions. also i had the game try to apply its own physics on top of maie which caused some jumpyness in the motion. im gonna screw around more with newtonian in this retro 3d game im working on in c++.
-
You'd be a fool to try actually running the game on it though.
:confused:
Nothing personal about your build. Just that HEAD is not currently in the state where I'd recommend anyone use it for playing games rather than just testing them. :)
-
I thought about that (and discussed it with the BtRL team) and my reasoning ended up as this:
In what situations is Glide enabled for ships? 1. in a campaign designed for it, and 2. when people add it themselves for fun.
For 1, the mission/mod designers can set the cap and design the mission to accommodate. Most (so far) are designing their missions with the generally accepted notion that Alpha 1 isn't going to be able to hit relativistic speeds :D ...imagine The Romans Blunder otherwise. So max afterburner speed fits best with the rest of Freespace accepted 'realism', as silly as that sounds (not exactly sure how to say it). Now that this option is available, maybe we'll see missions/mods/campaigns with it in mind, someday.
And of course, for 2, people can set the caps to whatever they feel like, since they're already editing the tables anyway. ;)
Oh, and just thought of this -- AI can't use glide, so that makes things a bit more tricky... unless "it's Alpha 1 vs the world", or multiplayer-only, missions are designed with wings in mind. I mean, sure, you usually take off on your own anyway, but IDEALLY... :p you know what I mean?
Yes, but there's no reason NOT to have a setting for no cap. Either have it default to no cap, or perhaps use Nuke's suggestion of -1.
There's no point in forcing a cap on everyone.
-
Why not just set the cap to 1000000 or something, since by the time you're going that fast you'll have already hit the edge of the mission and died.
-
Hackish solutions like that generally only lead to problems later on. Also, being able to check for an integer value of -1 is a whole lot more efficient than needlessly performing multiple floating-point calculations to determine the magnitude of the vector of the ship's velocity.
Plus having a specific value that means that the ship does not have a maximum speed in glide mode lets the code know that that's exactly what was intended, and a massive value isn't a typo, and tells it that it can make any other optimizations as needed.
-
also, about the edge of the mission, any way to make it much further away. such as replacing world space doubles with double doubles :D
-
Ah, I see now karajorma. Ok, I mostly agree. Fortunately the sort of people that bother to check out such a thread with this kind of title are not the newbies :) ....so far
Good idea, the -1! Yeah, I'll do that. Hadn't even thought about checking for negative numbers, whoops.
No force to mass conversions... just an arbitrary value I settled on after much testing. Yeah I know, but I figured in "semi-realistic" Freespace terms the ships would have the right engines that had the proper thrust to propel them... so that's what $Forward accel is for. Whatever that means :D
The arbitrary value happens to be 0.16 * 1+(the acceleration time constant, whether forward or side or afterburner) if you must know. I'm open to suggestions to how to make it better, but last time I posted the math people ran screaming from the thread :p
Ludicrous speeds are fun, but past a certain point collisions stop working right.
I'm pretty sure the edge of the mission that makes you explode is a much smaller number than the actual edge of a double.
-
Ah, I see now karajorma. Ok, I mostly agree. Fortunately the sort of people that bother to check out such a thread with this kind of title are not the newbies :) ....so far
In the years I've spent troubleshooting on this forum I've learned to never assume what a newbie might do. You'll come a cropper every time. :D
All it would take is for instance HT mentioning on the IRC channel that he's been testing the new feature mentioned on the HLP thread and I could easily see a few people trying it out.
Right now they'll crash on the table changes, decide that the build doesn't work for them and give up most likely. But once that error is fixed.....
:)
-
IMHO wih my admittedly limited programming experience and total lack of any certain knowledge about the inner workings of the code, the likely reason why the collision detection works...
(could be)
...is that it checks for actual bounding box intersection, coupled with the fact that it probably moves objects by actually very small - but finite and quantative - distances multiplied by a speed factor. So when an object has a massive velocity it means, that the very small minimum distance an object can be moved is actually multiplied to be greater than actual models.
-
its sorta like that but the box subdivides and then checks which divided section the projectile is in, and it repeates untill the box is so small that its position is pretty much spot on with the projectile. but if you have a situation where you, your target, or your shot is moving about a hundred meters every frame, then that meathod doesnt work so well. this can be fixed with extra math of course, draw a line between the current position and the last position, and check every point along that line for a colision. this is actually alot of math. especially considering all those points have to be transformed into model space (or is it world space) to see if they hit any bounding boxes.
No force to mass conversions... just an arbitrary value I settled on after much testing. Yeah I know, but I figured in "semi-realistic" Freespace terms the ships would have the right engines that had the proper thrust to propel them... so that's what $Forward accel is for. Whatever that means :D
The arbitrary value happens to be 0.16 * 1+(the acceleration time constant, whether forward or side or afterburner) if you must know. I'm open to suggestions to how to make it better, but last time I posted the math people ran screaming from the thread :p
im not gonna really make any suggestions. the freespace engine isnt really cut out for newtonian physics at this time. not that i dont want them, i do, it just seems we need a bunch of other things for it to work. if collisions dont kill you the edge of the mission will. then again the math for newtonian is much simpler than what freespace uses. it starts getting confusing to mod when none of the values in the tables work anymore. you have to know 2 things to determine how fast you can accelerate, how much mass your ship has, and the force output of your engine.
since force = mass * velocity, then force / mass tells you how much energy to add to your current velocity every second. force and velocity are both vectors and so must be handled as such. you determine your velocity by adding all force vectors. each force vector is essentially your engine normals backwards, times the amount of force that engine is producing at the time. then divide the total vector by the mass of the ship, then divide again by the length of the frame, and add the resulting vector to the velocity every frame. at least i think thats how it works. please correct my physics anywhere i may be off. i need to have this nailed for a little something im working on.
-
Ahoy, long post ahead! Steer clear to avoid imminent headplosion...
sence force = mass * velocity, then force / mass tells you how much energy to add to your current velocity every second. force and velocity are both vectors and so must be handled as such. you determine your velocity by adding all force vectors (normal diretion * amount of force). then divide the total vector by the mass of the ship, then divide again by the length of the frame, and add the resulting vector to the velocity every frame. at least i think thats how it works. please correct my physics anywhere i may be off.
Replace velocity with acceleration... or, rather more accurately, replace force with momentum.
Also, energy actually has not much to do with kinetics, as surprizing as it may sound. Momentum is way more fundamental here. It's not even necessary to invoke the concepts of energy and/or acceleration if you only need to simulate movement in three spatial and one temporal dimension, but I suppose that's more of a matter of huge overhaul and the fact that after that it would be much more difficult to implement FS2-like behaviour again, unless there's two movement calculus choices in the code, perhaps another one activated via "newtonian" flag or somesuch. Anyhow...
Since
F = dp/dt
p = momentum vector, t = time, d=delta ie. change of.
and dp = m * dv (v = velocity vector)
and dv = ds / dt (s = spatial dislocation vector)
we got ourselves here a fancy little equation that resolves like this:
F = m * dv/dt
dv = F/m * dt
Int dv = F/m Int dt
v = F/m * t + C , where C is integration constant.. further analysis reveals that C = v0, ie. the velocity at the time when the analysis started.
-> v = F/m * t + v0
ds / dt = F/m * t + v0
ds = (F/m*t * + v0) dt
Int ds = Int (F/m * t + v0) dt = Int F/m * t dt + Int v0 dt
-> s = ½ * F/m t^2 + v0*t + D
again, D is an integration constant that will, for our purposes, be suitable to assume to be the "zero vector", or the starting point of the spacial dislocation vector...
-> s = F / 2m * t^2 + v0*t + s0
There. Gods damn that was a lot of brackets to get the vectors announced correctly with bold letters, for sake of sanity please don't quote that...
Obviously, the toughest part is to make that work in [x,y,z,t] space, which means you need to hacksaw all vectors to three dimensions, but that's trivial number crunching at this stage... for example this is one common way to do it:
i, j and k are unit vectors with length of 1 and they are all perpendicular to each other, defining a space co-ordinate system (there are fancy mathematical marks to say that but I can't bother to look for them...) For the sake of sanity, let's say that vector i defines so called x-axis, j defines y-axis and k defines z-axis. The co-ordinate system is right-handed, which means that when X axis points to right, y axis points away from you, then z axis points upwards.
Now we can define that
s = dxi + dyj + dzk
s0 = x0i + y0j + z0k
v = |s| / dt
x0, y0 and z0 and v0 are the x,y,z and v from the previous pass.
Note that the values that are actually fed into the program that crunches this bastard are mass, force vector, initial co-ordinates and initial velocity vector. mass is defined by table value (and quite possibly fuel and weapons on board :drevil:), force vector is defined by attitude and controls input.
Initial co-ordinates and initial velocity are translated from the previous pass - the end results of previous equation pass are simply moved to form the data basis of the next equation pass. Obviously, the first pass of the equation will need to aquire arbitrary values - location and initial velocity, given by the mission designer. From there, the simulation can proceed quite accurately.
Now, the only thing needed to define is the time change between two equation passes. Basically, the smaller the time shift, the better the accuracy. Real space likely uses Planck's time as dt, but we don't have that kind of resources now do we (no we don't). So we need to define how good accuracy we want. I truly have no idea how good the accuracy should be, but I have a vague opinion that it really definitely doesn't need to be any better than dt = 1/1000 second. That would define the ship's location thousand times a second, which is plenty much and well enough to fool human senses to think it's truly newtonian (when instead it's just a numerical approximation...).
...obviously, that's just the location part. Aquiring the thrust vector is a matter in it's own right, because you need to first define how much net thrust the ship is producing and it's direction in ship's co-ordinates, and then convert that vector to the previously defined base co-ordinate system, based on the ship's attitude vector, which needs to be handled separately by rotational dynamics, which sucks monkey **** and is for the most part much more complex to handle than simple 3D movement... still, same things apply, you need to know the moment of inertia for all three axes of the ship, and then you can handle the rotation vectors pretty much like you would handle linear movement vectors, but that's already handled pretty well enough in FS2 IMHO, you don't really need to add all the pesky things like gyroscopic effect (if you're rotating on longitudinal axis, it would be harder pitch or yaw...)
:lol:
But that's basically how it would be sensible to build a 3D spaceflight simulation engine in it's very rudimentary basics, without bothering over gravitational effects and stuff. Rotation would not need to really be changed for our purposes - if someone wants to fly realistic space fighter game, go get B5:IFH, get your bone marrow surgically replaced after the blood cancer inflicted upon you by B5:IFH's atrocious difficulty level, and then get back to playing FS2...
Again, this is most likely *not* the way to go with FS2_Open code due to historical reasons'n stuff, but that's the most simple way to do it. The stupid thing is that for compatibility, in FS2 this kind of code would still need to convert old ship tables' acceleration values to available thrust based on the ship's mass, or at least check if there is are or aren't direct thrust values supported. Also, if raw thrust values were added to new ship tables, they wouldn't be compatible with older builds which doesn't make even that much sense... :rolleyes:
-
thanks, im bookmarking all that btw :D i working on a retro 3d space game similar in appearance to elite in line drawn mode but i intend to use full on newtonian physics. this is my first attempt at programming something in c++ and all the pointers are making me a little nuts. its still not drawing anything in 3d yet but i got all my vector, matrix, and quaternion classes defined. im sorta stuck on my model loading code and cant really test my math until i have some verts to work with. it will be some time before i even touch physics.
-
I just hope I didn't make any stupid mistake there...
The notation might not be extra-accurate since vectors and deltas are not actually the same thing, but for all intents and purposes and avoiding even more breckets and formatting I simplified things a bit there. It shouldn't affect the maths in any way however. Also note that the equation for dislocation vector that pops out can also be formatted like this:
s = ½*a*t^2 + v0*t + s0
which is the standard "learn-by-heart" equation that is first taught in school physics to calculate the location of an accelerating object, without any use of differential calculus... which IMHO sucks ass and is the exact wrong way to learn physics because you don't really know where all the equations pop up, you just need to memorize them mindlessly. Only way, way later in high school when the differential calculations were presented to us it became clear why and where that equation comes from... obviously I consequently tried to make a 2D orbital simulation (with a big object on origo) on TI-86 but it never worked out as it should have. Perhaps it's time to brush that up again... :p
-
its sorta like that but the box subdivides and then checks which divided section the projectile is in, and it repeates untill the box is so small that its position is pretty much spot on with the projectile. but if you have a situation where you, your target, or your shot is moving about a hundred meters every frame, then that meathod doesnt work so well. this can be fixed with extra math of course, draw a line between the current position and the last position, and check every point along that line for a colision. this is actually alot of math. especially considering all those points have to be transformed into model space (or is it world space) to see if they hit any bounding boxes.
No force to mass conversions... just an arbitrary value I settled on after much testing. Yeah I know, but I figured in "semi-realistic" Freespace terms the ships would have the right engines that had the proper thrust to propel them... so that's what $Forward accel is for. Whatever that means :D
The arbitrary value happens to be 0.16 * 1+(the acceleration time constant, whether forward or side or afterburner) if you must know. I'm open to suggestions to how to make it better, but last time I posted the math people ran screaming from the thread :p
im not gonna really make any suggestions. the freespace engine isnt really cut out for newtonian physics at this time. not that i dont want them, i do, it just seems we need a bunch of other things for it to work. if collisions dont kill you the edge of the mission will. then again the math for newtonian is much simpler than what freespace uses. it starts getting confusing to mod when none of the values in the tables work anymore. you have to know 2 things to determine how fast you can accelerate, how much mass your ship has, and the force output of your engine.
since force = mass * velocity, then force / mass tells you how much energy to add to your current velocity every second. force and velocity are both vectors and so must be handled as such. you determine your velocity by adding all force vectors. each force vector is essentially your engine normals backwards, times the amount of force that engine is producing at the time. then divide the total vector by the mass of the ship, then divide again by the length of the frame, and add the resulting vector to the velocity every frame. at least i think thats how it works. please correct my physics anywhere i may be off. i need to have this nailed for a little something im working on.
Hmm...what if we had an "in-between frame", that doesn't actually get rendered but is only used for collision detection?
Namely do a whole frame collision calculation as if "time was doubled"/"velocities halved".
This should only be done if there are models present with sufficiently high velocities, and during the "in-between frame" only the high speed objects should be checked for collisions.
If the velocity is so extraordinary we can halve it again and do 4 successive in-between frames.
Fine tuning the velocity limit (the point where a sinle frame transition creates a noticable error) could also depend on the model size.
-
Is this working with BtRL yet?
Because it would be great if it did... :p
-
Hmm, wikify this stuff, anyone? Or not?
-
Ok now you guys with the math almost scared ME off :D
Update:
http://files.fringespace.org/bs/build20070509.rar
I fixed a bug with ships slowing down faster-than-usual when not gliding. Also added the negative value idea for $Max Glide Speed, let me know if it works how you like.
Known issue: engine trails are not always working. Bug since April 13 or so. Working on it.
jr2, good idea. I'll add it to the wiki once I'm sure things are working right.
UT - um, yes it works with BtRL, but BtRL is not working with it :p If you want to try it, make the temporary changes I showed in the other thread ;) Remember, HEAD is where stuff gets put to test... if it works well THEN it gets added to 3.6.9 branch.