Impact spheres

[chris330 0]

Dear All,

Hi just need some advice on a basic physics engine type question for something I'm making in OFP and might port to ArmA. Firstly I will point out this is not an attempt to try and be clever or show you how smart I am or anything like that I just genuinely need some help on a physics concept. I don't want to say what it's for, or the thread will attract replies that will send it O/T.

So here goes:

I want to simulate applying a force to an object. Obviously there is no way of doing this directly in either engine with the commands we have access to as private editors. I know ArmA has a new vector command and the like but I want to get the principle functioning in OFP first before looking at ways it could be done in ArmA.

I'm going to try a method I thought of which uses what I call impact spheres. I make a small sphere in O2 and give it a mass. Then I place it very near to the object I want to apply a force to, say a stationary truck for example. Then I time the execution time of one cycle of the script I'm going to use. This would have to be done on another occasion. Then I work out the force I want to apply to the truck, whether it be acquired by calculation or just some arbitrary value for testing purposes.

So I now have:

1)My desired force to apply to the truck.

2)The time interval between code executions.

3)The distance of the impact sphere from the truck.

4)The initial velocity of the impact sphere which is zero.

If I use the desired force and the sphere's mass placed into the f=m*a formula then I can acquire the required acceleration I'd have to give the impact sphere to simulate the application of the desired force.

That's all very nice but it means nothing because there's no way to apply an acceleration directly to an object in OFP. So if I take the time interval between execution times (or script frame-rate to give it a different term) and then input the relevant known information for acceleration, initial velocity and time into the following equation of motion:

a=(v-u)/t

..then I can re-arrange it to give me the value for v. This would be the final velocity after time t if an acceleration of magnitude a had been applied.

So if I work out the required end velocity I think that means I can give the impact sphere a setvelocity push that will mean it arrives at the truck's geometry LOD with exactly or almost the correct final velocity value v. This would mean that mathematically speaking the force I'd simulated giving to the impact sphere would now be transferred to the truck. I know some of it would be lost due to equations relating to drag in the game's engine but if the distance were small this would have a negligible effect.

So in theory it's sound. But I could do with someone with a better grasp of physics to confirm this for me.

Will it work in the OFP/ArmA engine though? Essentially I'm imparting momentum to the truck by giving something with a known mass (the sphere) a velocity and then colliding it with an existing vehicle. Odd engine behaviour could be worked around however by using experimental tests to alter the applied setvelocity push to the sphere to give the correct results. It would need the engine to perform reliably though, even if it doesn't perform realistically, which I suspect might be the case.

As I said I'm not trying to be a smartass I just think this is a really good idea but I want someone to back me up in my theory assumptions before I go on a wild goose chase.

If anyone can offer a bit of help with the above question please do so as this is a bit of a new area for me.

Many thanks

[chris330 0]

No matter guys I figured it out last night at work

[[aps]gnat 28]

lol ... glad because it was hurtung my little brain

[General Barron 0]

I think it is a clever and interesting idea. The Arma physics engine is a bit... funky... when dealing with collisions though. I don't remember OFP being any better.

So in practice, this might not turn out so well. But without actually trying it, there is no way of knowing that! So I'd definitely try it out, the results might be very useful.

Bear in mind though, you are dealing with 3d objects, not points in space like in a math book. There is no way to locate an object's center of mass via script (that I know of), so you won't be able to fire your impulses directly at it. So in practice this might not work out very well, because part of your force might end up making a rotation, instead of a translation.

[chris330 0]

