Help with Flight Controls

#21 Resource submitted:

Gui Reticle HUD for TGE(A) With Target Cycling.

#22 Nice. Thanks Martin.

#23 You're welcome :-)

#24 Nice one, Martin. thanks.

---

now that everybody has shown off their screenies, does anybody have an answer for J.P Berry ?
I'm saddened that in 5+ years of Torque, things still fly around like they are Tribes2 hovercraft.

I understand that i may have to ditch the multiplayer part of my game if i want a realistic flight model.
..... fine... if thats what it takes... i'll go there. does anyone please have any advice on which bits to
rip out... or what needs adding ?

I can work out the lift/drag co-efficients of any given plane..... the temperature and density of the atmosphere. the windspeed. the quaternion rotations. no problem. there are at least a dozen free
flight models on the net. but how do i apply this data back to the model without Torque making it
"arcade". Datablocks are for a one off transfer of structures, yes?. so they won't cut it, will they?

I am currently looking down the wrong end of the telescope.
and any advice would be appreciated.

thankyou.

#25 The only difference between a Harrier Jet and say an F-16 (as far as flight goes)
is that the Harrier can hover. Wouldn't the same possibly fix the current Torque
flight model for you? Take away the ability to hover, and create an actual settable
throttle so you can maintain a constant speed, and you have a flying aircraft that
relies on it's physics to carry it through the air without plummeting to the ground.

I also think part of the difficulty here is that flying an aircraft with mouse or keyboard
controls has never really felt right. You need to use a joystick to really get that flight
feel to come through.

#26 @ Kevin - How did you get straffing working?

@Ken - I would be very interested to know how to implement realistic physical forces on an aircraft. I believe it would be a lot of tweaking, and overriding the "arcady" implementation of flight in the game. There is a helicopter resource which unfortunately is arcady but at least shows you how to mod the engine to change the flight model.
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9263

Here's one for adding animations to the vehicle...
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=11635

Peripherals v.cool
www.goflightinc.com/order/index.php

A Torque flight sim
www.garagegames.com/mg/snapshot/view.php?qid=980

EDIT: Fixed animations link

#27 @ Kevin
thanks for trying to help, but the issue is more complex than the feel of a joystick. theres a great deal
of difference, between a hovering VTOL plane, and a prop-plane thats using lift and drag to climb, dive and turn. I'm not knocking it... it generates very nice looking AI flight... but the torque 'flight model' has no lift. when the attitude of the wing (angle of attack) changes... so should the lift co-efficient. the angle of mass (center of gravity?) should also change. torque seems to use a system of jets around the fuselage to manuver? i have a feeling it may need ripping out completely. tweaking it would be a waste of time, if it is fundementally flawed. the fact that nobody has turned out a semi-accurate flight model in 5 years, leads me to suggest/guess that it is.

@ Andy
a bloke posted a resource that computed the 4 basic forces accurately.
but that was also based around the manuevering jets paradigm too.
if i can find it, i'll post the link for you. i also have a couple of free sim
flight models that you could look at for reference. i don't know enough
to bolt them into torque yet.. but at least theres hope. the alternative
of starting with a flight model, and building everything up from there is
too much to contemplate.

Sadly, the torque flight sim "Air Ace" couldn't solve the problem, either. they're now calling their game "Panzer Ace". from the info in their blogs, they tried to bolt on an external physics library,
but they couldn't get it to work across a network. (didn't mention which one).

what about JSBsim ? nice flight model. could that be integrated with torque?
we can access XML via the tinyXML implementation. 'flight gear' is too massive
and flabby for something as simple as a "basic flight model".

any advice appreciated.

regards to all.

#28 @ Andy
It was accidental. I was playing with values in the physics section
of the scout ship's CS file.

@ Ken
True. I can't say I've really dug into the meat of the flying code of Torque,
at least not yet. Chances are before I start hitting beta releases of my
game I'm going to have to do something different myself. Even in space
the ship just doesn't have the right feel yet.

#29 Maybe we can share our efforts? I started too working on a replacement for the stock vehicle class by taking the stock player class, renaming it to "JetVehicle" and starting now to put in the (hopefully) right steering behaviour. What do you think? Shall we work together on this?

Stock player class has a lot of Pro's to use it:
- Collision works
- Vehicles could then have animation
- Battle-proven

#30 I'm in.

