Re: [Flightgear-devel] More DC-3 3D model progress
> That is quite impressive! Indeed ! > Vertex smoothing and transparent windows would be great... Until now it's got a transparent a**, eh, tail ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LED Fonts
Whups, should be arriving soon. This is the font that seemed to work the best of the 3 that people mentioned when I asked earlier. Curt. John Check writes: > On Monday 18 February 2002 10:22 pm, you wrote: > > On Monday 18 February 2002 09:44 pm, you wrote: > > > John, David, other panel designers, > > > > > > I have just added support for multiple panel fonts. Right now we have > > > the default (typewriter) font and an LED font. > > > > > > When specifying panel text, you can include led to > > > specify the LED font. > > > > > > The panel support code could be generalized a bit more, but this is a > > > good first step. > > > > > > (And it looks pretty cool. ) :-) > > > > > > Regards, > > > > > > Curt. > > > > Awesome, lemme sync up > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > Curt, we need the font in the base package > > ___ > 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] LED Fonts
On Monday 18 February 2002 10:22 pm, you wrote: > On Monday 18 February 2002 09:44 pm, you wrote: > > John, David, other panel designers, > > > > I have just added support for multiple panel fonts. Right now we have > > the default (typewriter) font and an LED font. > > > > When specifying panel text, you can include led to > > specify the LED font. > > > > The panel support code could be generalized a bit more, but this is a > > good first step. > > > > (And it looks pretty cool. ) :-) > > > > Regards, > > > > Curt. > > Awesome, lemme sync up > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel Curt, we need the font in the base package ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tiled panel progress
> Some reuse. I'm running a 16mb Voodoo3 3000. What will you be using? 8MB + AGP in a RagePro chipset ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tiled panel progress
Alex Perry <[EMAIL PROTECTED]> said: > > http://www.spiderbark.com/fgfs/c172r-tiled-panel.png > > http://www.spiderbark.com/fgfs/c310-tiled-panel.png > > Very nice. Do you do enough texture re-use that it'll run well on > low-texture-memory machines ? I'm doing a demo on Wednesday 8-) > > Other than that, you need some mini texture fragments with fingerprints, > scratches and other dings. It looks too neat and clean the way it is. > I really like the way that the cowling looks now, especially the corner. Some reuse. I'm running a 16mb Voodoo3 3000. What will you be using? If you run into trouble try taking the right side textures out. They are normally hidden unless you scroll over there. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LED Fonts
On Monday 18 February 2002 09:44 pm, you wrote: > John, David, other panel designers, > > I have just added support for multiple panel fonts. Right now we have > the default (typewriter) font and an LED font. > > When specifying panel text, you can include led to > specify the LED font. > > The panel support code could be generalized a bit more, but this is a > good first step. > > (And it looks pretty cool. ) :-) > > Regards, > > Curt. Awesome, lemme sync up ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tiled panel progress
On Monday 18 February 2002 08:50 pm, you wrote: > Here are a couple screen shots, the first is the C172R IFR panel with tiled > background and another shot of the c310 panel that I did last week cleaned > up a bit. There's still a couple things to work out but hopefully I can > post the code changes in the next day or so. > > http://www.spiderbark.com/fgfs/c172r-tiled-panel.png > http://www.spiderbark.com/fgfs/c310-tiled-panel.png > > Best, > > Jim > > Sweet! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Tiled panel progress
Jim Wilson writes: > Here are a couple screen shots, the first is the C172R IFR panel with tiled > background and another shot of the c310 panel that I did last week cleaned up > a bit. There's still a couple things to work out but hopefully I can post the > code changes in the next day or so. > > http://www.spiderbark.com/fgfs/c172r-tiled-panel.png > http://www.spiderbark.com/fgfs/c310-tiled-panel.png Very nice -- please send us the patches as soon as convenient. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] LED Fonts
John, David, other panel designers, I have just added support for multiple panel fonts. Right now we have the default (typewriter) font and an LED font. When specifying panel text, you can include led to specify the LED font. The panel support code could be generalized a bit more, but this is a good first step. (And it looks pretty cool. ) :-) Regards, Curt. -- 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] FlightGear Priorities
Alex Perry writes: > That doesn't seem too hard. Curt, how about having FGFS write > the values of all the properties to a file in a shellscript > acceptable fashion ? Given a collection of such files, with > names that describe the developers' opinion on survivability, > it should be easy (and fun) to generate a scripted message. You would need a serious of snapshots from (say) the last 30 seconds of flight. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] More DC-3 3D model progress
matthew law writes: > That is quite impressive! Thanks. > All done in blender/gimp? Yes, completely. After years of aversion, I found that it was actually quite easy to learn both because of the many excellent, step-by-step online tutorials. I *like* layers and masks in the Gimp now that I know how to use them. I even did a bit of script-fu, modifying an existing script a little. > Vertex smoothing and transparent windows would be great... For some reason, the vertex smoothing is not making it through the Python-based blender AC3D export script -- I have an e-mail out to the script's author. Transparent windows can come for free by using an alpha component in the textures, but I'm putting them off for now, since there's nothing to see inside the plane. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tiled panel progress
> http://www.spiderbark.com/fgfs/c172r-tiled-panel.png > http://www.spiderbark.com/fgfs/c310-tiled-panel.png Very nice. Do you do enough texture re-use that it'll run well on low-texture-memory machines ? I'm doing a demo on Wednesday 8-) Other than that, you need some mini texture fragments with fingerprints, scratches and other dings. It looks too neat and clean the way it is. I really like the way that the cowling looks now, especially the corner. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Tiled panel progress
Here are a couple screen shots, the first is the C172R IFR panel with tiled background and another shot of the c310 panel that I did last week cleaned up a bit. There's still a couple things to work out but hopefully I can post the code changes in the next day or so. http://www.spiderbark.com/fgfs/c172r-tiled-panel.png http://www.spiderbark.com/fgfs/c310-tiled-panel.png Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
> OTOH getting beyond something fairly simple would probably need > some sort of time history of key events and some aero data. Ok, here's one as example. It's the second plane I trained in, after the first one was intentionally flown acrobatically until the wings failed. This accident wasn't me ... it had already left the club I'm in by then. http://www.ntsb.gov/ntsb/brief.asp?ev_id=20010227X00520&key=1 NTSB Identification: LAX01LA102. The docket is stored in the (offline) NTSB Imaging System. Accident occurred Thursday, February 15, 2001 at San Diego, CA Aircraft:Cessna 172N, registration: N4922D Injuries: 2 Uninjured. [ all of that is trivial ] During landing rollout, the airplane veered off the runway and collided with obstacles. [ should be easy to recognize, based on position-relative-to-runway data ] At the completion of a 3.7-hour-long flight, [ data trivially available ] the tower controller advised the pilot that the local wind was from 270 degrees at 6 knots, and asked him to switch runways to the parallel. [ we don't have that feature yet ] After touchdown, the airplane was still traveling about 50 knots when, approaching runway 28L's midfield location, the pilot lost directional control. [ aka heading became significantly different from runway direction, at speed ] The left wing rose upward. The airplane veered off the runway and impacted a sign. Airport personnel reported that the collision occurred about 1,000 feet upwind of the runway's threshold. [ when we get airport signage into the scenery. More to the point, when someone create a tool, so I can add the signs to KMYF myself ] The airplane came to a stop about 550 feet farther upwind of the sign and about 200 feet north of the runway. [ also easy to do, albeit with different wording ] No mechanical malfunctions were reported with the airplane. [ we don't have a malf feature, but even if we did, this is easy ] The National Transportation Safety Board determines the probable cause(s) of this accident as follows. [ we'd need to use different words here, to avoid getting in trouble ] The pilot's failure to maintain directional control of the airplane during landing rollout. [ hrmph ] Full narrative available [ I merged it on for this message ] On February 15, 2001, about 1516 hours Pacific standard time, a Cessna 172N, N4922D, veered off the runway and collided with a taxiway sign during landing rollout on runway 28L at the Montgomery Field, San Diego, California. [ All of that should be trivial to derive from the simulator state ] The airplane was substantially damaged. Neither the airline transport certificated pilot nor passenger was injured. [ comment based on decelerations from FDM ] Plus One Flyers, Inc., San Diego, operated the airplane. [ I have no idea what we'd put for that, grin ] Visual meteorological conditions prevailed, and an instrument flight rules flight plan was filed. [ The former is trivial from the weather; the latter is hard to do for now ] The personal flight was performed under 14 CFR Part 91, and originated in Scottsdale, Arizona, about 1235 mountain standard time. [ Boilerplate, and the latter should be known by the simulator ] Airport personnel reported that the collision occurred about 1,000 feet upwind of the runway's threshold. The airplane impacted the taxiway "C" sign and veered off the runway. [ All of that should be derived from the collision transient with the object description from the scenery database. ] The airplane came to a stop about 550 feet farther upwind of the sign and about 200 feet north of the runway. [ Relative position of wreckage to first collision impact recorded ] The pilot stated to the National Transportation Safety Board investigator that during the landing rollout, as the airplane was decelerating through about 50 knots, the left wing suddenly lifted up. Thereafter, he lost control of the airplane. He additionally reported that he was unaware of the reason for this occurrence. [ The user has to write this bit within 1 minute of the crash ] No mechanical malfunctions were reported with the airplane. [ simulator malf database report ] In the pilot's partially completed accident report, he indicated that when the airplane was "almost half way down the runway" the left wing rose up, and thereafter he lost control of the airplane as it "violently" veered off the runway. The pilot also reported that when he was on final approach the tower controller reported that the wind was from 270 degrees at 6 knots. [ This bit is written after more thought ... and talking to insurance ] [ ... that's all there is to most accident reports ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
On Mon, 18 Feb 2002 16:16:25 -0800 (PST), Alex Perry <[EMAIL PROTECTED]> wrote: >Rick said: >> The ideal, but probably unobtainable, result would be a excerpt >> from the accident investigation report: >> >> 'The aircraft impacted nose down with an angle of approximately >> 83 degrees to the vertical and 3 degrees of bank. >That doesn't seem too hard. Curt, how about having FGFS write >the values of all the properties to a file in a shellscript >acceptable fashion ? Given a collection of such files, with >names that describe the developers' opinion on survivability, >it should be easy (and fun) to generate a scripted message. > >Once we have it working, we either move the script execution >into FGFS or use "popen()" to call the script and then format >the results onto the screen. > >The NTSB reports follow a pattern laid down by regulation, >which is why it wouldn't be too difficult to code up. >Given a basic version that mostly works, I suspect the >real investigators would offer comments and suggestions. There is also a serious reason for having something like this. In the days way back when I flew MSFS 2 and Falcon 1 it was sometimes difficult to tell _why_ you 'crashed'. Something to tell the user they wandered off the operating surface, landed hard, scraped the tail on takeoff etc. would be useful. OTOH getting beyond something fairly simple would probably need some sort of time history of key events and some aero data. For example, knowing that the aircraft was stalled would be a key parameter. Presumably an ADR could be simulated? But if this idea is used, lets run before we start flapping our arms and do it simple first. >> Or maybe just a balance sheet: >> >> Replacement Aircraft: X >> Litigation (Surviving Passengers and Relatives of >> non-survivors): Y >> Funeral Costs: Z >> Lost revenue: P >> Increased insurance premiums: Q > >That one is alot easier; the numbers are fairly static. >However, most users won't be interested in boring facts >so it doesn't meet the underlying entertainment goal. Its probably more 'realistic' for airliners though. Rick -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - "[Post attack] crew changes would have been based on crew availability."' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 18, 2002 at 04:09:37PM -0500, David Megginson wrote: > I have a feeling that if I were a real C-172 pilot looking at 50 kt > surface winds, I'd just leave the plane tied down and take a bus. I think you wouldn't feel very comfortable in a bus either. :-) When winds aloft are at 50-60 kts, a surface wind of 20-25 would be more realistic anyway. That is why you want multiple layers of wind. You want to do that non-stop trip from Amsterdam to Rome (fuel!), but you also want to be able to take off. - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Wind confusion. In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Mon, Feb 18, 2002 at 04:09:37PM -0500 X-S-Issue: [EMAIL PROTECTED] 2002/02/19 00:58:45 4b2f043144af2e0f6669867ab3c4d54d -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjxxlT0ACgkQN880WP6HRIvvXACdEYz4HeyQuYUqRW8b10IXtomO r8UAn3gF2nkDmVXYs6noCtcygoH3PlcT =62jO -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Layered wind.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Still not completely happy with it, but don't want to hold it off
any longer. Wind layer configuration is at the top. You can add
as many as you want, but remember to add them in order from low
to high.
Usage: nc -vve wind
===[ wind ]==
#!/bin/sh
exec awk -W interactive '
function initwinds(wN, wE, wU)
{
toplayer = 0
# wind layer configuration
setwind(0, "foot", 23, "knot", 260, "degree", 0, "foot/minute")
setwind( 1000, "foot", 40, "knot", 270, "degree", 0, "foot/minute")
setwind( 2000, "foot", 110, "knot", 280, "degree", 0, "foot/minute")
setwind( 4000, "foot", 110, "knot", 350, "degree", 0, "foot/minute")
setwind(1, "foot", 40, "knot", 050, "degree", 0, "foot/minute")
if (toplayer <= 0) {
WIND[0, "altitude"] = 0
WIND[0, "up"] = wU
WIND[0, "north"] = wN
WIND[0, "east"] = wE
toplayer = 1
}
toplayer--
}
function abs(n)
{
if (n < 0) return -n
return n
}
function sgn(n)
{
if (n < 0) return -1
if (n > 0) return 1
return 0
}
function msg(m)
{
print m > "/dev/stderr"
}
function fail(m)
{
msg(m)
exitcode = 1
exit exitcode
}
function datamode()
{
msg("entering data mode")
print "data"
msg("data mode entered")
}
function getproperty(p , ret)
{
msg("req: " p)
print "get " p
status = getline ret
msg("result: " ret)
return ret
}
function setproperty(p, v , dummy)
{
msg("set: " p " = " v)
print "set " p " " v
status = getline dummy
}
function parse_unit2(u, TOP, BOT, a, b, s, tobot)
{
tobot = 0
while (u != "") {
a = index(u, "/")
b = index(u, ".")
if (a && (b <= 0 || a < b)) {
s = substr(u, 1, a - 1)
while(s in UNITRANS) s = UNITRANS[s]
if (tobot) BOT[s]++
else TOP[s]++
u = substr(u, a + 1)
tobot = 1
}
else if (b && (a <= 0 || b < a)) {
s = substr(u, 1, b - 1)
while(s in UNITRANS) s = UNITRANS[s]
if (tobot) BOT[s]++
else TOP[s]++
u = substr(u, b + 1)
}
else {
while(u in UNITRANS) u = UNITRANS[u]
if (tobot) BOT[u]++
else TOP[u]++
u = ""
}
}
}
function parse_unit(u, TOP, BOT)
{
delete TOP
delete BOT
TOP[""] = 0
BOT[""] = 0
parse_unit2(u, TOP, BOT)
mod = 1
while(mod) {
mod = 0
for (s in TOP) if (TOP[s] > 0 && match(s, "[\./]")) {
mod = 1
parse_unit2(s, TOP, BOT)
TOP[s]--
}
for (s in BOT) if (BOT[s] > 0 && match(s, "[\./]")) {
mod = 1
parse_unit2(s, BOT, TOP)
BOT[s]--
}
}
for (s in TOP) {
while (s in BOT && TOP[s] > 0 && BOT[s] > 0) {
TOP[s]--
BOT[s]--
}
}
}
function unitconvert3(v, from, to)
{
if (from == to) return v
else if ( (from, to) in UNICONV)
return (v + UNICONV[from, to, "offset"]) * UNICONV[from, to]
else if ( (to, from) in UNICONV)
return v / UNICONV[to, from] + UNICONV[to, from, "offset"]
return "err"
}
function unitconvert4(v, d, FROM, TO)
{
for (s in FROM) if (FROM[s] > 0) {
w = ""
for (t in TO) if (TO[t] > 0) {
if (d) w = unitconvert3(v, t, s)
else w = unitconvert3(v, s, t)
if (w != "err") {
FROM[s]--
TO[t]--
v = w
break
}
}
if (w == "err") {
msg("Unable to convert:")
for (s in FROM) msg(s ": " FROM[s])
msg("to")
for (s in TO) msg(s ": " TO[s])
fail("!")
}
}
return v
}
function unitconvert2(v, from, to)
{
FTOP[""] = 0
FBOT[""] = 0
TTOP[""] = 0
TBOT[""] = 0
parse_unit(from, FTOP,
Re: [Flightgear-devel] FlightGear Priorities
Rick said: > The ideal, but probably unobtainable, result would be a excerpt > from the accident investigation report: > > 'The aircraft impacted nose down with an angle of approximately > 83 degrees to the vertical and 3 degrees of bank. There was no > evidence of rotation about any of the aircraft axes. The > airspeed was approximately 250 knots. The state of the spinner, > recovered portions of airscrew, and engine crankshaft suggest > that the engine was at flight idle with the blades feathered. > > Upon impact the engine rotated about the lower rear mounts, > breaking through the firewall as it did so. Whilst it later > detached from these mounts it initially rotated through > approximately 130 degrees, reducing the occupancy space in the > area of the forward seats as it did so. This is consistent with > the severe trauma to the lower limbs and chest suffered by the > pilot...' That doesn't seem too hard. Curt, how about having FGFS write the values of all the properties to a file in a shellscript acceptable fashion ? Given a collection of such files, with names that describe the developers' opinion on survivability, it should be easy (and fun) to generate a scripted message. Once we have it working, we either move the script execution into FGFS or use "popen()" to call the script and then format the results onto the screen. The NTSB reports follow a pattern laid down by regulation, which is why it wouldn't be too difficult to code up. Given a basic version that mostly works, I suspect the real investigators would offer comments and suggestions. > Or maybe just a balance sheet: > > Replacement Aircraft: X > Litigation (Surviving Passengers and Relatives of > non-survivors): Y > Funeral Costs: Z > Lost revenue: P > Increased insurance premiums: Q That one is alot easier; the numbers are fairly static. However, most users won't be interested in boring facts so it doesn't meet the underlying entertainment goal. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
Martin van Beilen writes: > Speaking of ground handling, all aircraft have the tendency to > slowly float sideways, even with zero wind, brakes applied and > engine(s) stopped. What's up with that? > Numerical precision errors somewhere. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
[EMAIL PROTECTED] writes: > > BTW, it's good to see that people have started experimenting with > > various combinations of wind and FDM's. There are interesting > > differences in ground handling between various models. > > > > Speaking of ground handling, all aircraft have the tendency to > > slowly float sideways, even with zero wind, brakes applied and > > engine(s) stopped. What's up with that? > > Ground handling - and *very* especially handling in a *stopped* condition - is > an acknowledged bitch to model by everyone who endeavors to model it. NASA, X- > Plane author Austin **??** (can't recall his last name at > present), Powers. > myself, > etc. > > We have ground handling pretty much figured out, but the quirks of modeling a > vehicle at rest are still being worked out. For us particularly (JSBSim > developers) there have been other issues to tackle for this current FlightGear > release - both technical and home life. This has given me, at least, some time > to think about it and I am going to try something I've had on my mind for a few > weeks as a potential solution. But it will still be a short while until I can > try it out. We acknowledge, though, that it does not work perfectly now and > that this is an important problem to solve. > > Jon > > > > ___ > 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] Wind confusion.
> BTW, it's good to see that people have started experimenting with > various combinations of wind and FDM's. There are interesting > differences in ground handling between various models. > > Speaking of ground handling, all aircraft have the tendency to > slowly float sideways, even with zero wind, brakes applied and > engine(s) stopped. What's up with that? Ground handling - and *very* especially handling in a *stopped* condition - is an acknowledged bitch to model by everyone who endeavors to model it. NASA, X- Plane author Austin **??** (can't recall his last noame at present), myself, etc. We have ground handling pretty much figured out, but the quirks of modeling a vehicle at rest are still being worked out. For us particularly (JSBSim developers) there have been other issues to tackle for this current FlightGear release - both technical and home life. This has given me, at least, some time to think about it and I am going to try something I've had on my mind for a few weeks as a potential solution. But it will still be a short while until I can try it out. We acknowledge, though, that it does not work perfectly now and that this is an important problem to solve. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 18, 2002 at 01:59:26PM -0500, David Megginson wrote:
> > It is now fixed. dir += 180 has been added back in, and the
> > JSBSim.cxx interface file has been changed to reverse the sense for
> > JSBSim.
>
> No, that's not right after all. Following a message from Jon Berndt,
> I took a peek at the property browser, and the wind-{north|east}-fps
> is the to- direction, not the from- direction.
I don't understand what you are trying to say. What's not right?
If you want the command line heading to be a from, and the NED to
be a to, you need to add those 180 degrees to convert.
BTW, it's good to see that people have started experimenting with
various combinations of wind and FDM's. There are interesting
differences in ground handling between various models.
Speaking of ground handling, all aircraft have the tendency to
slowly float sideways, even with zero wind, brakes applied and
engine(s) stopped. What's up with that?
- --
Regards, "I RADIS, do you?"
=Martin=http://www.iradis.org/
PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B
From: Martin van Beilen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Wind confusion.
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on
Mon, Feb 18, 2002 at 01:59:26PM -0500
X-S-Issue: [EMAIL PROTECTED] 2002/02/18 23:09:09
22892bd41cbcb6096d9468ba1c81dd7e
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
iEYEARECAAYFAjxxe4wACgkQN880WP6HRIvqqwCgn6vOUSRtj4ZBvvB0+zSMPMja
Q8MAn2bR9bR1H0G+YOu3+RZX25ufebtM
=D/UD
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
On Mon, 18 Feb 2002 12:30:38 -0800 (PST), Alex Perry <[EMAIL PROTECTED]> wrote: >Curt comments: >> Erik Hofman writes: >> > Alex Perry wrote: >> > > I see nothing wrong with a fireball feature ... a PLIB sequenced 3D >> > > animation that gets loaded from a file (if requested by config option) >> > > and triggered to be played by the rising edge of the "crash flag". >> > >> > Well, the way I see it, The whole time were pretending to be the pilot, >> > and then upto the point we crash all of a sudden we are a bystander? >> > That's not logical. Lets make the screen black ... >> >> Fade gently to black ... ? > >Check whether the "outside view" flag is set. If yes, use the fireball >sequence as above. If no, use the afterlife sequence. The latter is >from the fgfsbase/Scenery/Afterlife/$religion/ directory and replaces >the normally rendered scene. The default "None" we provide in the base >package is simply a black screen (as Erik suggests). The ideal, but probably unobtainable, result would be a excerpt from the accident investigation report: 'The aircraft impacted nose down with an angle of approximately 83 degrees to the vertical and 3 degrees of bank. There was no evidence of rotation about any of the aircraft axes. The airspeed was approximately 250 knots. The state of the spinner, recovered portions of airscrew, and engine crankshaft suggest that the engine was at flight idle with the blades feathered. Upon impact the engine rotated about the lower rear mounts, breaking through the firewall as it did so. Whilst it later detached from these mounts it initially rotated through approximately 130 degrees, reducing the occupancy space in the area of the forward seats as it did so. This is consistent with the severe trauma to the lower limbs and chest suffered by the pilot...' or: 'The aircraft left the sealed surface at a speed of approximately 10 knots. Almost immediately the left main gear entered a drainage ditch and the aircraft tipped forward until halted by the left forward portion of the engine bay. Damage to the airscrew was extensive but the engine retained its integrity as the shock-loading was not great. The occupant had fitted, and was wearing, a four point harness. This restrained him and, whilst shaken, he was released from hospital the next day after being kept in for observation. There was extensive damage to the airscrew, left main undercarriage and the left wingtip. This damage is repairable. Shock loading to the engine, whilst not great and causing no visually evident damage, will require its replacement.' Or maybe just a balance sheet: Replacement Aircraft: X Litigation (Surviving Passengers and Relatives of non-survivors): Y Funeral Costs: Z Lost revenue: P Increased insurance premiums: Q Do we know anyone from the NTSB or AAIB? :) Rick -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - "[Post attack] crew changes would have been based on crew availability."' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] More DC-3 3D model progress
David, That is quite impressive! All done in blender/gimp? Vertex smoothing and transparent windows would be great... All the best, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
Alex Perry writes: > For a slight headwind, or a slight tailwind, you can use the > ailerons to modify the effective angle of attack and oppose that > rolling torque. However, the stated example is exactly at 90 > degrees and thus this would have no effect. In real life, you'd > zigzag down taxiways and very carefully change the control > positions as you go (watching windsocks like an eagle). I have a feeling that if I were a real C-172 pilot looking at 50 kt surface winds, I'd just leave the plane tied down and take a bus. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
Curtis L. Olson writes: > Yes something similar happened to me the first time I saw code to an > MSVC program. Thank god it wasn't VB, then. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear Priorities
> > -- > "I'm not crazy, I'm plausibly off-nominal!" > http://www.f15sim.com - The only one of its kind. Hey. Are you paying royalties on that quote! ;-) Actually, my quote was that we wanted to be "plausible, off-nominal", meaning in outer-envelope flight we wanted to be believable in our modeling. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
On Mon, 18 Feb 2002, Curtis L. Olson wrote: > Christian Mayer writes: > > Not necessarily. > > > > When you get a strong shock (in the medical sense) it might happen that > > you see yourself as a bystander. (Happend to me once). > > Yes something similar happened to me the first time I saw code to an > MSVC program. > > Curt. > Man, I knew that was coming. I knew that all I had to do was to wait for it. *laughs* (you want shock? Try getting a price quote from Korry for a single 3/4" square illuminated switch. $1144. EACH.) g. -- "I'm not crazy, I'm plausibly off-nominal!" http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
> Alex Perry writes: > > I suspect the LaRCSim is the most accurate. It is possible to taxi > > (carefully) with those winds, but takes considerable planning and > > operation of the controls to make it work out safely. David comments: > The tests were run with the plane stationary, engine at idle, and no > brakes applied. In those circumstances, wouldn't a weathervane be most > likely? I'm not sure; I've never been in sustained winds that strong. A weathervane is a weakening effect as rotation starts; enough wind to cause rotation will also cause the aircraft to tilt over on the landing gear. Terrain shape in the vicinity of the aircraft will modify the wind flow; if there is a tiny upward component near the upwind wing, you're in trouble. Either the aircraft rolling slightly, or the wing flowing upward slightly, is enough to expose a positive angle of attack of the main wing to the wind. The wing aspect ratio inverts, so it becomes an extremely effective lifting body on the upwind side; the downwind side is baffled by the airframe and the detached boundary layer on the upper side of the wing and so has very little lift. This converts the wind-based lift into a roll torque that increases _quadratically_ with the angle of rotation (i.e. no pilot warning). For a slight headwind, or a slight tailwind, you can use the ailerons to modify the effective angle of attack and oppose that rolling torque. However, the stated example is exactly at 90 degrees and thus this would have no effect. In real life, you'd zigzag down taxiways and very carefully change the control positions as you go (watching windsocks like an eagle). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
> And they do it for entertainment value. For most people FGFS > is classified as a game. That's right up there with offensive capability > on the top 10 list at demos . Besides, we can always have a switch > to turn it off. > > TTYL > John > I think that having it be optional would be good. "real" simulators freeze on crashes or OOB activity. The "flash bang" crash does have appeal, but I'd much rather see the airplane break apart and bounce along the landscape ala Flight Unlmited. :) g. -- "I'm not crazy, I'm plausibly off-nominal!" http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASFRIFAID
Christian asks: > "Curtis L. Olson" wrote: > > Landing lights: I saw a very convincing implimentation of this in a > > sim where the ground was a 100% flat plane in all directions and they > > did their own ground lighting calcs. They used a texture to simulate > > the imperfections of the lens in the beam and it looked really cool. > > I can't think of a really good strategy for doing this in the context > > of arbitrary and complex terrain (and opengl lighting.) Maybe someone > > else with a bit of opengl experience might have some ideas. > Well, can't we *assume* that the rumway is perfactly flat? No, for two reasons: (1) little runways, 4000ft / 1km length or so, were built cheaply and tend to follow topographic features since the aircraft have no trouble with this. (2) big runways, 1ft / 2km length or more, have trouble with the max transitional slope between the surroundings and the runway surface, so tend to try to follow the general ground tendency slightly. Changes in surface angle below 0.1% are trivially visible and contribute to the visual challenge of flying at realistic airports. > IMHO it's save so assume that the landinglights are only used on the > runway. All other cases sould be too rare to really care about them. Yes, we could make many lighting methods work; unfortunately as soon as we do that, people will complain that it doesn't look right when they crash into a mountain, or do an off-field landing on grass, or similar. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
Christian Mayer writes: > Not necessarily. > > When you get a strong shock (in the medical sense) it might happen that > you see yourself as a bystander. (Happend to me once). Yes something similar happened to me the first time I saw code to an MSVC program. Curt. -- 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] FlightGear Priorities
Curt comments: > Erik Hofman writes: > > Alex Perry wrote: > > > I see nothing wrong with a fireball feature ... a PLIB sequenced 3D > > > animation that gets loaded from a file (if requested by config option) > > > and triggered to be played by the rising edge of the "crash flag". > > > > Well, the way I see it, The whole time were pretending to be the pilot, > > and then upto the point we crash all of a sudden we are a bystander? > > That's not logical. Lets make the screen black ... > > Fade gently to black ... ? Check whether the "outside view" flag is set. If yes, use the fireball sequence as above. If no, use the afterlife sequence. The latter is from the fgfsbase/Scenery/Afterlife/$religion/ directory and replaces the normally rendered scene. The default "None" we provide in the base package is simply a black screen (as Erik suggests). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASFRIFAID
"Curtis L. Olson" wrote: > > Landing lights: I saw a very convincing implimentation of this in a > sim where the ground was a 100% flat plane in all directions and they > did their own ground lighting calcs. They used a texture to simulate > the imperfections of the lens in the beam and it looked really cool. > I can't think of a really good strategy for doing this in the context > of arbitrary and complex terrain (and opengl lighting.) Maybe someone > else with a bit of opengl experience might have some ideas. Well, can't we *assume* that the rumway is perfactly flat? As we are drawing it independantly (sort of) from the rest of the scenery (AFAIK), we could use our own lighting for those few polygons. IMHO it's save so assume that the landinglights are only used on the runway. All other cases sould be too rare to really care about them. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
* [EMAIL PROTECTED] (Erik Hofman) [2002.02.18 03:52]: > Roman Grigoriev wrote: > >Hi! > >Curtis could you please tell us your priotities to next FlightGear release > >and It would be 0.7.10 or 0.8.0? > > I would like to see a 0.8.0 release (moslty bugfixes and fgat support > only). This should be the most reliable release of the past five years. > :-) > > There is no reason to prevent non-code changes though. I like your idea, Erik. I'd like to see us make a 0.8.0 release soon but with these prerequisites (IMHO of course): - erradication of FPEs - stable gear code in JSBSim - runway lighting so flying at night is worthwhile - overhaul of the I&GS manual (I'm working on this) Anything beyond that would be icing on the cake as far as I'm concerned. -- Cameron Moore / One cannot guess the real difficulties \ \ of a problem before having solved it. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
On Mon, Feb 18, 2002 at 02:23:47PM -0500, John Check wrote: > > And they do it for entertainment value. For most people FGFS > is classified as a game. That's right up there with offensive capability > on the top 10 list at demos . Besides, we can always have a switch > to turn it off. > You mean a switch to turn it on - the default should be off. :) -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
"Curtis L. Olson" wrote: > > Erik Hofman writes: > > Alex Perry wrote: > > >>>I'd move it down the list, but it would be a crowd pleaser. > > >>>People do ask for it. > > >>> > > >>From the crash reports I've read and pictures I've seen, small planes > > >>tend to snap or crumple rather than explode (often none of the above). > > >> > > > > > > The fire (non-ball) does happen occasionally, but is usually delayed with > > > respect to the accident because it takes time for fuel to leak, evaporate > > > and find something hot to get ignited by. Plenty of time to leave the area, > > > but disappointing for simulation users who want an impressive crash effect. > > > > > > I see nothing wrong with a fireball feature ... a PLIB sequenced 3D > > > animation that gets loaded from a file (if requested by config option) > > > and triggered to be played by the rising edge of the "crash flag". > > > > Well, the way I see it, The whole time were pretending to be the pilot, > > and then upto the point we crash all of a sudden we are a bystander? > > That's not logical. Lets make the screen black ... Not necessarily. When you get a strong shock (in the medical sense) it might happen that you see yourself as a bystander. (Happend to me once). CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: AW: [Flightgear-devel] compiled binaries for 0.7.9
Thanks D Luff writes: > Curtis L. Olson writes: > > > The unix zip utility had a lot of problems building a zip file that > > large last time I tried it, so if someone else wants to create a zip > > version and send it to me (or rather post it where I can fetch it) > > that would be great. > > > > http://www.nottingham.ac.uk/~eazdluf/fgfs-base-0.7.9.zip > > Cheers - Dave > > -- > [EMAIL PROTECTED] > > ___ > 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] compiled binaries for 0.7.9
Curtis L. Olson writes: > Norman has resigned from the FlightGear project for now ... :-( > Thats a great shame. My first contact with this list was Normans helpful and friendly advice on how to compile FlightGear with Cygwin. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASFRIFAID
BERNDT, JON S. (JON) (JSC-EX) (LM) writes: > (Yet Another Stupid Feature Request Inquiry From an Ignorant Developer) > > I have seen several articles (seen != fully_read_or_understood) mentioning > the modeling of "shadows" using projected texturing. Has anyone here ever > considered doing this? Is this something that is inherently not possible in > FGFS at this time? Or is it just that nobody has the time to do it? > > Shadows from ones own aircraft would of course be useful as a position cue. Shadows: Draw a line from the sun through the aircraft CG and find the intersection point with the terrain. Draw a shadow / texture polygon at the terrain intersection point (slightly raised) and oriented parallel to the current ground triangle. You will see some artifacts when the plane is passing over more complex terrain ... the shadow polygon might cut into the terrain and be partially obscured. But over most runways where we care about this the most, it should work fairly well. Landing lights: I saw a very convincing implimentation of this in a sim where the ground was a 100% flat plane in all directions and they did their own ground lighting calcs. They used a texture to simulate the imperfections of the lens in the beam and it looked really cool. I can't think of a really good strategy for doing this in the context of arbitrary and complex terrain (and opengl lighting.) Maybe someone else with a bit of opengl experience might have some ideas. Curt. -- 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: AW: [Flightgear-devel] compiled binaries for 0.7.9
Curtis L. Olson writes: > The unix zip utility had a lot of problems building a zip file that > large last time I tried it, so if someone else wants to create a zip > version and send it to me (or rather post it where I can fetch it) > that would be great. > http://www.nottingham.ac.uk/~eazdluf/fgfs-base-0.7.9.zip Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
David Megginson writes:
>
> No, that's not right after all. Following a message from Jon Berndt,
> I took a peek at the property browser, and the wind-{north|east}-fps
> is the to- direction, not the from- direction. JSBSim was using the
> from- direction already, while the other FDM's were usign the to-
> direction. In any case, the command-line option now works properly,
> and all the FDMs behave the same way; it's just that the properties
> need to be interpreted differently.
>
> So, what do we do?
>
Meteo convention is from - hence the command line should use
that.
All fdm writers can use whatever vector convention they wish
internally as long as they document it.
Since the wind-{north|east}-fps property may be accessed by any
fdm it should follow a clearly documented convention - I would
suggest the meteo convention.
Each fdm can then process the property however it likes when
converting into a vector.
For clarity, how about we rename the property from wind-
{north|east}-fps to wind-from-{north|east}-fps or wind-to{north|east}-
fps, depending on which is chosen.
How's that for a solution?
Cheers - Dave
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
Alex Perry writes: > > fgfs --aircraft=c172 --airport-id=KSFO --heading=270 --wind=0@50 > > The JSBSim C172 actually takes off, weathervanes in the air, then > > lands again facing north. The LaRCSim C172 flips over, and the > > UIUC C172 starts sliding smoothly sideways. YASim takes the > > prize for this one, since it simply weathervanes on the ground > > until it's facing north, into the wind. > > I suspect the LaRCSim is the most accurate. It is possible to taxi > (carefully) with those winds, but takes considerable planning and > operation of the controls to make it work out safely. The tests were run with the plane stationary, engine at idle, and no brakes applied. In those circumstances, wouldn't a weathervane be most likely? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
Erik Hofman writes: > Alex Perry wrote: > >>>I'd move it down the list, but it would be a crowd pleaser. > >>>People do ask for it. > >>> > >>From the crash reports I've read and pictures I've seen, small planes > >>tend to snap or crumple rather than explode (often none of the above). > >> > > > > The fire (non-ball) does happen occasionally, but is usually delayed with > > respect to the accident because it takes time for fuel to leak, evaporate > > and find something hot to get ignited by. Plenty of time to leave the area, > > but disappointing for simulation users who want an impressive crash effect. > > > > I see nothing wrong with a fireball feature ... a PLIB sequenced 3D > > animation that gets loaded from a file (if requested by config option) > > and triggered to be played by the rising edge of the "crash flag". > > Well, the way I see it, The whole time were pretending to be the pilot, > and then upto the point we crash all of a sudden we are a bystander? > That's not logical. Lets make the screen black ... Fade gently to black ... ? Curt. -- 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] Wind confusion.
[EMAIL PROTECTED] writes: > Is this now how the "system" works? The command-line option has always been meant (and documented) to give the from direction. I guess it's still up for grabs how the internal NED properties represent wind. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
Alex Perry wrote: >>>I'd move it down the list, but it would be a crowd pleaser. >>>People do ask for it. >>> >>From the crash reports I've read and pictures I've seen, small planes >>tend to snap or crumple rather than explode (often none of the above). >> > > The fire (non-ball) does happen occasionally, but is usually delayed with > respect to the accident because it takes time for fuel to leak, evaporate > and find something hot to get ignited by. Plenty of time to leave the area, > but disappointing for simulation users who want an impressive crash effect. > > I see nothing wrong with a fireball feature ... a PLIB sequenced 3D > animation that gets loaded from a file (if requested by config option) > and triggered to be played by the rising edge of the "crash flag". Well, the way I see it, The whole time were pretending to be the pilot, and then upto the point we crash all of a sudden we are a bystander? That's not logical. Lets make the screen black ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compiled binaries for 0.7.9
Erik Hofman writes: > Curtis L. Olson wrote: > > D Luff writes: > > > >>I can do. I assumed Norman would provide a MingW compiled > >>one, but he doesn't seem to be around at the moment. > >> > > > > Norman has resigned from the FlightGear project for now ... :-( > > For any particular reason, or is that unknown? His email address is in the Thanks file. I'd prefer to let him speak for himself (rather than me offering my interpretation and getting it wrong.) Norman wasn't trying to make a big public stink about his exit, and he left the door open for returning at some later date. I will say this. We are all volunteers here and no one is getting paid. Since we are all contributing out of our spare time, and for most of us that is a very limited resource, I respect that a person would choose to reallocate how they are spending their spare time. Norman made many fine contributions for which we are greatful, but it is completely up to him to choose how he wants to spend his limited spare time.. Regards, Curt. -- 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] FlightGear 0.7.9. final binaries fot Irix
> I have uploaded the new binaries of FlightGear-0.7.9 at: > http://www.a1.nl/~ehofman/fgfs/ Yeah, yeah, yeah _That_ makes me happy. Pretty nice work. More features that previous versions at same or better frame rate. _This_ is really nice, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
On Monday 18 February 2002 01:44 pm, you wrote: > John Check writes: > > > > As for me I'd like to see > > > > 1)ground explosion when plane crash the ground (I have a lot > > > > explosion textures) > > > > > > Hmm, I'm not sure I see a reason for this one. > > > > I'd move it down the list, but it would be a crowd pleaser. > > People do ask for it. > > From the crash reports I've read and pictures I've seen, small planes > tend to snap or crumple rather than explode (often none of the above). > In fact, the more full the tanks, the *less* likely an explosion, > since there's less oxygen to help the fuel ignite. Crashed planes are > often salvaged and rebuilt, even. > > Oh yeah, cars don't usually explode either, except on TV shows and > movies. > And they do it for entertainment value. For most people FGFS is classified as a game. That's right up there with offensive capability on the top 10 list at demos . Besides, we can always have a switch to turn it off. TTYL John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
> > C172 starts sliding smoothly sideways. YASim takes the prize for this > > one, since it simply weathervanes on the ground until it's facing > > north, into the wind. > > I suspect the LaRCSim is the most accurate. Yep. That was my thinking, too. Again, our gear model and high beta aero need work, still, I think. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
> fgfs --aircraft=c172 --airport-id=KSFO --heading=270 --wind=0@50 > The JSBSim C172 actually takes off, weathervanes in the air, then > lands again facing north. The LaRCSim C172 flips over, and the UIUC > C172 starts sliding smoothly sideways. YASim takes the prize for this > one, since it simply weathervanes on the ground until it's facing > north, into the wind. I suspect the LaRCSim is the most accurate. It is possible to taxi (carefully) with those winds, but takes considerable planning and operation of the controls to make it work out safely. However, that crosswind is double what the aircraft can manage at takeoff speeds, so the aircraft is likely to flip over as soon as you get a significant groundspeed, unless you manage a lucky skid-yaw turn into the wind. You should try for the intersection with the north runway and use that. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
> > I'd move it down the list, but it would be a crowd pleaser. > > People do ask for it. > From the crash reports I've read and pictures I've seen, small planes > tend to snap or crumple rather than explode (often none of the above). The fire (non-ball) does happen occasionally, but is usually delayed with respect to the accident because it takes time for fuel to leak, evaporate and find something hot to get ignited by. Plenty of time to leave the area, but disappointing for simulation users who want an impressive crash effect. I see nothing wrong with a fireball feature ... a PLIB sequenced 3D animation that gets loaded from a file (if requested by config option) and triggered to be played by the rising edge of the "crash flag". ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
David Megginson writes:
> > And guess what I discovered when diffing 0.7.8 against 0.7.9? In
> > Main/options.cxx, around line 900, someone *commented out* the
> > line "dir += 180;", thereby *changing* the definitions of
> > /environment/wind-{north,east}-fps! Okay, who did that? Just wait
> > till I get my hands on you! ;-)
>
> It is now fixed. dir += 180 has been added back in, and the
> JSBSim.cxx interface file has been changed to reverse the sense for
> JSBSim.
No, that's not right after all. Following a message from Jon Berndt,
I took a peek at the property browser, and the wind-{north|east}-fps
is the to- direction, not the from- direction. JSBSim was using the
from- direction already, while the other FDM's were usign the to-
direction. In any case, the command-line option now works properly,
and all the FDMs behave the same way; it's just that the properties
need to be interpreted differently.
So, what do we do?
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
> It is now fixed. dir += 180 has been added back in, and the > JSBSim.cxx interface file has been changed to reverse the sense for > JSBSim. All three models should now see the wind from the same > direction, but they don't behave the same -- try this at the default > airport: > > fgfs --aircraft=c172 --airport-id=KSFO --heading=270 --wind=0@50 > fgfs --aircraft=c172-yasim --airport-id=KSFO --heading=270 --wind=0@50 > fgfs --aircraft=c172-larcsim --airport-id=KSFO --heading=270 --wind=0@50 > fgfs --aircraft=c172-uiuc --airport-id=KSFO --heading=270 --wind=0@50 Given our discussion this morning, I wonder if this is right. A **3-D** wind vector (or any uniquely specified component thereof) should IMHO specify the direction the wind is blowing towards - not from; this is a true engineering vector. But, the standard way of describing wind in meteorology (and many other fields) is azimuth direction *from* and speed (because our that is where our weather *comes*from*). Subsequent to that, and with this understood, the FGInterface class of the respective FDMs must process the values as needed by the individual FDMs. Is this now how the "system" works? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
John Check writes: > > > As for me I'd like to see > > > 1)ground explosion when plane crash the ground (I have a lot explosion > > > textures) > > > > Hmm, I'm not sure I see a reason for this one. > > I'd move it down the list, but it would be a crowd pleaser. > People do ask for it. >From the crash reports I've read and pictures I've seen, small planes tend to snap or crumple rather than explode (often none of the above). In fact, the more full the tanks, the *less* likely an explosion, since there's less oxygen to help the fuel ignite. Crashed planes are often salvaged and rebuilt, even. Oh yeah, cars don't usually explode either, except on TV shows and movies. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
Martin van Beilen writes:
> And guess what I discovered when diffing 0.7.8 against 0.7.9? In
> Main/options.cxx, around line 900, someone *commented out* the
> line "dir += 180;", thereby *changing* the definitions of
> /environment/wind-{north,east}-fps! Okay, who did that? Just wait
> till I get my hands on you! ;-)
It is now fixed. dir += 180 has been added back in, and the
JSBSim.cxx interface file has been changed to reverse the sense for
JSBSim. All three models should now see the wind from the same
direction, but they don't behave the same -- try this at the default
airport:
fgfs --aircraft=c172 --airport-id=KSFO --heading=270 --wind=0@50
fgfs --aircraft=c172-yasim --airport-id=KSFO --heading=270 --wind=0@50
fgfs --aircraft=c172-larcsim --airport-id=KSFO --heading=270 --wind=0@50
fgfs --aircraft=c172-uiuc --airport-id=KSFO --heading=270 --wind=0@50
The JSBSim C172 actually takes off, weathervanes in the air, then
lands again facing north. The LaRCSim C172 flips over, and the UIUC
C172 starts sliding smoothly sideways. YASim takes the prize for this
one, since it simply weathervanes on the ground until it's facing
north, into the wind.
> > Was there a properties way to do it that is opposite to the above? Perhaps
> > we are given too much power! ;-)
>
> /environment/wind-{north,east,down}-fps
Just to be clear, these mean the *from* direction. I suppose that we
should rename them to wind-from-{north|east|down}-fps, but I don't
feel like changing all the references right now.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compiled binaries for 0.7.9
> > Norman has resigned from the FlightGear project for now ... :-( > Bummer Seconded. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compiled binaries for 0.7.9
Curtis L. Olson wrote: > D Luff writes: > >>I can do. I assumed Norman would provide a MingW compiled >>one, but he doesn't seem to be around at the moment. >> > > Norman has resigned from the FlightGear project for now ... :-( For any particular reason, or is that unknown? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compiled binaries for 0.7.9
On Monday 18 February 2002 10:30 am, you wrote: > D Luff writes: > > I can do. I assumed Norman would provide a MingW compiled > > one, but he doesn't seem to be around at the moment. > > Norman has resigned from the FlightGear project for now ... :-( > Bummer ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
On Monday 18 February 2002 04:33 am, you wrote: > Roman Grigoriev wrote: > > Hi! > > Curtis could you please tell us your priotities to next FlightGear > > release and It would be 0.7.10 or 0.8.0? > > I would like to see a 0.8.0 release (moslty bugfixes and fgat support > only). This should be the most reliable release of the past five years. > > :-) > > There is no reason to prevent non-code changes though. > > > As for me I'd like to see > > 1)ground explosion when plane crash the ground (I have a lot explosion > > textures) > > Hmm, I'm not sure I see a reason for this one. > I'd move it down the list, but it would be a crowd pleaser. People do ask for it. > > 2)runway lights support This should be #1 > > 3)aircraft landing lights > > 4)trees houses and various objects (Have objects and textures) > > 5) terrain with LODs > > 6) realisitc clouds > > I understand that it can be diffuluct to implement. > > Erik > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: AW: [Flightgear-devel] compiled binaries for 0.7.9
Michael Basler writes: > Curt, > > > Norman has resigned from the FlightGear project for now ... :-( > > Bad news... > > > > I've put a Cygwin compiled one up at > > > > > > http://www.nottingham.ac.uk/~eazdluf/fgfs-win32-bin-0.7.9.zip > > > > > Curt, can we have an accompanying *.zip file of the base package for Win > users this time? I am convinced there are several of them who never heard > about .tar and .gz let alone what to do with it. Moreover, the free Windows > unpacker knowing about .tar.gz I suggested in the manual does cost money now > (there are sure alternative, but still). > > In case you run into problems just tell me and I'll re-pack it. > > Regards, Michael The unix zip utility had a lot of problems building a zip file that large last time I tried it, so if someone else wants to create a zip version and send it to me (or rather post it where I can fetch it) that would be great. Curt. -- 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
AW: [Flightgear-devel] compiled binaries for 0.7.9
Curt, > Norman has resigned from the FlightGear project for now ... :-( Bad news... > > I've put a Cygwin compiled one up at > > > > http://www.nottingham.ac.uk/~eazdluf/fgfs-win32-bin-0.7.9.zip > > Curt, can we have an accompanying *.zip file of the base package for Win users this time? I am convinced there are several of them who never heard about .tar and .gz let alone what to do with it. Moreover, the free Windows unpacker knowing about .tar.gz I suggested in the manual does cost money now (there are sure alternative, but still). In case you run into problems just tell me and I'll re-pack it. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compiled binaries for 0.7.9
Curtis L. Olson writes: > > I can do. I assumed Norman would provide a MingW compiled > > one, but he doesn't seem to be around at the moment. > > Norman has resigned from the FlightGear project for now ... :-( That is very sad news. I hope that we'll see him back before too long. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] YASFRIFAID
BERNDT, JON S. (JON) (JSC-EX) (LM) writes: > Shadows from ones own aircraft would of course be useful as a > position cue. I'd like to see this, but I'd have other priorities first, including some decent buildings, etc., and a general TerraGear cleanup. Of course, that won't stop anyone from sending in patches ... All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASFRIFAID
(Yet Another Stupid Feature Request Inquiry From an Ignorant Developer) I have seen several articles (seen != fully_read_or_understood) mentioning the modeling of "shadows" using projected texturing. Has anyone here ever considered doing this? Is this something that is inherently not possible in FGFS at this time? Or is it just that nobody has the time to do it? Shadows from ones own aircraft would of course be useful as a position cue. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Wind confusion.
* Martin van Beilen -- Monday 18 February 2002 17:08:
> And guess what I discovered when diffing 0.7.8 against 0.7.9? In
> Main/options.cxx, around line 900, someone *commented out* the
> line "dir += 180;", thereby *changing* the definitions of
> /environment/wind-{north,east}-fps! Okay, who did that? Just wait
> till I get my hands on you! ;-)
$ cvs ann options.cxx|head -902|tail -1
m.;-)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 18, 2002 at 06:58:44AM -0600, Jon S. Berndt wrote:
> What are/is the way[s] a user can specify wind on the FGFS command line? All
> I can see is this:
>
> --wind=DIR@SPEED: specify wind coming from DIR (degrees) at SPEED (knots)
Correct. And that's the way it *should* be specified.
I did some testing with the command-line option, and it appears
that both LaRCSim and YASim have it backwards. If I start up
heading 270, and specify a wind 270@50, I get _tail_ wind with
these two models. That's weird, because LaRCSim used to get it
right in 0.7.8.
And guess what I discovered when diffing 0.7.8 against 0.7.9? In
Main/options.cxx, around line 900, someone *commented out* the
line "dir += 180;", thereby *changing* the definitions of
/environment/wind-{north,east}-fps! Okay, who did that? Just wait
till I get my hands on you! ;-)
> Was there a properties way to do it that is opposite to the above? Perhaps
> we are given too much power! ;-)
/environment/wind-{north,east,down}-fps
> Most/all users will only specify a from direction and speed. It would
> normally (IMHO) be up to the scenery model (giving us the terrain info) and
> the weather or FDM model to give us the up/down component, would it not?
Or by an external wind model connected through a network
interface.
> I still think our (JSBSim) approach to winds is the most
> intuitive, but I am open to debate.
Wind heading as set by the user should be *from*.
Vector representations of wind should be *to*. (imho).
- --
Regards, "I RADIS, do you?"
=Martin=http://www.iradis.org/
PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B
From: Martin van Beilen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Wind confusion.
In-Reply-To: <001901c1b87b$ff32ebe0$[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on
Mon, Feb 18, 2002 at 06:58:44AM -0600
X-S-Issue: [EMAIL PROTECTED] 2002/02/18 17:06:10
9132af46f20dcbed58f8fd6b83ece702
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
iEYEARECAAYFAjxxJnkACgkQN880WP6HRIt6lACfcvEbE/rPm6afhHu+ZCKQIU3d
OAEAnA1xtnzq3mlcSzvpPXrSdAfMDg8V
=DWL3
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compiled binaries for 0.7.9
D Luff writes: > I can do. I assumed Norman would provide a MingW compiled > one, but he doesn't seem to be around at the moment. Norman has resigned from the FlightGear project for now ... :-( > I've put a Cygwin compiled one up at > > http://www.nottingham.ac.uk/~eazdluf/fgfs-win32-bin-0.7.9.zip > > You can download it from there and put it on the main FlightGear > server. Ok, thanks I appreciate it. Curt. -- 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] compiled binaries for 0.7.9
Curtis L. Olson wrote: > As people build executables for these platforms it would be great to > be able to point to them. > > Dave, were you going to do the windows binaries like you did for the > pre releases? > I can do. I assumed Norman would provide a MingW compiled one, but he doesn't seem to be around at the moment. I've put a Cygwin compiled one up at http://www.nottingham.ac.uk/~eazdluf/fgfs-win32-bin-0.7.9.zip You can download it from there and put it on the main FlightGear server. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
"Jon S. Berndt" <[EMAIL PROTECTED]> said: > Was there a properties way to do it that is opposite to the above? Perhaps > we are given too much power! ;-) In the /environment path there are variables for wind direction that specify a force value as fps from east and/or north, the "sum" of which articulate direction and speed I presume. I'm not sure how the translation from the command line degrees vector is done, not to mention if it is done the "same way". The DIR vector is displayed in the environment path, if it is given, but I don't think changing it makes a difference after startup. I should double check but IIRC the up/down as represented by viewing the properties is counter-intuitive. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
From: Martin van Beilen <[EMAIL PROTECTED]> > In the same vein, it is a convention to report vertical winds as > 'to' headings. Although vertical heading is binary, it is > reported as 'to-up', not 'from-down'. So if you want to stick to > the meteo conventions, your horizontal components should be > 'from' components, while the vertical component should be 'to'. > Getting confused yet? :-) Yes, I finally "got" this reading Andy's last message. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
From: Andy Ross <[EMAIL PROTECTED]> > That is a "to" vector, by definition. Really, the > "from" convention applies to a 1-dimensional compass direction; I'm > not aware of anyone else trying to apply it to a 3D vector environment. Ooh! Yeah, that is a good point about the 3D part of it. It's been a while since I worked on the wind stuff. So, can anyone specify the following: What are/is the way[s] a user can specify wind on the FGFS command line? All I can see is this: --wind=DIR@SPEED: specify wind coming from DIR (degrees) at SPEED (knots) Was there a properties way to do it that is opposite to the above? Perhaps we are given too much power! ;-) Most/all users will only specify a from direction and speed. It would normally (IMHO) be up to the scenery model (giving us the terrain info) and the weather or FDM model to give us the up/down component, would it not? Perhaps the FGInterface object is not preparing the wind components properly for the FDM? I still think our (JSBSim) approach to winds is the most intuitive, but I am open to debate. Tony? Thoughts? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind confusion.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Feb 17, 2002 at 04:15:01PM -0600, Jon S. Berndt wrote: > We are talking about simulating an aircraft, about an > aircraft-centric phenomena, and about a phenomena that is normally reported > by humans in a particular way. Sitting on the runway, pointed with a heading > of 20 degrees, and with a wind of 20 knots from 20 degrees (as is normally > reported, that is, the *from* direction is given), the aircraft sees 20 > knots headwind. This equation in FGTranslation shows this nicely: > > vAeroUVW = vUVW + State->GetTl2b()*Atmosphere->GetWindNED(); You are right. It is a meteorological convention to report wind with a 'from' heading. That's just what it is: a convention. In the same vein, it is a convention to report vertical winds as 'to' headings. Although vertical heading is binary, it is reported as 'to-up', not 'from-down'. So if you want to stick to the meteo conventions, your horizontal components should be 'from' components, while the vertical component should be 'to'. Getting confused yet? :-) Mathematically speaking, it is just a sign issue. Neither way is more 'mathematically correct' than the other. That's why it is possible to debate this topic for years without reaching consensus. My view is simply this: air is a moving body, just like every other moving body. It has a heading and velocity, just like every other moving body. I have no hard arguments for this, it just seems to me the logical way to think of it. I doubt that physicists use from-headings when they model wind as a three-dimensional vector, but I could be wrong. If there is a convention, it is not one used in general meteorology. At least I've never seen any of our local weathermen report wind as North and East components. :-) > I know that the wind vector that originates in the NED axis points *at* 200 > degrees and that the north component of this vector would be a negative > number. But, what happens if you add the aircraft velocity and the wind > velocity vectorially? You sure don't get the aircraft total sensed velocity > vector. Depends how you define the aircraft's velocity vector. In terms of aerodynamic modelling, the aircraft is 'mounted' on the air, and moves relative to it. Add the wind vector, and you get true ground speed. If you want to go back from true ground speed to relative speed, you subtract the wind. Does that seem awkward to you? > Of course you can do it a couple of ways. It just needs to be documented. We > have fallen short there, apparently. As a last resort you could rename and clone the wind properties: /environment/wind-down-fps becomes both wind-from-down-fps and wind-to-up-fps. :-) - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Wind confusion. In-Reply-To: <005501c1b800$8c154700$[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sun, Feb 17, 2002 at 04:15:01PM -0600 X-S-Issue: [EMAIL PROTECTED] 2002/02/18 11:20:58 a789bb439a5d67ea956cbb1380001bc5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjxw1ZIACgkQN880WP6HRIuQEgCeMGsKbfd2O7Ao9B5TAQSv2nNJ blIAnRqyvQR3gEAW69X4Skxd0HEtF110 =FM8s -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
- Original Message - From: "Erik Hofman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 18, 2002 12:33 PM Subject: Re: [Flightgear-devel] FlightGear Priorities > Roman Grigoriev wrote: > > Hi! > > Curtis could you please tell us your priotities to next FlightGear release > > and It would be 0.7.10 or 0.8.0? > > I would like to see a 0.8.0 release (moslty bugfixes and fgat support > only). This should be the most reliable release of the past five years. > :-) > > There is no reason to prevent non-code changes though. The reason is that you can see what happening in real life if you manage the plane wrong way or when you land with high speed. We have good FDM to calculate conditions of crash to inplement this > > > As for me I'd like to see > > 1)ground explosion when plane crash the ground (I have a lot explosion > > textures) > > Hmm, I'm not sure I see a reason for this one. > > > 2)runway lights support > > 3)aircraft landing lights > > 4)trees houses and various objects (Have objects and textures) > > 5) terrain with LODs > > 6) realisitc clouds > > I understand that it can be diffuluct to implement. > > Erik > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Priorities
Roman Grigoriev wrote: > Hi! > Curtis could you please tell us your priotities to next FlightGear release > and It would be 0.7.10 or 0.8.0? I would like to see a 0.8.0 release (moslty bugfixes and fgat support only). This should be the most reliable release of the past five years. :-) There is no reason to prevent non-code changes though. > As for me I'd like to see > 1)ground explosion when plane crash the ground (I have a lot explosion > textures) Hmm, I'm not sure I see a reason for this one. > 2)runway lights support > 3)aircraft landing lights > 4)trees houses and various objects (Have objects and textures) > 5) terrain with LODs > 6) realisitc clouds > I understand that it can be diffuluct to implement. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