A rotation is exactly what I'm after mate. I can simulate lift, drag and thrust using the setvelocity command. The game physics engine book I'm reading taught me how it's done by the engine. Basically all the forces are calculated by the engine and turned into an acceleration depending upon the object's mass ('m sure you guys prob already know this). Then they integrate to get a velocity and then use the frame-rate time measured from the last frame inputted into the speed, distance and time equation to get the object's new position. It's updated in either the current or next frame.

So basically an applied force simply drops out as a positional update which the general game engine renders. Obviously I can't get that close to the OFP engine so I'll have to settle for turning a force into a velocity and applying it to an impact sphere. This instantaneous applied velocity gives the impact sphere the exact momentum that it would receive due to the acceleration caused by the applied force.

Then if all holds well the impact sphere hits the object (read aircraft) and transfers all that gained momentum to the object being hit, thus simulating the direct application of the applied force to the target object. Looking ahead I can see the following issues and notes arising:

1)Given that the impact sphere will have to travel a short distance before hitting the target object, it will obviously lose some of the applied velocity from the setvelocity command before hitting the target object (t/o) due to drag applied by the OFP engine. This will cause slightly less force than desired to be imparted to the t/o. Not such a bad thing, infact it will probably help with stability - and I'll need plenty of that with this comedy circus of a method.

2)Simulating an applied force due to a control surface such as an elevator attempting to change the t/o's pitch could be more easily simulated by applying the impact sphere force somewhere else on the t/o's body. For example an elevator on the wing trying to pitch the t/o up could be more easily modelled by using a very small force underneath the aircraft's (I'll stop beating about the bush now) cockpit right at the nose. Given the greater distance from the Centre Of Gravity at the nose compared to the wing a much smaller force could be applied to give the same turning force due to the increased distance from the COG. This would bring impact sphere velocities right down and reduce potential issues of the aircraft sustaining damage from the collision.

3)Point 2) could be further improved by having two impact spheres operating in tandem to further reduce impact velocities.

4)The time interval had me scratching my head to begin with. I mean what did it actually represent? Obviously it had to be there but what was it all about? Well the applied force basically as already stated results in an applied acceleration to the impact sphere.

Naturally the best time interval to choose between updates is the length of time it takes the script/function to complete which I hope will be small. Great so I now have a time interval, but still couldn't figure out what it meant. The time interval is obviously used to predict the size of the setvelocity push to apply and it dawned on me in the end that the time interval represents the length of time the force is applied for and thus the amount of momentum the impact sphere accrues before hitting the t/o.

Force is what's being applied but momentum is the stuff that's actually moving around. The longer the predicted and calculated time interval the force acts for, the greater the change in accrued momentum and thus the larger the calculated setvelocity push and the larger the magnitude of reaction that eventually occurs in the t/o when the impact sphere hits it. I suppose you could think of this time interval as the script's 'resolution'.

Obviously in the real world this time interval is infinitely small but in the realm of computer's and frame-rates and script execution times it starts to get potentially problematically big. If it became too large then the behaviour of this script and the resultant changes in the t/o's behaviour could get very chunky indeed so it needs to be kept as small as possible. I eventually decided to think of the time interval and setvelocity magnitude as the final velocity the impact sphere would accelerate to over this time interval with the desired applied force.

Put another way: if the script executed too slowly the simulated applied force would act for too long and the momentum build up would become too big and the behaviour of the t/o would become too dramatic.

So there's the idea anyway. Lift, drag, gravity and thrust can be done by using aerodynamic calculations to work out what force to apply then turning this force into an acceleration and then finally a velocity which can be applied using the setvelocity command in the correct resultant direction.

Rotations can be effected using this impact sphere method which will in turn alter the pitch and bank of the main active parts of the aircraft (the wing and the engine) through calculations performed by the OFP engine upon the occurrence of these mini collisions. Then the next update simply looks at the orientation of the aircraft after the OFP engine has done its rotational magic on it and then re-evaluates lift, drag, gravity and thrust forces again as a result of these orientation changes. User inputs are checked and if present applied again by using the impact sphere method to apply the required rotation forces caused by aileron, elevator and rudder movement plus any inputs to the turbines.