#31 I get back here on the weekend, I think I have the first "stuff" then done. Let's see if it works out. Back soon :-)

#32 Hi Martin. I'm still a noob with torque, but i'd love to help out somewhere.
I'm making a biplane sim which has prop planes flying at around 100mph
maximum speed.

I noticed (in another thread) that you were having trouble shifting the "mass" node?
did you get that to work at all? because shifting the plane's center of gravity is fairly
integral with what we're attempting to do, i think.

regards.

#33 Hey Ken. No, haven't had success so far with shifting the mass node. I pushed this back a bit until I got my new more powerful mac to actually do some heavy debugging session. My old machine wasn't able to do so. But now the mac is there - will see what I can archive this weekend. But the wrong mass point seems to be an error in the existing physics calculation code. Not sure if I have enough memories on my physics knowledge to fix that... Will see will see... :-)

#34 Okay, this really isn't as complicated as everyone's making it sound. The flight model for the default FlyingVehicle class is intentionally hovercraft-like; they basically fly like spacecraft. The vehicles are, at the base, just ShapeBase objects with an attached physics actor (the Rigid class). The updateForces function then applies impulse to the Rigid body to make it move about. This function is simple and well-commented, at least in FlyingVehicle it is, so it's easy to see how each force actually gets applied to the Vehicle.

All you really need to to is clear out all the existing updateForces stuff for the FlyingVehicle class and replace it with some realistic lift/drag stuff. You're going to have to get all of this from some real physics if you want it to be realistic. Just go look up the physics of airplanes.

In effect you basically want to calculate lift and apply upward force based on this value. The only force that actually will come from user control is the throttle and various rudder positions. Once again, you'll want to look up how these actually apply force if you want it to be realistic, but you could also just apply speed * steering as rotational force as a cheap hack.

For the original poster: The lines you're going to be interested in are:

torque += yv * steering.x * mDataBlock->steeringRollForce;
   F32 ar = mDataBlock->autoAngularForce * mDot(xv,Point3F(0,0,1));
   ar -= mDataBlock->rollForce * mDot(xv, mRigid.linVelocity);
   torque += yv * ar;

Instead of applying steering.x * steeringRollForce, you'll want to apply whatever controls your roll force in your flight model. There's a steering.z, and while nothing actually sets it by default, you could easily link some aspect of your controls to it (either keys or a joystick axis).

As far as the center of mass, remember that only the center of the Rigid actor's mass is important. The center of the actual Vehicle object doesn't come into play, unless that's how Rigid determines the center of mass (I was under the impression it used an offset from bounding box center, but I honestly don't recall without looking it up). I have no idea if the Mass node is actually used (could be some old, unused leftover), but even if it is, changing its position at runtime will do nothing because the Rigid's center is set onAdd.

Anyway, you can call Rigid::setCenterOfMass(Point3F) at any point to set it. For the rotation to all work correctly, you probably also want the axis of the ShapeBase obj to be at this location.

#35 @Henry - thanks for that explanation. It makes it a lot clearer how it's been implemented.

#36 Hi Henry. the skeptic in me says "if its that simple, why has nobody done it in 5 years?".
plenty of other people have tried working on flight, only to be beaten back (like myself)
by the "jet thrusters" in the flight model. i'm sure they weren't all stupid, or overlooking
the obvious. but i thankyou for illuminating a possible solution. And will do my best to try
and get it working satisfactorily.

Quote:you can call Rigid::setCenterOfMass(Point3F) at any point to set it.

thanks for that. according to my rudimentary knowledge, the Center of Gravity does shift.
so it's good to know that this is achievable with code, and not via the mass node.

cheers..

#37 Well, honestly I tried that shifting the massCenter parameter from the datablock. You can really see that the behaviour is completly different if the massCenter is shifted, but the point is: it is not the expected result what you get! So if you for example want to have the ship roll around it's real center and modify the massCenter so that it is really at the point where the shape center is, the pitch/yaw messed behaves totally strange and rotates even more around an arbitrary point. Try it, weird behaviour.

So generally there _are_ issues with the flightgame updateforces code. Honestly if I would have found a solution for it, I had it already posted long long time. But so far all my tries went to dust.

