Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Michael Selig writes: Sounds useful. Can I suggest that this feature be enabled/disabled at the option of the user? Yes -- that's why I mentioned it should be optional. It would make no sense if FlightGear were hooked up to a full-motion sim (or even just a moving chair). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Tony Peden writes: On Sat, 2003-02-08 at 19:53, Curtis L. Olson wrote: I agree with Michael though that whatever we do with respect to providing motion queues through the visual system should be user selectable. Any time your eyes (visuals) disagree with your butt eh, hemm. Inner ear. All three, I think -- the brain also uses pressure on the feet or posterior to establish balance. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Viewer suggestion: acceleration effects
Just to add my two cents, the eyepoint motion sounds like an interesting way to add some cues to make up for the cues missing in a motionless sim. Only small movement in the x and y planes would suffice to provide the cues. There is some movement in the z axis, mainly from the springiness of the soft seat cushion. There is also the bouncing eyeball effect, which is most noticable at night (I suppose in the daytime the brain can more easily smooth the effect of step inputs). This effect can be demonstrated by going into a very dark room and staring at an LED display while eating something crunchy, like an apple. (If someone asks, tell him you're doing a scientific experiment). This can really increase the difficulty of nighttime instrument flying. There are two other cues that are helpfull. One is pre-stall buffet. For instance, the T-38 flies the entire base turn in pre-stall buffet. One reads the visual, tactile and audio severity of the buffet to estimate the angle of attack. The initial tickle is low-amplitude and periodic, about 10 hz, give or take. It progresses with increasing AOA to elephant, high amplitude and about 4 hz. The buffet can be applied to almost any airplane at some point in its AOA range. It can also model mach buffet or severe engine/prop vibration. Another cue, like someone else mentioned, is the grey/black/red-out effect. It is nearly impossible to do a proper loop in the T-38 without this cue (unless you have a very prominent g-meter installed). I'd recommend a graying of the entire screen starting at about 3 g's and increasing linearly to black at 6 g's (without g-suit) or 8 g's (with g-suit) or 9 g's (f-16). This is important in acrobatic and fighter airplanes because much of the basic maneuvering is done at the 3 to 4 g level, with eyes outside. (The audio level diminishes at the same rate.) A really accurate blackout (as modeled in AW3, a great sim) will last about 2 or 3 seconds, and the return to normal senses will occur gradually, say three seconds. In a *really* accurate sim, which I haven't seen yet, the return to normal senses will be accompanied by seeing stars during that time. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
I agree with Michael though that whatever we do with respect to providing motion queues through the visual system should be user selectable. Any time your eyes (visuals) disagree with your butt (motion) you risk getting the user sick. Some people are a lot more sensitive to this than others. People who suffer migrains seem to suffer more simulation sickness and being an older male seems to also be a risk factor. Regards, Curt. David Culp writes: Just to add my two cents, the eyepoint motion sounds like an interesting way to add some cues to make up for the cues missing in a motionless sim. Only small movement in the x and y planes would suffice to provide the cues. There is some movement in the z axis, mainly from the springiness of the soft seat cushion. There is also the bouncing eyeball effect, which is most noticable at night (I suppose in the daytime the brain can more easily smooth the effect of step inputs). This effect can be demonstrated by going into a very dark room and staring at an LED display while eating something crunchy, like an apple. (If someone asks, tell him you're doing a scientific experiment). This can really increase the difficulty of nighttime instrument flying. There are two other cues that are helpfull. One is pre-stall buffet. For instance, the T-38 flies the entire base turn in pre-stall buffet. One reads the visual, tactile and audio severity of the buffet to estimate the angle of attack. The initial tickle is low-amplitude and periodic, about 10 hz, give or take. It progresses with increasing AOA to elephant, high amplitude and about 4 hz. The buffet can be applied to almost any airplane at some point in its AOA range. It can also model mach buffet or severe engine/prop vibration. Another cue, like someone else mentioned, is the grey/black/red-out effect. It is nearly impossible to do a proper loop in the T-38 without this cue (unless you have a very prominent g-meter installed). I'd recommend a graying of the entire screen starting at about 3 g's and increasing linearly to black at 6 g's (without g-suit) or 8 g's (with g-suit) or 9 g's (f-16). This is important in acrobatic and fighter airplanes because much of the basic maneuvering is done at the 3 to 4 g level, with eyes outside. (The audio level diminishes at the same rate.) A really accurate blackout (as modeled in AW3, a great sim) will last about 2 or 3 seconds, and the return to normal senses will occur gradually, say three seconds. In a *really* accurate sim, which I haven't seen yet, the return to normal senses will be accompanied by seeing stars during that time. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Sat, 2003-02-08 at 19:53, Curtis L. Olson wrote: I agree with Michael though that whatever we do with respect to providing motion queues through the visual system should be user selectable. Any time your eyes (visuals) disagree with your butt eh, hemm. Inner ear. (motion) you risk getting the user sick. Some people are a lot more sensitive to this than others. People who suffer migrains seem to suffer more simulation sickness and being an older male seems to also be a risk factor. Regards, Curt. David Culp writes: Just to add my two cents, the eyepoint motion sounds like an interesting way to add some cues to make up for the cues missing in a motionless sim. Only small movement in the x and y planes would suffice to provide the cues. There is some movement in the z axis, mainly from the springiness of the soft seat cushion. There is also the bouncing eyeball effect, which is most noticable at night (I suppose in the daytime the brain can more easily smooth the effect of step inputs). This effect can be demonstrated by going into a very dark room and staring at an LED display while eating something crunchy, like an apple. (If someone asks, tell him you're doing a scientific experiment). This can really increase the difficulty of nighttime instrument flying. There are two other cues that are helpfull. One is pre-stall buffet. For instance, the T-38 flies the entire base turn in pre-stall buffet. One reads the visual, tactile and audio severity of the buffet to estimate the angle of attack. The initial tickle is low-amplitude and periodic, about 10 hz, give or take. It progresses with increasing AOA to elephant, high amplitude and about 4 hz. The buffet can be applied to almost any airplane at some point in its AOA range. It can also model mach buffet or severe engine/prop vibration. Another cue, like someone else mentioned, is the grey/black/red-out effect. It is nearly impossible to do a proper loop in the T-38 without this cue (unless you have a very prominent g-meter installed). I'd recommend a graying of the entire screen starting at about 3 g's and increasing linearly to black at 6 g's (without g-suit) or 8 g's (with g-suit) or 9 g's (f-16). This is important in acrobatic and fighter airplanes because much of the basic maneuvering is done at the 3 to 4 g level, with eyes outside. (The audio level diminishes at the same rate.) A really accurate blackout (as modeled in AW3, a great sim) will last about 2 or 3 seconds, and the return to normal senses will occur gradually, say three seconds. In a *really* accurate sim, which I haven't seen yet, the return to normal senses will be accompanied by seeing stars during that time. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Viewer suggestion: acceleration effects
For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: /accelerations/pilot/x-accel-fps_sec /accelerations/pilot/y-accel-fps_sec /accelerations/pilot/z-accel-fps_sec What we'd do is tilt the cockpit viewpoint slightly for any strong forwards/backwards or sideways accelerations. For example, a strong, forward acceleration (like a takeoff roll in a fighter jet) might tilt the view pitch angle up a degree or so, while a strong deceleration might tilt the head forward about the same amount. Sideways accelerations would cause the head to tilt sideways similarily (the view roll angle). Vertical accelerations are trickier, since they're roughtly perpendicular to the spine. The best thing here would be to adjust the vertical view offset by half an inch or so down for a strong upwards acceleration (being pushed down into your seat) or up for a strong downwards acceleration (straining up against your lap belt). If we want these to be useful and not cheesy, they'll have to be very subtle in most normal flight (i.e. a fraction of a degree) except for special situations like the initial part of the takeoff roll or heavy braking. On the other hand, if the plane is being flown by a ham-fisted sim driver, we could rock things around a little more as would be happening with real passengers (Alex has also suggested splattering the panel with virtual vomit). Jim: are you interested in adding this to the viewing architecture, or would you like me to take a try in a week or two? I don't claim to fully understand how to use these, but you can look at src/Instrumentation/slip_skid_ball.cxx for a sideways-acceleration example I ripped off from Alex's old steam code. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, 7 Feb 2003 11:51:29 -0500 David Megginson [EMAIL PROTECTED] wrote: For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: /accelerations/pilot/x-accel-fps_sec /accelerations/pilot/y-accel-fps_sec /accelerations/pilot/z-accel-fps_sec What we'd do is tilt the cockpit viewpoint slightly for any strong forwards/backwards or sideways accelerations. For example, a strong, forward acceleration (like a takeoff roll in a fighter jet) might tilt the view pitch angle up a degree or so, while a strong deceleration I think this is a great idea. You might try treating the pilot eyepoint as a spring/mass/damper system in the XY plane and assume no Z motion. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
[Chiming in because the subject is cool, and because I'm currently stuck debugging a parser that is giving me fits and need a break.] David Megginson wrote: For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: Why not just model the head as a highly damped spring? You'd need to fiddle with the constants a little to make it look right, but once it's fixed up it should work right for all heads. :) Almost exactly the same thing technique can be used for orientation. I distinicly remember from my few flights in light planes that turbulence (especially yaw oscillations) felt more like the plane was rotating around me. It would be (I think) really cool for the view direction to lag the planes reference frame a little in the same way that the view position lags the real position. I'd give this more general idea a shot first, before trying axis-specific code. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Andy Ross writes: [Chiming in because the subject is cool, and because I'm currently stuck debugging a parser that is giving me fits and need a break.] David Megginson wrote: For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: I'd give this more general idea a shot first, before trying axis-specific code. A Quaternion representation for the head orientation anyone :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Andy Ross writes: I'd give this more general idea a shot first, before trying axis-specific code. The axis-specific stuff is easier for me to understand -- perhaps someone with a stronger physics background could work with Jim to do a generalized, spring implementation. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, 7 Feb 2003 13:29:34 -0500 David Megginson [EMAIL PROTECTED] wrote: Andy Ross writes: I'd give this more general idea a shot first, before trying axis-specific code. The axis-specific stuff is easier for me to understand -- perhaps someone with a stronger physics background could work with Jim to do a generalized, spring implementation. *Spring/mass/damper* system, as I mentioned before. This is similar to how fuel slosh is modeled in spacecraft sims (and I'm not making a comment on anyone's brain consistency, in particular ;-). Break the aircraft acceleration into X and Y components and model it in a head axis that is parallel to the aircraft body axis. This is a cool problem to work, but I don't have time now either. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
David Megginson [EMAIL PROTECTED] said: Andy Ross writes: I'd give this more general idea a shot first, before trying axis-specific code. The axis-specific stuff is easier for me to understand -- perhaps someone with a stronger physics background could work with Jim to do a generalized, spring implementation. Hehe...Thanks David. I've still got a nasty bug that was reported last week to deal with. So I'll be in the code. My recommendation would be to model this head thing, probably in its own class, and then publish data in the position or orientation path that the viewer would read in. We could have a class FGPilot with properties: ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Hmmm...not sure how that happened but this message got away from me half finished.
David Megginson [EMAIL PROTECTED] said:
Andy Ross writes:
I'd give this more general idea a shot first, before trying
axis-specific code.
The axis-specific stuff is easier for me to understand -- perhaps
someone with a stronger physics background could work with Jim to do a
generalized, spring implementation.
Hehe...Thanks David. I've still got a nasty bug that was reported last week
to deal with. So I'll be in the code.
My recommendation would be to model this head thing, probably in its own
class, and then publish data in the position or orientation path that the
viewer would read in.
We could have a class FGPilot with properties:
head {
double head_roll;
double head_pitch;
double head_Xoffset;
double head_Yoffset;
double head_Zoffset;
}
stomach {
double breakfast;
double lunch;
bool antacid;
}
vision {
bool on;
bool blur;
}
And methods:
FGPilot::chg_head_roll;
FGPilot::chg_head_pitch;
...
FGPilot::Vomit;
FGPilot::BlackOut;
etc, etc.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, Feb 07, 2003 at 09:43:59AM -0800, Andy Ross wrote: Why not just model the head as a highly damped spring? You'd need to fiddle with the constants a little to make it look right, but once it's fixed up it should work right for all heads. :) Since this is simply a visual effect, let's start by trying a linear system. If it turns out to be too simple we can simply add a nonlinearity. If that is still not good enough (most likely due to the head snapping back too fast), it isn't difficult to model a damped spring system undergoing all the relevant effects. Since I imagine that a jet fighter can generate head motion due to both linear acceleration and pitch I've included both terms for head pitch. Since I don't know what coordinate system FG uses, I used words for the accelerations. Also, the 'spring constants' (Ka, Kp, Kr and Ky) are really fudge factors representing both the mass of the head and the resistance to rotation. The coder will need to experiment. angle of head pitch = forward accel / Ka + (d^2/dt^2 pitch) / Kp angle of head roll = (d^2/dt^2 roll) / Kr angle of head yaw = (d^2/dt^2 yaw) / Ky Having never flown on a high performance aircraft, it is unknown to me whether the yaw effect is important. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
Jim Wilson writes:
My recommendation would be to model this head thing, probably in its own
class, and then publish data in the position or orientation path that the
viewer would read in.
We could have a class FGPilot with properties:
Which is just a 'classic' rigid body'
head {
double heading;
double roll;
double pitch;
double Xoffset;
double Yoffset;
double Zoffset;
double dx,dy,dz; // linear velocities
double dh, dp, dr; // angular velocities
}
or more simply expressed using PLIB
head {
sgCoord pos ;
sgCoord velocity ;
}
where
struct sgCoord
{
sgVec3 xyz ;
sgVec3 hpr ;
} ;
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, 7 Feb 2003 15:00:41 -0500 James A. Treacy [EMAIL PROTECTED] wrote: On Fri, Feb 07, 2003 at 09:43:59AM -0800, Andy Ross wrote: Since I imagine that a jet fighter can generate head motion due to both linear acceleration and pitch I've included both terms for head pitch. The acceleration vector AT the pilot eyepoint should probably be used. Use the X and Y components - I've mentioned this before. Aircraft rotations about all axes will potentially play a part in this, it depends on where the pilot is in relation to the CG. In fact, rotational accels will be largely responsible for the jostle effect in calm air in cruise. I wouldn't change the orientation of the head (the view) due to motion, though. I think that would be too disturbing, too distracting. But the motion of the head should be driven by the X and Y axis accelsat the pilot position, whether due to aircraft CG translational acceleration or translational accels at the pilot position due to rotational motion about the CG. Jon Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
I forgot another possible effect: spinal compression. This one, if necessary, can almost certainly be considered as being uncoupled from any head rotations. delta z = z-accel / Kspine Also, it may be that the equation for pitch of the head is too simple as the two terms can cancel each other out(*) and it would a good idea if the model got this correct. It may be that the linear model is close enough that picking the constants correctly will allow for this. Unfortunately once you start rotating things intuition doesn't work well. (*)for example a forward acceleration while pulling back on the stick. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
On Fri, 7 Feb 2003 15:21:20 -0500, James A. Treacy [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: I forgot another possible effect: spinal compression. This one, if necessary, can almost certainly be considered as being uncoupled from any head rotations. delta z = z-accel / Kspine Also, it may be that the equation for pitch of the head is too simple as the two terms can cancel each other out(*) and it would a good idea if the model got this correct. It may be that the linear model is close enough that picking the constants correctly will allow for this. Unfortunately once you start rotating things intuition doesn't work well. (*)for example a forward acceleration while pulling back on the stick. ...and then the reclining seat's effect on the spine _angle_. ..some (most?) game sim's also model grey|black|red-out etc, this angle is a factor here too. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
At 2/7/03, David Megginson wrote: For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: /accelerations/pilot/x-accel-fps_sec /accelerations/pilot/y-accel-fps_sec /accelerations/pilot/z-accel-fps_sec What we'd do is tilt the cockpit viewpoint slightly for any strong forwards/backwards or sideways accelerations. For example, a strong, forward acceleration (like a takeoff roll in a fighter jet) might tilt the view pitch angle up a degree or so, while a strong deceleration might tilt the head forward about the same amount. Sideways accelerations would cause the head to tilt sideways similarily (the view roll angle). Vertical accelerations are trickier, since they're roughtly perpendicular to the spine. The best thing here would be to adjust the vertical view offset by half an inch or so down for a strong upwards acceleration (being pushed down into your seat) or up for a strong downwards acceleration (straining up against your lap belt). If we want these to be useful and not cheesy, they'll have to be very subtle in most normal flight (i.e. a fraction of a degree) except for special situations like the initial part of the takeoff roll or heavy braking. On the other hand, if the plane is being flown by a ham-fisted sim driver, we could rock things around a little more as would be happening with real passengers (Alex has also suggested splattering the panel with virtual vomit). Jim: are you interested in adding this to the viewing architecture, or would you like me to take a try in a week or two? I don't claim to fully understand how to use these, but you can look at src/Instrumentation/slip_skid_ball.cxx for a sideways-acceleration example I ripped off from Alex's old steam code. Sounds useful. Can I suggest that this feature be enabled/disabled at the option of the user? Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