Bugger if I can get it to work I can even simulate jolt forces caused by firing cannons at ground targets. I also thought that if a stable working version of it can be made (I'm really not sure how likely that is?) then a more advanced drag force could be applied by relating the aircraft's orientation to its velocity vector and computing how much of its surface area is perpendicular to its velocity and thus altering drag accordingly.

Naturally there is no way a generalised version of this could be made. A separate tailored version would have to be made per aircraft and it will involve detailed analysis of the aircraft in O2 with regards to its COG location and the starting point of impact sphere location. Furthermore it's possible that a very accurately distributed weight model might be needed in O2 rather than simply selecting every vertice and simply applying a portion of the total mass to each which I think it what probably happens with most addons including the default Bohemia ones.

With this firmly in mind I need a really well known and freely documented aircraft to start work on for which an addon has already been made for in OFP. I was thinking of going with the A-10 unless anyone has a better suggestion?

The first task will be to work out the aircraft's weight distribution and build something in O2 which is fairly close to it. Thing's such as changes in COG due to emptying fuel tanks will simply have to not be modelled as I doubt COG changes are modelled by OFP/ArmA's engine due to such things.

The next thing will be to acquire a reasonable set of equations (even if somewhat simplified) relating velocity to lift force for the wing profiles of the chosen aircraft, and also for the thrust it puts out and the drag and turning forces caused by aileron and elevator and rudder deflection.

Then I'd have a pretty good mathematical flight model coupled to a reasonably good physical game engine .p3d model of the chosen aircraft. I've put a lot of thought into the initial theory behind this and the work in that department is pretty much done now. All that remains is to see if the impact sphere method will work in practice. Potential snags of doing this in OFP include:

1)Some general engine problem/limitation which rejects or makes otherwise impossible the impact sphere method such as varying degrees of accuracy due to integration problems or badly implemented collision detection/resolution. Perfectly possible with the OFP engine from what I hear.

2)Unwanted interference from the general game engine such as that which causes helicopters to gain height often unwantedly when flying over varying terrain heights. Should issues of this nature occur they could probably be overcome by some crafty manipulation of the vehicle class instance.

So yes to be honest I'm building a flight simulator in OFP. Reason being is I have a very big project lined up in coming years for a personal game adventure (not OFP/ArmA related) and I want to learn as much as I can about building my own flight simulator on a platform I'm familiar with to facilitate doing it in my future game.

For those who are curious I'm going to use Kegety's FWatch to take user inputs to make the aircraft's behaviour completely customizable so there's no nasty interferences with the default game inputs for planes.

If this method really does work then it could be used for helicopters too and potentially lots of other things. I'm going to stick with the simple truck on runway test to start with though and learn all I can about the impact sphere method before applying it to something this complex. I'll simply fire impact spheres at it until I can get predictable results.

Thought I'd share it with you especially seeing as I know the two people who have replied in this thread so far very well and I know you're good people who have a genuine interest in learning about this kind of stuff and helping others. As I said I'm not trying to be a smartass I've just had what I think is potentially a really good idea.

If anything I've said doesn't make sense and you want a better or different explanation please ask and I'll respond again. I'm going to need quite a bit of help with a few things before this is over (if it ever is).

Thanks

[hardrock 1]

If anything I've said doesn't make sense

I'm not sure whether many people in these forums will be able to help you on this pretty advanced topic. I'm curious as to whether and how you'll realize this though.

Thumbs up!

[vektorboson 8]

Ok, I'll try my take at it; as for information: I implemented a helicopter simulation in C++ as an university project, so I had two problems to master: Drawing a wide landscape with > 20km view distance (accomplished, though with a few visual artifacts) and creating believable aerodynamics for a helicopter (err, somewhat accomplished).

The aerodynamics were a very hard task and I can't say that I am pleased with the result I delivered.