#38 You're not thinking about center of mass properly. From my experience when I did a jet ski for my surfing game, the true center of gravity was not inside the hull at all. It was below hull, probably around the area where the dorsal fins would displace water under speed. Center of mass changes with velocity, which is why a boat can rise up onto a ski at the right speeds. When a boat is not under power it's center of mass shifts up, and becomes unbalanced which is why if you're not careful you can roll the boat and fall off.

Aircraft would be similar and with great velocity the center of mass would shift around constantly. From there this is would influence centrifugal force, which is why you can be forced out of your seat doing negative gees and into your seat doing positive gees - one results in blackouts (no blood to the brains) and another in red-outs (too much blood to the brain). It would also allow you to curve a path through the sky where the jet would be slicing through the sky almost as if it was carving up a wave.

I think in response to what Martin has said, I don't believe Torque is designed for realistic flight dynamics, and so a 3rd party solution is required - just as physics code is added in later - should I provide it? I'll try to find a solution.

#39 Here's the Wikipedia entry on Center Of Mass (CM).

From what I understood of the article, the center of mass is a fixed point, but the forces that apply are the momentum forces that take the CM into calculation (a bit down the page).

Hehe, too much physics, that should be handled by a physics library, as Andy said. :-)

#40 Admittedly not the freshest of threads, but since I've lost this code a few times now:
(vehicle.h/.cc/.cpp)

class Vehicle: public ShapeBase
{
...
   // Control
   Point3F mSteering;//was Point2f
...
Point3F getSteering() {return mSteering;}//was Point2f
...
}

Vehicle::Vehicle()
{
...
mSteering.set(0,0,0);//was mSteering.set(0,0);
...
}

void Vehicle::updateMove(const Move* move)
{
...

   // Steering
   if (move != &NullMove) {
...
      F32 p = move->pitch;
      mSteering.y = mClampF(mSteering.y + p,-mDataBlock->maxSteeringAngle,
                            mDataBlock->maxSteeringAngle);
      F32 r = move->roll;//add 3rd vector
      mSteering.z = mClampF(mSteering.z + r,-mDataBlock->maxSteeringAngle,
                            mDataBlock->maxSteeringAngle);
   }
   else {
      mSteering.x = 0;
      mSteering.y = 0;
	  mSteering.z = 0;
   }
...
}

(flyingvehicle.h/.cc/.cpp)

FlyingVehicle::FlyingVehicle()
{
   mSteering.set(0,0,0);
...
}

void FlyingVehicle::updateMove(const Move* move)
{
   Parent::updateMove(move);

   if (move == &NullMove)
      mSteering.set(0,0,0); // was set(0,0)
...
   mThrust.x = move->x;
   mThrust.y = move->y;
   mThrust.z = move->z;//added
...
      else
         mThrustDirection = ThrustBackward;
   //else
      //mThrustDirection = ThrustDown; //removed vtol though can't remember why that was relevant atm.

void FlyingVehicle::updateForces(F32 /*dt*/)
{
...
   steering.y = mSteering.y / mDataBlock->maxSteeringAngle;
   steering.y *= mFabs(steering.y);
   steering.z = mSteering.z / mDataBlock->maxSteeringAngle;
   steering.z *= mFabs(steering.z);

   torque -= xv * steering.y * mDataBlock->steeringForce;
   torque -= zv * steering.x * mDataBlock->steeringForce;
   torque -= yv * steering.z * mDataBlock->steeringForce;

   // Roll
   torque += zv * steering.z * mDataBlock->steeringRollForce;
   F32 ar = mDataBlock->autoAngularForce * mDot(zv,Point3F(0,0,1));
   ar -= mDataBlock->rollForce * mDot(zv, mRigid.linVelocity);
   torque += zv * ar;
}

and finally, scriptside: (default.bind.cs)

//-------------------------------------- added roll
function rollRight( %val )
{
	error("$mvRollRightSpeed  : " @ $mvRollRightSpeed);
	$mvRollRightSpeed = %val ? $Pref::Input::KeyboardTurnSpeed : 0;
}

function rollLeft( %val )
{
	error("$mvRollLeftSpeed : " @ $mvRollLeftSpeed);
	$mvRollLeftSpeed = %val ? $Pref::Input::KeyboardTurnSpeed : 0;
}

One corollary: Had to put this back together from memory twice at this point, and can't quite recall how I fixed the lack of damping issue, so the above code requires a counter- keypress to stop the spin. Probably update this when I can remember (unless someone cares to append it themselves)