I used the simple Euler-Integration scheme, and I used quaternions to store the orientation of the chopper (it's cheap easy to turn quaternions back into rotation quaternions, as opposed to matrices).

I can't say I had problems with numerical stability aside from sloppy/wrong equations and programming.

The real hard problem was creating the coefficients (drag, inertia, a.s.o.). They also need to be different for every direction/axis. Because of lack of time, I didn't create physically 'correct' turning, and I started to cheat by creating some weird type of 'centripetal force' I applied in some very weird way.

It wasn't nice, but it was acceptable. I compared my result to the Bo-105 handling from open source simulator FlightGear, and was quite pleased what I accomplished in less than one week of coding.

But you shouldn't forget: I had full control over the engine. I could control velocity, position, orientation, rotation of the helicopter, and I decided when and how they were changed.

Now, as I read, you try to make your flight dynamics in OFP. Where you can only set/get the velocity and azimut. So to control orientation you try this very crazy hack through impact spheres by transferring momentum.

Well, as you probably know, OFP does violate momemtum preservation. Throwing for example grenades on the ground could sky-rocket them into heavens; so you absolutely cannot rely on OFP simulating elastic collision, and thus your hack of impact spheres won't work.

It will create system explosions.

Beside this: You need the orientation of the jet to apply torque at the correct position. Ok, there are hacks by using the drop-command (which transforms the relative position of the particles with the object's matrix); but this won't be satisfaction.

Ok, you want it to do in ArmA rather than in OFP since you can control the orientation in ArmA. You still got the problem to fight against the built-in dynamics engine, let's put this aside for now. But forget about the clever trick of impact spheres.

You said you want to make a more realistic mass distribution; the mass distribution will be abstracted into the inertia tensor anyway. So either you calculate it from the mass distribution (parse the P3D, read in the vertices along with their mass value, calculate the inertia tensor and COG), or you set the tensor directly.

No need for impact spheres: You have the information you need to apply force/torque correctly. No need for a man-in-the-middle.

The other thing you want to do: Calculating lift/drag from the model; AFAIK commercial simulator X-Plane calculates those coefficients from the models. Don't know about the others, but presumably it is a non-trivial thing.

I'd say: Find the coefficients by trial-error instead; if you really want to find them from the model, it must satisfy many constraints, so you can apply an algorithm that is supposed to provide reasonable values and to finish calculating sometime.

Good luck!

[General Barron 0]

Quote[/b] ]Naturally there is no way a generalised version of this could be made. A separate tailored version would have to be made per aircraft and it will involve detailed analysis of the aircraft in O2 with regards to its COG location and the starting point of impact sphere location.

Quote[/b] ]...forget about the clever trick of impact spheres.

Exactly. Upgrade to Arma, with a (slightly) better physics engine, and a (much) better scripting engine.

You don't want to spend your time messing with "impact spheres", just to make a simple rotation. It will take you forever to build your flight simulator if you need to hack your way around limitations in the scripting engine like that!

For Arma, try my set pitch/bank function.

While you're at it, maybe you or vektorboson could use your (far) superior math skills to figure out the bug in my get pitch/bank function (see the thread).

In Arma, there is also a version of FWatch available for Arma. Or, you can also capture keyboard / mouse input in a dialog, and use it there (no need for external apps).

-------

You also have more control over an aircraft's flight model via configs, which in your case might make it easier to "switch off". Actually, in your case you are best off flying a static object around, not a real plane, because then the engine will only simulate gravity (and maybe drag).

[chris330 0]

Thanks for the replies that will have saved me alot of time indeed. I suspected OFP might not like the method and would not behave as one would expect so thanks for confirming that as I would have spent god knows how much time learning that for myself.

Lol great minds think alike, as I read your point about using the drop command to properly place the spheres it is something that I have just written down in my notes only this morning!

I'll go for doing it in ArmA instead then, sounds like a far better solution indeed.

@GB, that is indeed what I was thinking of doing. Using a plane or helicopter derived from the base class with as much turned off as possible. I've tried using commands on static objects and I don't think it reacted too well.

Great replies, many thanks to you all.

*Edit* Thanks vektorboson for the info about the inertia tesnor too and its relation to the COG that's helped alot.