Re: [Flightgear-devel] field of view script
Andy Ross writes: > Jim Wilson wrote: > > Ummm...why does this matter? > > Why wouldn't it? :) It would be nice to be able to at least be able overzoom and simulate a telephoto lens (as before.) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] field of view script
Andy Ross writes: > This is mind bogglingly easy to fix. But what is the desired > behavior? What I want is a limit that will tell me when I've zoomed > to as far as a human pilot would actually be able to see from the > cockpit. > > What do you guys want? If you want to overzoom only from the > non-cockpit views (which aren't "realistic" anyway), then we can > predicate it on the current view number. If you want to ignore the > feature, we can make a simple preference property. If you want both, > then we need to decide on a more complicated interface. > > Again, IMHO it's a realism thing. Computer monitors don't have the > spacial resolution that an eye does, so we have to allow for zoom. > But pilots don't usually have telescopes in the cockpit, so it should > by default be limited to something approximating real life. >From my perspective the issue is flexibility and differentiating between "policy" and "capabilities". I also don't think the "realism" argument should trump everything else. We do a *lot* of things for the sake of convenience. Is starting up in flight on a 7 mile final realistic? Is teleporting to the other side of the world realistic? Is accelerating time realistic? Is landing a helicopter on a 747 wing realistic? For that matter, is flying under a bridge something a person would realistically do in real life? Is being able to swivel my view (aka head) in multiple 360 degree circles a realistic thing? Perhaps it would be better not to answer that one. :-) There are a lot of cases where convenience, training value, or the limits of a PC computer will trump "realism". There is other cases such as fidelity of the flight dynamics where we do want realism to trump everything else. Then there are grey areas where it's not exactly clear. Do we always want to fly at the "real" time for our current location, or do we want to be able to control the time of day and choose night when it's day to practice night flying, or select day when it is night so we can do some nice sight seeing? I think it's very clever to be able to figure out the maximum real world resolution a pilot would have, but perhaps the little poppup message would say "overzoom xyz" when you get past the real world physical limitation. Being able to zoom way in is at least useful for taking screen shots and debugging scenery construction problems. In real life there exists some pretty amazing cameras and telescopes so it's not entirely unrealistic to allow arbitrary zooms. Even from a cockpit view you might consider that a passenger has some super telephoto lens on their camera, and the air is still, etc. Maybe we want to some day simulate the camera view from a UAV. It's not inconceivable that such a camera would have significant telephoto abilities and be mounted on some sort of gyro stabilization platform. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] NMEA output (i.e. faking a gps receiver for use with other moving map/gps software)
I just commited some fixes to the NMEA output to make it more usable. This allows FlightGear to to pretend it is a gps and send fake gps sentences out the serial port. You can then feed the other end of the serial cable into something running some real moving map/gps software and that software thinks it is talking to a real gps located at your current virtual flightgear position. My fixed include: 1. I switched to the correct line terminators (\r\n) 2. I fixed a variety of careless formating errors. 3. I added a faked GSA sentence along with faked HDOP and VDOP and PDOP. >From the FlightGear end, you can activate the nmea output using the following flightgear command line option: --nmea=serial,out,1,/dev/ttyS0,4800 (for the unix folks) --nmea=serial,out,1,COM1,4800(for the dos folks) Substitude with the actual serial port you are plugged into of course. Just for fun I downloaded FlightMaster which is a palm pilot application intended for real pilots. With my palm pilot in it's cradle and connected to the appropriate serial port it was able to receive the gps strings from flightgear and was properly tricked into thinking it was talking to a real gps. This isn't quite as good as connecting up a real Garmin 196 or 430, but if you already have a palm pilot or other pda, it's a lot cheaper. :-) FlightMaster is shareware ($40) so if you use it, definitely send them their $$$, they were very helpful in helping me track down my problems in the NMEA output code. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery testing
Erik Hofman writes: > Jon Stockill wrote: > > I've just been having a look at some of the new airports I've generated, > > and I've noticed an error with the new ufo model - the great big red > > anti-collision light from the front is missing ;-) > > Heh, I noticed that too recently. > I was mostly busy doing other stuff today, I'll see if I can get it > updated soon. If some one else feels like doing some updates to it, then > don't hessitate to do so. Can we double the power, add some animation, and perhaps more loosely couple the power plants? Now is when we really could use the ability to drop ordinance. I don't have the POH in front of me, but I would think that those particular engines would certainly need to expel spent fuel now and then. Regards, Curt. (Unless you are the lead dog, the view never changes) -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT re] Perthon -- Python to Perl Language Translation
Jonathan Richards writes:
> On Tuesday 09 Dec 2003 9:37 pm, Norman Vine wrote:
> > http://perthon.sourceforge.net/
> >
> > :-)
>
> Interesting - I don't often see two (purportedly) equivalent pieces of code
> together like that. I put both examples into files: the python is 668 bytes,
> whereas the perl is 1074. Is python really that much more terse than perl,
> or is it an artefact of the translation? I have a mildly pathological
> attraction to terse languages; I learned APL *many* years ago, and I have
> been known to do real-world (if not terribly professional) stuff with Icon:
> http://www.cs.arizona.edu/icon/
There's a better way to compare languages:
http://99-bottles-of-beer.ls-la.net/history-and-background.html
Minimal perl By Dave Rolsky (140 Bytes):
$b=sub{([EMAIL PROTECTED]||No)." bottles of beer on the wall\n"};
warn map{&$b.substr(&$b,0,18)."\nTake one down, pass it around\n".&$b(0).$/}0..98
Minimal python By Oliver Xymoron (133 Bytes):
a,t="\n%s bottles of beer on the wall","\nTake one down, pass it around"
for d in range(99,0,-1):print(a%d*2)[:-12]+t+a%(d-1 or'No')
Icon version by Scott E Gilbert <[EMAIL PROTECTED]>:
procedure main()
t:= table("bottles")
t[1]:= "bottle"
every n:= 100 to 1 by -1 do {
write(n, " ", t[n], " of beer on the wall.\n",
n, " ", t[n], " of beer.\n",
"Take one down, Pass it around.\n",
n-1, " ", t[n-1], " of beer on the wall.\n"
)
}
end
Regards,
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Manuel Bessler writes: > OK, No problem. Maybe we should really consider a mailinglist for that as Al > has mentioned. Even if it'll be very low traffic. > The question would be whether this would/could be hosted officially > along the other fgfs list, or if we should set up something independet > of flightgear.org > > Curt? It's not a ton of work to setup a new mailing list, however, you might consider just jumping on board with an existing home cockpit group such as simpits.org. That would make more sense to me since they've already gone to a lot of effort to collect like minded people. > My idea would be something like this: > "flightgear-hardware" -- "discussions about hardware interfacing to > flightgear, hardware design, and interface software" > > Whadda'y'all think ? If there is some overwhelming desire to add a flightgear-hardware list, I can do that, but definitely consider jumping on board with the simpits.org group. They could benefit from your knowledge and resources and I'm sure you could benefit from theirs. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway / Apron lighting advice wanted.
David Luff writes: > Now, that I've edited a few taxiways, I could do with some advice on > airport lighting before sending them off to Robin Peel. Documentation on > taxiway lighting seems quite (very) hard to come by, so could some airport > users give me some advice for various classes of airports. I'm no expert so if someone has better information, please share it. > Do aprons have edge lighting? Do large GA airports typically have > taxiway edge / center lighting? Small GA airports? Do taxiways > tend to be lit either all or none, or just the main ones sometimes. I don't think there are hard and fast rules for this. Ultimately real people spend real time and real money installing real lights. So a lot of times, smaller airports with smaller budgets have no taxiway lighting at all. KDEN has all it's taxiways very well lit, and has the green centerline lights pretty much every where. That is a newer airport. KMSP doesn't have nearly the same amount of green centerline lighting. It is a bit older airport. I'm guessing things like centerline lighting need to be installed when the taxiway is built. The surest approach would be to go poke around the actual airport, or pay close attention when you fly in/out for real. If you found the airport adminstrator and explained what you wanted to do, you might be able to get some good information from them ... maybe a lighting or wiring diagram? That would tell you pretty quick which taxiways were lit and which ones had centerline lights. If you don't want to go through all that effort, you probably have to just make your best guess. For what it's worth, a couple weeks ago I had a chance to visit a driving sim at the KMSP airport. They used their simulator for training emergency and utility vehicle drivers. Their MSP airport model is *very* impressive. They have every surface, every light, every sign modeled exactly as it is in real life. Their vendor came out and took something like 3000 digital photos for use in the 3d models. They of course had access to all the airport diagrams. They even put in the 5 tunnels and made them drivable. I don't expect that we would go to that level of detail, but if you can find the right person, and say the right sorts of things, that kind of information is probably available for most airports. > A few screenshots of the first one I've finished BTW: > > http://www.nottingham.ac.uk/~eazdluf/KGYY-1.jpg > http://www.nottingham.ac.uk/~eazdluf/KGYY-2.jpg > http://www.nottingham.ac.uk/~eazdluf/KGYY-3.jpg > http://www.nottingham.ac.uk/~eazdluf/KGYY-4.jpg > http://www.nottingham.ac.uk/~eazdluf/KGYY-5.jpg > > with the first 2 showing the current FG runways, and the final 3 the edited > airport. Looks great. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway / Apron lighting advice wanted.
David Megginson writes: > Possibly, but from what I've heard, the main reason for centreline lighting > on runways is to support Cat II and III ILS approaches (down to a 50 ft > ceiling); probably, the same applies to taxiway lighting, since you'll have > ground ops in *extremely* low visibility. I was actually talking about the green centerline lighting on taxiways. DAFIF and FAA do a pretty good job of defining this sort of thing for the actual runways, but little data is available for taxiways. > My home airport, Ottawa, is fairly busy (including two ILS approaches and > lots of big airliners), but we do not have runway or taxiway centreline > lighting anywhere. Montreal/Dorval has centreline lighting on one runway, I > think, but I don't remember seeing it on the taxiways when I flew in at > night, and that's Canada's #2 airport. > > I think that the best thing to do would be to leave taxiway centreline > lighting out by default, and only include it when you have positive > information that it's present in real life (probably only a few airports in > any country). I'd be very surprised to see it anywhere that wasn't a major > airline hub. Agreed. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [BUG] simgear/io/sg_socket.cxx: funny code
Melchior FRANZ writes: > BTW: reverting the last patch and going back to revision 1.2 fixes > the bug. But it does still not explain the "client" zombie. Strange, someone suggested this as a fix. Note that previously, read() and readline() were not consistant. the patch made them consistant. The patch also supposedly fixed a bug for someone. Something is obviously screwy here. Anyone know what's going on with this section of code? Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync not working correctly?
Matevz Jekovec writes: > Ok, I run fgfs with the following arguments: > --fg-root=/home/matevz/fgfs/data > --atlas=socket,out,1,localhost,5500,udp > --fg-scenery=/home/matevz/fgfs/data/Scenery > --airport=LJLJ > > and I run > nice terrasync -p 5500 -d /home/matevz/fgfs/data/Scenery > > And I found myself in the ocean. > > Terrasync outputs: > pos = 0,0 > lat = 0 lon = 0 > lat_dir = 0 lon_dir = 0 > mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ > /home/matevz/fgfs/data/Scenery/e000n00/e000n00 > > And that's it. > Emm... advice? Looks like fgfs isn't reporting to terrasync the right > coordinates to download? (LJLJ is in e010n040 world chunk) It might be possible that FlightGear is sending data out port 5500 before the FDM is fully initialized. I'd suggest letting it run until it looks like it has stopped rsyncing. And don't forget there is a chicken and egg problem where if you start up in a brand new area, FlightGear will initialize, not find scenery, and generate ocean tiles before terrasync has a chance to download the tiles. For now I suggest starting up flightgear, letting terrasync kick off it's downloading, then quite and restart FlightGear adn you should now pick up the newly downloaded tiles. We used to have a way to flush the tile cache, and reload it from scratch, but I think that got lost along the way during a code refactoring. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync not working correctly?
Hi Matevz, I was able to run rsync fine last night after my first reply to your problem so I believe the rsync server should be working just fine. Curt. Matevz Jekovec writes: > Curtis L. Olson wrote: > > >Matevz Jekovec writes: > > > > > >>Ok, I run fgfs with the following arguments: > >>--fg-root=/home/matevz/fgfs/data > >>--atlas=socket,out,1,localhost,5500,udp > >>--fg-scenery=/home/matevz/fgfs/data/Scenery > >>--airport=LJLJ > >> > >>and I run > >>nice terrasync -p 5500 -d /home/matevz/fgfs/data/Scenery > >> > >>And I found myself in the ocean. > >> > >>Terrasync outputs: > >>pos = 0,0 > >>lat = 0 lon = 0 > >>lat_dir = 0 lon_dir = 0 > >>mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > >>rsync --verbose --archive --delete --perms --owner --group > >>scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ > >>/home/matevz/fgfs/data/Scenery/e000n00/e000n00 > >> > >>And that's it. > >>Emm... advice? Looks like fgfs isn't reporting to terrasync the right > >>coordinates to download? (LJLJ is in e010n040 world chunk) > >> > >> > > > >It might be possible that FlightGear is sending data out port 5500 > >before the FDM is fully initialized. I'd suggest letting it run until > >it looks like it has stopped rsyncing. And don't forget there is a > >chicken and egg problem where if you start up in a brand new area, > >FlightGear will initialize, not find scenery, and generate ocean tiles > >before terrasync has a chance to download the tiles. For now I > >suggest starting up flightgear, letting terrasync kick off it's > >downloading, then quite and restart FlightGear adn you should now pick > >up the newly downloaded tiles. We used to have a way to flush the > >tile cache, and reload it from scratch, but I think that got lost > >along the way during a code refactoring. > > > > > Ok, I let it wait this time and terrasync returned a weird error: > pos = 0,0 > lat = 0 lon = 0 > lat_dir = 0 lon_dir = 0 > mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ > /home/matevz/fgfs/data/Scenery/e000n00/e000n00 > rsync: failed to connect to scenery.flightgear.org: Connection timed out > rsync error: error in socket IO (code 10) at clientserver.c(83) > mkdir -p /home/matevz/fgfs/data/Scenery/w010s10 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/w010s10/w001s01/ > /home/matevz/fgfs/data/Scenery/w010s10/w001s01 > rsync: failed to connect to scenery.flightgear.org: Connection timed out > rsync error: error in socket IO (code 10) at clientserver.c(83) > mkdir -p /home/matevz/fgfs/data/Scenery/e000s10 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e000s10/e000s01/ > /home/matevz/fgfs/data/Scenery/e000s10/e000s01 > > > Now maybe there's a problem on my side because of the router, but I > doubt it. I'll take a look later today. Is rsync server running fine on > scenery.flightgear.org? > > > - Matevz > > > > > > > > Curtis L. Olson wrote: > cite="[EMAIL PROTECTED]"> > Matevz Jekovec writes: > > > Ok, I run fgfs with the following arguments: > --fg-root=/home/matevz/fgfs/data > --atlas=socket,out,1,localhost,5500,udp > --fg-scenery=/home/matevz/fgfs/data/Scenery > --airport=LJLJ > > and I run > nice terrasync -p 5500 -d /home/matevz/fgfs/data/Scenery > > And I found myself in the ocean. > > Terrasync outputs: > pos = 0,0 > lat = 0 lon = 0 > lat_dir = 0 lon_dir = 0 > mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ > /home/matevz/fgfs/data/Scenery/e000n00/e000n00 > > And that's it. > Emm... advice? Looks like fgfs isn't reporting to terrasync the right > coordinates to download? (LJLJ is in e010n040 world chunk) > > > > It might be possible that FlightGear is sending data out port 5500 > before the FDM is fully initialized. I'd suggest letting it run until > it looks like it has stopped rsyncing. And don't forget there is a > chicken and egg problem where if you start up in a brand new area, > FlightGear will initialize, not find scenery, and generate ocean tiles > before terrasync has a chance to download the til
[Flightgear-devel] Kool site of the day ...
Kim Komando has FlightGear listed as her "kool site of the day". http://www.komando.com/ Klick on "Kim's Kool sites" followed by "Go to today's kool site." Looks like we are experiencing the "Kim Effect", but our server is holding together. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] latest AI tricks
Norman Vine writes: > http://www.boston.com/news/galleries/2003/domeplane/01.htm Nice ... :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Slackware, USB, CH yoke
Andy Ross writes: > > As always, everything seems quite 'trivial' to those who haven't > > actually tried to do it. Hurry up and build a running robot too > > while you're at it.. > > Plonk. Does anyone with a real clue have an answer for this? Sorry, not me. I was waiting until after I get finished up the flight simulator to start work on my running robot ... although my master's degree project involved parallel algorithms for pre-calculating paths for a 7 degree of freedom robotic arm and simulating the proposed motion. Does that count for anything? http://www.flightgear.org/~curt/research/ Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Cockpit Hardware Building
Alan King writes: >Rudder pedals. Been a while since I was at the controls in a Cessna > etc, how much control throw is normal? With a one foot seperation > between the pedals 4" seems like a lot, maybe too much. Currently have > 2" in and 2" out for the 4" total, but can easily shorten it up, feels > like I'd have a foot in the engine. I seem to recall that on a C172, the maximum rudder travel is about +/- 1.75 inches from the neutral point. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Cockpit Hardware Building
Alan King writes: >Yes it is. But the control feedback in the simulator EXACTLY > matching real life is not critical. For that matter a Cessna rudder > probably doesn't exactly match a P-51 rudder either, but I have no > doubts that learning rudder on said Cessna prepares you for 80 or 90 > percent of how to use a P-51 rudder. Exact matches aren't critical, > simply having some feedback and learning that you must pay attention to > the feedback and develop a feel for what is right for a particular plane > is most of it. With the sim plane being a bit different from the real > plane, you're simply learning two different planes. It's still quite > useful to have the basic feedback even if it's not exact. > >And I'm not aware of any even $10 mil simulators that are more than > approximately real, even with a driven motor proper G forces have a > noticable effect on your legs, yet are incompletely modeled. There's > only so much you can effectively do without getting in a real plane, I'm > just going for the basic 80 percent of it and leaving the other 5 or 10 > percent that could possibly be done on the ground alone. It should > still be quite effective for the cost. The FAA defines tolerances that a sim builder needs to meet in order to be certified. Control forces are something they definitely pay attention to. Rudder force for some manuever might need to be within 5 lbs of the real thing for instance. But if it takes 4 lbs of force in the real airplane, that leaves you a bit of latitude. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WGS84 changes
Andy, Why don't we go ahead and commit one of these since both sound a lot better than what we have now. Then we could do some timing tests and see if we need to consider trading precision for faster performance. Regards, Curt. Andy Ross writes: > Norman Vine wrote: > > Yes, this was written before the 'standard' was adopted and we just > > adopted it. > > > > I suggest that we use the attached geoc <-> geod transforms or a > > massaged version of them to reflect what we want for an interface > > > > Note these are arguably 'the current standard' slightly modified by me > > to just use WGS84 and to return the Earth radius at location > > This one (geoc->geod, the reverse transform is easy, and essentially > identical to mine) is about 4x faster than the one I wrote, with a > symmetric error about 1000x worse (7mm after a double transform, > instead of 6nm). > > I like (most of, see below) the code size, which is very small. I > can't find that paper on the web, though, so unfortunately the > algorithm is (literally, heh) greek to me. Do you have a pointer to a > copy? > > The implementation worries me a bit, though. There's an elaborate > dance that it does to try to special case the poles, which as far as I > can tell is purely an attempt to avoid a divide by zero in the > argument to atan(). (Pet peeve. That's what atan2() is for, ugh.) > There is "error" checking for situations that shouldn't be errors > (latitudes with magnitudes greater than 90° have an unambiguous > interpretation and *can* occur in practice due to integer conversion > issues, they aren't errors). > > Quite honestly, I like mine better. Mostly because I wrote it and > understand it better, obviously, but also because of the accuracy. > The performance difference is real but IMHO irrelevant, and a ~1cm > error is *just* at the limit of what a gear collision implementation > can tolerate. Stiff gear might have compression distances of only > 10cm or so, which makes that spurious 7mm into a noticeable bump. > > Andy > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] sample script
If anyone is interested in "external" scripting of FlightGear, I've added another quick example to $fgsrc/scripts/perl/examples/ The reset.pl script will reset FlightGear to a particular airport/runway at a fixed interval (i.e. every 5 minutes.) It also sets the time of day to noon and makes sure the engine get's started. This might be useful for a demo environment where you have a line of kids wanting to take turns ... Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
Martin Spott writes: > Melchior FRANZ <[EMAIL PROTECTED]> wrote: > > * Martin Spott -- Sunday 21 December 2003 00:07: > >> I tend to include OpenSource drivers only, no proprietary stuff. > > > I understand, but then the whole effort is pretty useless. There are > > too many nVidia card users, and no open source 3D drivers for them. > > As you already said: > > "[...] The problems with licenses of different proprietary graphic > cards aren't such a great motivation." > > I second that. Why shouldn't people use cards with OpenSource drivers > for a presentation of an OpenSource flight simulator ? > FlightGear developers are _that_ much careful when it's about including > other people's work. Why shouldn't they take the same care for their > graphics card drivers ? The problem is that the best quality, highest performance cards are either made by nvidia and ATI with binary only drivers. The open-source drivers have flaws and are lower quality. I don't mean that as a criticism, it's just that the in-house nvidia/ati developers have a huge advantage over the open-source developers in terms of access to card info and assistance with problems. These binary only drivers are given away for free; I personally don't have a problem with using them. People have to work and feed their families too. Open-source is great, and I'm proud to be part of one of the larger open source projects out there. But personally, I don't mind if FlightGear runs on top of proprietary operating systems or drivers such as Mac OS, sgi, windows, solaris, or a binary nvidia driver on linux. There needs to be a balance between idealism and pragmatism. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
Martin Spott writes: > Jon Stockill <[EMAIL PROTECTED]> wrote: > > > And the open source drivers don't support some of the newer ATI cards. > > Sorry, why do you buy cards that are not supported by OpenSource > drivers ? You are developing OpenSource software, why don't you take > care of that. I can't accept this as a valid argument. > I do look out for drivers _before_ I buy a card for my or my customers' > PeeCee (currently I don't even own a PC ;-) Is it sgi machines that you run on? Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
Martin Spott writes: > Not many, but on the other hand you won't have much trouble with the > BIOS when you think about a standalone FlightGear CD. Dealing with a > bunch of different kernel modules for autodetecting different vendors' > cards might prove to end in a huge mess. This _is_ very pragmatic > thinking, I don't think this big mess is the fault of vendors with binary drivers. OpenGL support on Linux has historically been a big mess and it's still a pain to get going on a lot of systems and especially for new users. Much of this is because Linux/XFree86 just didn't have infrastructure to support it in the early days when 3d cards started to become available for pc's. If there had been a driver standard when all this started, I'm sure companies like nvidia would have adopted it. But there wasn't (DRI was under development, but it just wasn't there quickly enough.) Nvidia chose to go their own route so they could get drivers out the door. But this discussion is getting very "political" and we do a *lot* better if we concentrate on FlightGear rather than politics! Thanks, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
Alex Perry writes: > From: Martin Spott <[EMAIL PROTECTED]> > > Jon Stockill <[EMAIL PROTECTED]> wrote: > > > And the open source drivers don't support some of the newer ATI cards. > > Sorry, why do you buy cards that are not supported by OpenSource > > drivers ? You are developing OpenSource software, why don't you take > > care of that. I can't accept this as a valid argument. > > I do look out for drivers _before_ I buy a card for my or my customers' > > PeeCee (currently I don't even own a PC ;-) > > There is little point making a Linux based LiveCD of FGFS, if it can only be > used on specific computers that a knowledgable person has already checked. > With that constraint, we might as well either > (a) do a full manual install of Linux with the driver downloading, or > (b) use the Windows version of FGFS and set the CDROM up for AutoRun. > Remember, the idea of the LiveCD was that people could use it at home. > > >From the pragmatic point of view, if (b) is the right way to go, I've got > no objections to making the script up on a Linux machine then burning a > copy of the standard AutoRun FGFS image with the new script file inserted. > I won't be able to _use_ the CDROM myself, but I can still hand it out ... Alex, For what it's worth, the cd distribution I've assembled has a ready to run copy of windows flightgear on it. Just pop in the cd, double click on the runfgfs.bat file and you are up and running. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
Hi Martin, Martin Spott writes: > Especially the mess with NVidia's drivers is the manufacturer's fault. > ATI at least _tries_ to conform with the standards proposed by the DRI. > With ATI you can copy the DRI driver module and the kernel module > (after tweaking the build script) to the appropriate places. > With NVidia (at least the last time I looked at their drivers) you have > to: I will address these points, since they are mostly false and/or misleading. > a) Unload the kernel's GART module during the autodetection and load >NVidia's special kernel module, Nvidia's kernel module does have an AGP driver, but it is smart enough to not activate this portion of the driver if the linux GART module is already there. As far as I know it has always been this way. Depending on your system, one or the other may work better for you though, so the nvidia readme encourages try the "other" one if you have problems with the first. And nvidia does provide full source for their own kernel module. > b) replace the OpenGL libraries, Yes this is allowed. Unfortunately XFree86/Mesa don't (or at least didn't) put the opengl libs where the linux standard said they should, nvidia did. That causes a huge mess if you have multiple opengl libs on your system and you aren't sure which one's your app is picking up. Like I say, this was a big mess before nvidia got involved. Especially consider that prior to that, the only way to do opengl in a window on linux was with a voodoo3 card. To get this running, you pretty much had to grab XFree86 cvs tree and build it yourself. This was 100x harder to get running than the approach nvidia used. > c) run a special X Server. Nvidia gives you a new driver (nvidia vs. nv) for your X server, but you have never needed a special X server. > _This_ is what I'd call a huge mess. I will continue to assert that what nvidia was trying to plug into was already a huge mess in terms of supporting hardware accelerated opengl within XFree86. This is a hard problem and many smart people were struggling with it. They came up with a reasonable solution, DRI, but it just wasn't ready to go when nvidia was ready to go. You at least have to credit nvidia for going out on a bit of a limb at the time to even support linux. This was *huge* for people who had been struggling along with voodoo1,2,3 cards and were living with very frustrating bugs in Mesa or in mesa's interface to the voodoo cards. Suddenly along came nvidia and we were able to get fast and correct rendering for the first time ever under linux. This was huge! I personally am very greatful to nvidia for this. They made linux a viable 3d platform. > I don't like ATI's approach either but these guys show that things > could have been done at least in a significant better way. Yes, > there was no 3D standard for Linux when 3D boards for PeeCees became > affordable. But NVidia's driver effort was very late as well. They > _would_ have had the chance to stick to DRI standards but they > simply don't have any interest into doing anything different from > "their own way". nvidia's effort was a *lot* earlier than ATI's. Yes there was some disappointment that they didn't follow the DRI standards, but I think you can make a plausible argument that the DRI standard was not fully fleshed out when nvidia started developing their linux drivers. I still don't see how any of this rises to the level of causing someone to boycott their company. And as you say, you are running hp, sgi, and ibm machines. I can't imagine every byte of code on those machines is fully open source. If you are actually running all open source operating systems and drivers on all these machines, then you are definitely not doing any opengl on those machines. Again, I see absolutely no problem with running the vendor's os, or linux or whatever you want on those machines, but I find it a bit odd that you are arguing so strongly for others to not run any proprietary code or drivers, when clearly you must be doing this yourself. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
Martin writes: > It became sort of a hobby to collect used Unix workstations. I have > an Octane with MXI graphics and TRAM as workplace at home, but this > machine (only 195 MHz) turned out not being able to keep up with > recent development. Its CPU is simply too slow and can't cope with > all the trees and buildings. I still wonder why this brings the > machine to its knees because there are a lot of applications out > there, displaying fancy stuff on such a machine at reasonable frame > rates. Maybe these applications' characteristics are not comparable > to flight simulation and the software probab=F6y is specifically > optimized for SGI's graphics subsyste= m. > > I also have a HP Visualize C240 (donation from a customer) but this > one also has only 200 MHz CPU cycle. I have an RS6k with 200 MHz > (per CPU, eight of them) which won't serve, the SPARC has only 90 > MHz (maximum, depending on what CPU set I put into it). The old > Motorola based machines will be _waaay_ too slow. Hi Martin, So should I assume that you are running fully open-source operating systems, and fully open-source drivers on all your own hardware? :-) > I have e workplace at a customer's location with a PC where I > plugged my own graphics card which serves as temporary FlightGear > testbed, I would love to hear which card/drivers you are using at your customer's location. Are there any rendering bugs? Any odd xserver crashes? What kind of performance are you getting compared to nvidia. If you have found a rock solid, high performance, correctly rendering open-source solution, I'm sure a lot of people would love to hear the specific details. For my day job I manage a research driving sim. We run linux on all our visual channels and are using nvidia hardware/drivers. For this system we can't tolerate driver crashes or rendering errors. This system isn't for play or hobby or expermentation, it is for doing real, paid research so it needs to work all the time. (To be fair, there are many other reasons why it doesn't work all the time, but none of them are video/3d/driver related.) If there is a 3d card with open-source drivers that could perform as well as nvidia in a do-or-die environment, I'd like to hear about it, because to date, I have yet to see anything else that compares. Regards, CUrt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LiveCD for FGFS - suggestion
Martin Spott writes: > I never owned an NVidia card, so I can't compare performance. Maybe > someone else has the opportunity to do that: Currently I have a > Radeon7500 plugged into a Pentium3/600 (I believe this one is still > running at 66 MHz external clock) with standard SuSE-9.0 XFree (built > from XFree86-4.3.0.1) and the daily CVS build gives me 10 fps when > sitting on the default location at noon. Ideally what I like to shoot for is a solid 60hz. If you set your monitor to refresh at 60hz and then lock the rendering to the vblank signal, (and you can get a solid 60hz out of flightgear) then you get extremely smooth and fluid frame rates. It's *really* nice. It makes those little frame rate blips and glitches seem incredibly annoying after you've seen FG running at a solid 60hz. > I've seen quite a lot of rendering errors and crashes during > _development_ of the DRI (I've been testing DRI CVS trees almost since > I got the first Radeon) and by trying out experimental features (T&L). > The only drawback was the official release of XFree86-4.3, which was > released with a completely outdated and buggy Radeon driver. David > Dawes knew that when he did the release :-/ > Linux distributors knew that as well and put a working one into their > distros (as far as I remember). XFree86-4.4 will be an excellent choice > as long as you stick to boards up to Radeon9200 (I'd have to look up > these numbers because I didn't bother to remember). > > What people have already been suggesting in the 'early days' and what I > refused to believe for quite a long period (which partially made me > purchase my first SGI): The performance of the graphics card appears > to have very little influence on the frame rate of FlightGear. At least > I wasn't able to recognize any significant change when switching > between these cards I mentioned above. Even the early PCI cards did a > remarkable good job - with stock XFree86-4.x. The newer cards are faster. What that gives you is the ability to run at higher resolutions and still maintian your target frame rate. Or it gives you the ability to turn up the FSAA and still hit your target frame rate; or turn up anisotropic texture filtering and keep your frame rates going. FSAA can make a big difference in reducing aliasing artifacts and anisotropic texture filtering can make the texture (especially the runway marking textures) much sharper. Definitely play with these features if you haven't. Unfortunately, the older middle-ages cards, just don't have the horsepower to run these more advanced features at high resolution and still keep a decent frame rate. In my mind, that is the big win for the newer cards. As you point out, FG currently isn't using any advanced rendering tricks of the newer cards. Someday we'll probably want to look into some spiffier graphical effects, but hey, people need a reason to buy MSFS. We aren't here to put anyone out of business. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Merry Christmas
Merry Christmas from Minnesota. I just received this so I thought I'd pass it along in case other's hadn't seen it yet ... Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org Twas the night before Christmas and out on the ramp, Not an airplane was stirring, not even a Champ. The aircraft were fastened to tiedowns with care, In hopes that come morning, they all would be there. The fuel trucks were nestled, all snug in their spots, With gusts from two-forty at thirty-nine knots. I slumped at the fuel desk, now finally caught up, And settled down comfortably, resting my butt. When the radio lit up with noise and with chatter, I turned up the scanner to see what was the matter. A voice clearly heard over static and snow, Called for clearance to land at the airport below. He barked his transmission so lively and quick, I'd have sworn that the call sign he used was "St. Nick." I ran to the panel to turn up the lights, The better to welcome his magical flight. He called his position, no room for denial, "St. Nicholas One, turnin' left onto final." And what to my wondering eyes should appear, But a Rutan-built sleigh, with eight Rotax reindeer! With vectors to final, down the glideslope he came. As he passed all the fixes, he called them by name: "Now Ringo! Now Tolga! Now Trini and Bacun! On Comet! On Cupid!" What pills was he takin?? While controllers were sittin' and scratchin' their heads, They phoned up my office and I heard it with dread. The message they left was both emphatic and dour; "When the fat guy pulls in, have him please call the tower." He landed like silk, the sled runners sparkling. And I heard, "Left at Charlie," and "Taxi to parking." He slowed to a taxi, turned off of three-oh, And stopped on the ramp with a "Ho-ho, ho-ho." He stepped out of the sleigh and smiled at my shock, As I ran out to meet him with my best set of chocks. His red helmet and goggles were covered with frost, And his beard was all blackened from reindeer exhaust. His breath smelled like peppermint, gone slightly stale, And he puffed on a pipe, but he didn't inhale. His cheeks were all rosy and jiggled like jelly, His boots were as black as a cropduster's belly. He was chubby and plump, in his suit of bright red, And he asked me to "fill it, with hundred low-lead." He came dashing in from the snow-covered pump, I knew he was anxious to be drainin' the sump. I spoke not a word but went straight to my work, And filled up the sleigh, without being a jerk. >From the restroom he returned with a sigh of relief, Then picked up a phone for a Flight Service brief. And I thought as he silently scribed in his log, These reindeer could land in an eighth-mile fog. He completed his pre-flight, from the front to the rear. Then he put on his headset and I heard him yell, "Clear!" And laying a finger on his push-to-talk, He called up the tower for clearance and squawk. "Take taxiway Charlie, the southbound direction, Turn right three-two-zero at pilot's discretion." He sped down the runway, the best of the best, "Your traffic's a Grumman, inbound from the west." And I heard him proclaim as he climbed through the night, "Merry Christmas to all! I have traffic in sight." - Anonymous - ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear CVS - error
Ok, should be fixed ... [EMAIL PROTECTED] writes: > Am Samstag, 27. Dezember 2003 15:55 schrieb Jacek: > > I have just tried to update from cvs: > > > > > > cvs update: Updating simgear/compatibility > > cvs update: Updating simgear/compatibility/MIPSpro721 > > cvs update: failed to create lock directory for > > `/var/cvs/SimGear-0.3/SimGear/simgear/compatibility/MIPSpro721' > > (/var/cvs/SimGear-0.3/SimGear/simgear/compatibility/MIPSpro721/#cvs.lock): > > Permission denied > > cvs update: failed to obtain dir lock in repository > > `/var/cvs/SimGear-0.3/SimGear/simgear/compatibility/MIPSpro721' > > cvs [update aborted]: read lock failed - giving up > > > > I have never seen this before. Any suggestion? > > Regards, Jacek. > > > > > I have the same problem. > > I decided to wait until the problem is fixed. :) > > > Best Regards, > Oliver C. > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear CVS - error
Erik Hofman writes: > Curtis L. Olson wrote: > > Ok, should be fixed ... > > >>>(/var/cvs/SimGear-0.3/SimGear/simgear/compatibility/MIPSpro721/#cvs.lock): > >>>Permission denied > > Do you have any idea what is causing these problems? > As far as I can tell everything went smooth. When new directories are created, they don't seem to automatically get the correct group id. I haven't had time to look into the problem. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/dc3/Models dc3-dpm.ac, 1.7, 1.8 dc3-dpm.xml, 1.10, 1.11
David, (Andy?)
It appears that in the latest cvs, we have lost the ability to control
the engines independently. Previously you could type
... etc. to select an engine. Then '{' and '}'
would select the magnetos. Finally, "space bar" would kick in the
starter motor for as long as it was depressed.
This seems to only work for , but applies to all engines, not
just the first one.
Any ideas?
Also, the dc3 model animation appears to still have some references to
engine[0] for the right prop animation. I will commit a fix for that.
Thanks,
Curt.
David Megginson writes:
> Update of /var/cvs/FlightGear-0.9/data/Aircraft/dc3/Models
> In directory baron:/tmp/cvs-serv4608/Models
>
> Modified Files:
> dc3-dpm.ac dc3-dpm.xml
> Log Message:
> Add a propeller disk for the right propeller as well.
>
> Select propeller disk at 500 rpm or above.
>
>
> Index: dc3-dpm.ac
> ===
> RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/dc3/Models/dc3-dpm.ac,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -C2 -r1.7 -r1.8
> *** dc3-dpm.ac20 Nov 2003 10:03:37 - 1.7
> --- dc3-dpm.ac29 Dec 2003 21:34:32 - 1.8
> ***
> *** 8339,8340
> --- 8339,8571
> 32 0.5 0.5
> kids 0
> + OBJECT poly
> + name "RightPropeller.Fast"
> + loc -0.729208 -1.53638 -2.90127
> + numvert 33
> + 0 0 1.55
> + 0 0.30239 1.52022
> + 0 0.593159 1.43201
> + 0 0.861134 1.28878
> + 0 1.09602 1.09601
> + 0 1.28878 0.861133
> + 0 1.43201 0.59316
> + 0 1.52022 0.302391
> + 0 1.55 0
> + 0 1.52022 -0.30239
> + 0 1.43201 -0.593159
> + 0 1.28878 -0.861134
> + 0 1.09602 -1.09601
> + 0 0.861134 -1.28878
> + 0 0.593159 -1.43201
> + 0 0.30239 -1.52022
> + 0 -1.19209e-007 -1.55
> + 0 -0.30239 -1.52022
> + 0 -0.593159 -1.43201
> + 0 -0.861134 -1.28878
> + 0 -1.09602 -1.09601
> + 0 -1.28878 -0.861134
> + 0 -1.43201 -0.593159
> + 0 -1.52022 -0.30239
> + 0 -1.55 4.76837e-007
> + 0 -1.52022 0.302391
> + 0 -1.43201 0.59316
> + 0 -1.28878 0.861134
> + 0 -1.09602 1.09601
> + 0 -0.861134 1.28878
> + 0 -0.593159 1.43201
> + 0 -0.30239 1.52022
> + 0 0 0
> + numsurf 32
> + SURF 0x20
> + mat 3
> + refs 3
> + 0 1 0.5
> + 1 0.990393 0.597545
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 1 0.990393 0.597545
> + 2 0.96194 0.691342
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 2 0.96194 0.691342
> + 3 0.915735 0.85
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 3 0.915735 0.85
> + 4 0.853553 0.853553
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 4 0.853553 0.853553
> + 5 0.85 0.915735
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 5 0.85 0.915735
> + 6 0.691342 0.96194
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 6 0.691342 0.96194
> + 7 0.597545 0.990393
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 7 0.597545 0.990393
> + 8 0.5 1
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 8 0.5 1
> + 9 0.402455 0.990393
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 9 0.402455 0.990393
> + 10 0.308658 0.96194
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 10 0.308658 0.96194
> + 11 0.15 0.915735
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 11 0.15 0.915735
> + 12 0.146447 0.853553
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 12 0.146447 0.853553
> + 13 0.0842652 0.85
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 13 0.0842652 0.85
> + 14 0.0380602 0.691342
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 14 0.0380602 0.691342
> + 15 0.00960734 0.597545
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 15 0.00960734 0.597545
> + 16 0 0.5
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 16 0 0.5
> + 17 0.00960739 0.402455
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 17 0.00960739 0.402455
> + 18 0.0380602 0.308658
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 18 0.0380602 0.308658
> + 19 0.0842652 0.15
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 19 0.0842652 0.15
> + 20 0.146447 0.146447
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 20 0.146447 0.146447
> + 21 0.15 0.0842651
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 21 0.15 0.0842651
> + 22 0.308658 0.0380602
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 22 0.308658 0.0380602
> + 23 0.402455 0.00960733
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 23 0.402455 0.00960733
> + 24 0.5 0
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 24 0.5 0
> + 25 0.597545 0.00960738
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 25 0.597545 0.00960738
> + 26 0.691342 0.0380603
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 26 0.691342 0.0380603
> + 27 0.85 0.0842652
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 27 0.85 0.0842652
> + 28 0.853553 0.146447
> + 32 0.5 0.5
> + SURF 0x20
> + mat 3
> + refs 3
> + 28 0.853553 0.146447
> + 29 0.915735 0.15
> + 32 0.5 0.5
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/dc3/Models dc3-dpm.ac, 1.7, 1.8 dc3-dpm.xml, 1.10, 1.11
Andy Ross writes:
> Curtis L. Olson wrote:
> > David, (Andy?)
> >
> > It appears that in the latest cvs, we have lost the ability to control
> > the engines independently.
>
> This one is mine. The recent Nasal stuff contains a rework of the
> engine handling to allow for arbitrary numbers of engines, and avoid
> the "why are there 10 engines on the skyhawk?" issue.
The engine selection code seems to work ok based on examining the
property tree.
It seems like the stepMagnetos() and startEngine() routines must be at
fault. But I agree, from an initial reading, I don't see any obvious
faults.
I see this also with --aircraft=c310 which I believe is a jsbsim
aircraft.
> > Previously you could type... etc. to
> > select an engine. Then '{' and '}' would select the magnetos.
> > Finally, "space bar" would kick in the starter motor for as long as it
> > was depressed.
>
> Let me take a look. I presume you're seeing this with the DC-3? The
> code (selectEngine(), stepMagnetos() and startEngine() in
> controls.nas) looks more or less correct at first reading. I'm pretty
> sure I remember testing this with a multiengine aircraft...
Ok, thanks for looking into this, hopefully it is something simple.
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/dc3/Models dc3-dpm.ac, 1.7, 1.8 dc3-dpm.xml, 1.10, 1.11
Jon S Berndt writes:
> On Mon, 29 Dec 2003 15:49:30 -0600
> "Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> >David, (Andy?)
> >
> >It appears that in the latest cvs, we have lost the ability to control
> >the engines independently. Previously you could type
> > ... etc. to select an engine. Then '{' and '}'
> >would select the magnetos. Finally, "space bar" would kick in the
> >starter motor for as long as it was depressed.
>
> Was this an FDM-dependent problem? Or, was it for all FDM's?
It appears (to me) to be a property setting problem. Andy, does nasal
have the ability to dump console output for temporary debugging?
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/dc3/Models dc3-dpm.ac, 1.7, 1.8 dc3-dpm.xml, 1.10, 1.11
Andy Ross writes:
> Curtis L. Olson wrote:
> > David, (Andy?)
> >
> > It appears that in the latest cvs, we have lost the ability to control
> > the engines independently.
>
> This one is mine. The recent Nasal stuff contains a rework of the
> engine handling to allow for arbitrary numbers of engines, and avoid
> the "why are there 10 engines on the skyhawk?" issue.
>
> > Previously you could type... etc. to
> > select an engine. Then '{' and '}' would select the magnetos.
> > Finally, "space bar" would kick in the starter motor for as long as it
> > was depressed.
>
> Let me take a look. I presume you're seeing this with the DC-3? The
> code (selectEngine(), stepMagnetos() and startEngine() in
> controls.nas) looks more or less correct at first reading. I'm pretty
> sure I remember testing this with a multiengine aircraft...
For what it's worth, I can control the engines independently if I
manually manipulate the correct properties, so this has to be some
problem with the nasal scripts not setting the properties correctly.
Regards,
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/dc3/Models dc3-dpm.ac, 1.7, 1.8 dc3-dpm.xml, 1.10, 1.11
Andy Ross writes:
> Curtis L. Olson wrote:
> > David, (Andy?)
> >
> > It appears that in the latest cvs, we have lost the ability to control
> > the engines independently.
>
> This one is mine. The recent Nasal stuff contains a rework of the
> engine handling to allow for arbitrary numbers of engines, and avoid
> the "why are there 10 engines on the skyhawk?" issue.
>
> > Previously you could type... etc. to
> > select an engine. Then '{' and '}' would select the magnetos.
> > Finally, "space bar" would kick in the starter motor for as long as it
> > was depressed.
>
> Let me take a look. I presume you're seeing this with the DC-3? The
> code (selectEngine(), stepMagnetos() and startEngine() in
> controls.nas) looks more or less correct at first reading. I'm pretty
> sure I remember testing this with a multiengine aircraft...
Andy,
The following line is failing in the stepMagneto() and startEngine()
functions. If the first engine is selected, this returns 1 for every
engine. If any other engine is selected, this returns 0.
select = sel.getChild("engine", i);
Could there be a bug in this form of getChild()?
If I rewrite the function to avoid using getChild() things work again,
for instance:
startEngine = func {
sels = props.globals.getNode("/sim/input/selected").getChildren("engine");
engs = props.globals.getNode("/controls/engines").getChildren("engine");
count = size(sels);
if (size(engs) < count) {
count = size(engs);
}
for(i=0; ihttp://www.flightgear.org/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/dc3/Models dc3-dpm.ac, 1.7, 1.8 dc3-dpm.xml, 1.10, 1.11
Andy Ross writes: > Sure, there's a print() function which uses SG_LOG; for exactly this > purpose. There's even a fancy dump() method on a property node that > you can use to dump a property tree to the console. Ok, thanks, I eventually found it. Quite useful, thanks. :-) > It turns out to be a missing feature in the C++ code. The > Node.getChild() function worked for the getChild(name) variant, but > silently ignored the second argument for a getChild(name, index). I > just forgot to write it, apparently. :) > > An additional issue was that the number of /sim/selected/engines[n] > properties (one) in the default configuration didn't match the > actual number of engines, so engine 2 would always look > "unselected". I fixed this via a Nasal hack that patches things up > after initialization, but we should consider unifying these trees > somehow (for example, by putting the selected properties under > /controls/engines). I will vote for moving this into the tree with the engine controls. That should make the code a bit simpler. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Output/Input of IGC files for FG
Pablo J. Rogina writes: > I was following the FG evolution since a long time, and I´m now willing to > to get involved to Flightgear. I think is quite a project where I´m to be > able to merge two of my hobbies: aviation and computing. > > In order to contribute, I've selected to provide FG with the ability to > read/write IGC files, a format developed by the International Gliding > Commission used mainly in flight recorders aboard sailplanes in order to > register the flight during a tournament. > > I´ve posted the same goal back in August 2002, but several personal > considerations made me unable to write the appropiate code. Now I'm released > from some obligatons, and hope to have enough time to indeed complete this > feature. > > I think allowing FG to read/write IGC files could provide some new > capabilities, to mention a few: > * Replay actual flights recorded with real flightrecorders: this will allow > pilots to review their flights from within FG, being able to watch to the > environment, the instruments, etc. that somehow could be missed to them > during the actual flight (as they´re busy trying to do their best flight) > * Record a simulated flight in whatever plane used in FG and then visualize > that flight in 3D through several available commercial and also open source > software (KFlog -www.kflog.org- or GPLIGC > karl.min.uni-bremen.de/kruegerh/GPLIGC/GPLIGC.html): This add a new > dimension (altitude) over plotting the course over a map (using for example > Atlas). > * For flightrecorder manufacters, could allow using FG as a simulation > engine to test their recorders > > If you think the proposal is acceptable, I´ll start to work on it. Any > project leader/developer who I have to report to? > > Thanks in advance for your attention. > > Pablo J. Rogina Hi Pablo, This sounds interesting and useful. Feel free to email me about it offline, but it sounds like you just need to add a protocal module in $fgfs/src/Network/ (this is maybe growing into a slight misnomer, but that is where you'd want to put it.) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain shadows and VASI
Hoyt A. Fleming writes: > A month or so ago I noticed that the VASI lights vary based upon the pitch > of the aircraft. This is a bug (or implimentation limitation) or whatever you want to call it. It's high on the todo list to be fixed. > Over the holiday break, I noticed that the terrain shadows also vary > based upon the pitch of the aircraft. Strange, I've never noticed this myself. Can you describe some simple procedure to demonstate the problem. I just went up for a test flight and wasn't able to notice anything along these lines. > I spent a couple of hours tracing the lighting code but did not > locate any location to compensate for the pitch of the aircraft. If > anyone can provide a pointer to the appropriate routine to fix the > lighting problem, I am willing to take a crack at it. The only thing I can think of is if there are specular attributes associated with the terrain surface, these may cause lighting changes when the view direction changes. But I don't see this happening myself. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable VASI light observations
Originally I tried to leverage an environment mapping trick to impliment the VASI. However, my understanding of how this work was not quite right, nor was the understanding of the person who suggested this trick in the first place. The result is that the VASI is dependent on the view direction, and not on your relative position to the VASI. This is clearly wrong and I need to backup and do it over. This is high on my todo list, but it will involve a substantial amount of effort to do correctly. There is no trivial fix to be had here. We need a complete reimplimentation from scratch. I was hoping for some time over the holidays, but most of my time is getting sucked up with family obligations and events and get togethers. And my wife thinks she should be seeing progress on our basement remodeling project. Regards, Curt. Dave Perry writes: > I have posted this observation before. but since the topic came up > again, I will post this again. > > I have the "hat switch" configured so it allows smooth changes in vies > as if I am moving my head (hen inside the plane) or moving my view point > and view direction in an outside view. > > When in an outside view > 1. If my vasi view line is below the center of the aircraft, all the > lights are white. > 2. If my vasi view line is above the center of the aircraft, all the > light are red. > 3. If my vasi view line passes throught the center of the aircraft. > half the lights are red and half are white. > > Its as if the light color is determined by where the aircraft is > relative to my line of sight to the vasi lights instead being determined > by where the aircraft is relative to the 3 degree line. > > From the normal inside view, all the lights stay red as the center of > the aircraft is still below my eyes (i.e. plane location is below the > line of sight to the vasi lights). > > If I knew where to look in the code, I would look to see if the wrong > decision reference is being used (plane location wrt line of sight > instead of plane location wrt 3 degree line). > > Hope this helps, > dave > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable VASI light observations
Dave Perry writes: > When in an outside view > 1. If my vasi view line is below the center of the aircraft, all the > lights are white. > 2. If my vasi view line is above the center of the aircraft, all the > light are red. > 3. If my vasi view line passes throught the center of the aircraft. > half the lights are red and half are white. > > Its as if the light color is determined by where the aircraft is > relative to my line of sight to the vasi lights instead being determined > by where the aircraft is relative to the 3 degree line. > > From the normal inside view, all the lights stay red as the center of > the aircraft is still below my eyes (i.e. plane location is below the > line of sight to the vasi lights). > > If I knew where to look in the code, I would look to see if the wrong > decision reference is being used (plane location wrt line of sight > instead of plane location wrt 3 degree line). I did some work this evening in simgear/flightgear to track some additional vasi positional information so that I can then compute the angle and correct color. This is a first stab and the result is a gross simplification of what really happens. There are some things I still need to research adn think about, and an item or two I know isn't quite right. But the vasi/papi lights are now colored by your approach angle and not your view angle which is a big improvement. I'll need to spend some more time on this to get the remaining issues ironed out, so please don't panic if they don't look quite right yet. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable VASI light observations
Curtis L. Olson writes: > I did some work this evening in simgear/flightgear to track some > additional vasi positional information so that I can then compute the > angle and correct color. This is a first stab and the result is a > gross simplification of what really happens. There are some things I > still need to research adn think about, and an item or two I know > isn't quite right. But the vasi/papi lights are now colored by your > approach angle and not your view angle which is a big improvement. > > I'll need to spend some more time on this to get the remaining issues > ironed out, so please don't panic if they don't look quite right yet. Ok, I'm still up ... I was on a roll so I kept going. I just checked in one more round of changes that will properly color the upwind/downwind bars of the VASI and the 4 individual lights of the PAPI. This should be a significant improvement over what we had previously. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Josh Babcock writes: > > Actually, I think that I nuked the base makefile by unzipping the patch > in that directory. That brings me back to the original problem, which > is that I can't log into the CVS repository. I guess I'll just keep > trying. I tried applying the patches to the regular plib distribution > and they compiled alright, but after rebuilding flightgear i didn't see > any changes. Plib is hosted at source forge and apparently they are still struggling with spotty access to the cvs repository. I think that if you keep trying you will eventually get through. Otherwise, I think they also make a snapshot of the latest source available for ftp/http download. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope on KSFO 28R ?
Victoria Welch writes: > I've been burried here lately and haven't had a chance to try > someplace else yet, but is there no glideslope on the ils there or > do I have a problem? The glide slope indicator never uncages - > just stays centered (c172, C310). The glide slope should be working. Are you sure you have the proper ILS approach frequency dialed in (i.e. 111.70 for KSFO, 28R), or did you leave the VOR frequency active (115.70)? > But the VASI works now :-) :-) :-) so all is not lost except in low > vis approaches :). Isn't that why you always bring along a duck and a cat? The cat always lands on his feet so you can always figure out which way is up. I forget what you use the duck for. That reminds me, I still want to try tying two cats together back to back and dropping them to see what happens. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-610x
Gerhard, Try this: fgfs --aircraft=c172-610x-jsbsim Intentionally, the c172-610x doesn't have an internal fdm definition so it only works if the fdm information is coming from some external source. To say it another way, the c172-610x *allows* you to specify an external fdm source which is very important for one project I'm involved in. However, I can see the confustion this arrangement might cause, so I have shuffled the naming around just a bit. So now you can run: fgfs --aircraft=c172-610x fgfs --aircraft=c172-610x-jsbsim And the original c172-610x is renamed to: fgfs --aircraft=c172-610x-null In this last one, I've explicitely requested the null fdm so it won't die on startup. It will come up and do nothing until you start feeding it data externally. Regards, Curt. Gerhard Wesp writes: > Hi, > > I just wanted to try out the c172-610x with the HighRes-Panel, but > somehow it doesn't work for me: The FG window appears, some messages > (pasted below) also, and then all of a sudden without apparent cause FG > stops (at ``JSBSim startup beginning''): > > FlightGear: Version MSVC7-WIN32-0.9.3 > Built with Microsoft Visual C++ version 1300 > > Scanning command line for: --fg-root= > fg_root = c:/Program Files/FlightGear-0.9.3/data/ > Reading global preferences > Finished Reading global preferences > Unable to detect the language > Selecting language: C > Reading localized strings from c:/Program > Files/FlightGear-0.9.3/data//Translations/strings-default.xml > Scanning command line for: --aircraft= > aircraft = c172-610x > Reading default aircraft: c172-610x from c:/Program > Files/FlightGear-0.9.3/data//Aircraft/c172/c172-610x-set.xml > Processing config file: c:/Program Files/FlightGear-0.9.3/data//system.fgfsrc > initializing cloud layers > texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/overcast.rgb > texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/broken.rgba > texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/scattered.rgba > texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/few.rgba > texture = c:/Program Files/FlightGear-0.9.3/data//Textures/Sky/cirrus.rgba > Cannot open file: c:/Program Files/FlightGear-0.9.3/data//Scenery/Objects.txt > Skipping bad material entry params > Tile not found (Ok if initializing) > > > [1m[4mJSBSim Flight Dynamics Model v0.9.4[24m[22m > FlightGear aborting > > > [2m[cfg file spec v1.60] > > [22mJSBSim startup beginning ... > > > The contents of my system.fgfsrc is: > > --fg-root=C:/Program Files/FlightGear-0.9.3/data > --fg-scenery=C:/Program Files/FlightGear-0.9.3/data/Scenery > --control=mouse > --browser-app=webrun.bat > --disable-splash-screen > --disable-intro-music > --enable-random-objects > --disable-sound > --disable-hud-3d > --enable-enhanced-lighting > --enable-distance-attenuation > --bpp=32 > --time-match-local > --log-level=warn > > This is the 0.9.3 binary installed on Windows XP. > > > Thanks for any help! > > -Gerhard > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-610x
Gerhard Wesp writes: > > fgfs --aircraft=c172-610x-jsbsim > > Already tried this on the Windows version, didn't work too. Strange, it works for me here. > I've now just installed the Linux Debian packages (0.9.3) by Ove > Kaaven. On this platform, I get: > > debian ~% fgfs --aircraft=c172-610x-jsbsim > FlightGear: Version unknown version > Built with GNU C++ version 3.3 > > Scanning command line for: --fg-root= > fg_root = /usr/share/games/FlightGear > Reading global preferences > Finished Reading global preferences > Unable to detect the language > Selecting language: C > Reading localized strings from > /usr/share/games/FlightGear/Translations/strings-default.xml > Scanning command line for: --aircraft= > aircraft = c172-610x-jsbsim > Reading default aircraft: c172-610x-jsbsim from > /usr/share/games/FlightGear/Aircraft/c172/c172-610x-jsbsim-set.xml > Error reading default aircraft: Failed to open file > at /usr/share/games/FlightGear/Aircraft/c172/c172r-jsbsim-base.xml Strange, I'm not sure what to say, other than it is working for me here under Debian gnu linux. > Note that c172-610x-jsbsim doesn't exist in --show_aircraft! It is showing up for me here. Maybe somehow it didn't get included in the official release ?? Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-610x
Gerhard Wesp writes: > > And the original c172-610x is renamed to: > > > > fgfs --aircraft=c172-610x-null > > > > Which gave me the idea of trying > > fgfs --aircraft=c172-610x --fdm=null > > and this works! Looks great! But it's upside down!! How can I change > this? There should be a property in the -set.xml file that controls if the panel is flipped or not. > Also, would it be possible to give a FDM explicitly on the command line for > --aircraft=c172-610x? It used to be, but at some point we moved towards defining all this in the .xml files and I don't think we can override the fdm choice from the command line anymore. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
You should also check *very* carefully to make sure you don't have a stray packaged copy of plib installed on your system somewhere. If that was built with a different version of the compiler (very plausible) then you would see errors similar to what you are reporting. Regards, Curt. Josh Babcock writes: > Hmm, I compiled and installed plib, then did a make clean, make and make > install on simgear, then a make clean on FlightGear, and the make for > Flightgerar still gives the same kind of error: > > > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > -I/usr/X11R6/include -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 > -D_REENTRANT -c -o viewmgr.o `test -f viewmgr.cxx || echo './'`viewmgr.cxx > rm -f libMain.a > ar cru libMain.a main.o fg_commands.o fg_init.o fg_io.o fg_props.o > globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o > ranlib libMain.a > source='bootstrap.cxx' object='bootstrap.o' libtool=no \ > depfile='.deps/bootstrap.Po' tmpdepfile='.deps/bootstrap.TPo' \ > depmode=gcc3 /bin/sh ../../depcomp \ > g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src > -I/usr/X11R6/include -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 > -D_REENTRANT -c -o bootstrap.o `test -f bootstrap.cxx || echo > './'`bootstrap.cxx > g++ -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O2 -D_REENTRANT > -L/usr/X11R6/lib -o fgfs bootstrap.o ../../src/Main/libMain.a > ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a > ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a > ../../src/Cockpit/built_in/libBuilt_in.a > ../../src/Controls/libControls.a ../../src/FDM/libFlight.a > ../../src/FDM/Balloon/libBalloon.a > ../../src/FDM/ExternalNet/libExternalNet.a > ../../src/FDM/ExternalPipe/libExternalPipe.a > ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a > ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a > ../../src/FDM/LaRCsim/libLaRCsim.a > ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a > ../../src/Input/libInput.a > ../../src/Instrumentation/libInstrumentation.a > ../../src/Model/libModel.a ../../src/Network/libNetwork.a > ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a > ../../src/Sound/libSound.a ../../src/Airports/libAirports.a > ../../src/MultiPlayer/libMultiPlayer.a ../../src/Objects/libObjects.a > ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a > ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a > -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb > -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops > -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgsound -lsgserial -lsgstructure > -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg > -lplibsg -lplibul -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi > -lXext -lX11 -ldl -lm -lplibsl -lplibsm > ../../src/Main/libMain.a(main.o)(.text+0x804): In function > `trRenderFrame()': > ../../src/Scenery/scenery.hxx:369: undefined reference to > `ssgCullAndDraw(ssgRoot*)' > ../../src/Main/libMain.a(main.o)(.text+0x844):../../src/Scenery/scenery.hxx:369: > undefined reference to `ssgCullAndDraw(ssgRoot*)' > ../../src/Main/libMain.a(main.o)(.text+0x858):../../src/Scenery/scenery.hxx:369: > undefined reference to `ssgCullAndDraw(ssgRoot*)' > ../../src/Main/libMain.a(main.o)(.text+0x1377): In function > `fgRenderFrame()': > ../../src/Scenery/scenery.hxx:369: undefined reference to > `ssgCullAndDraw(ssgRoot*)' > ../../src/Main/libMain.a(main.o)(.text+0x13b0):../../src/Scenery/scenery.hxx:369: > undefined reference to `ssgCullAndDraw(ssgRoot*)' > ../../src/Main/libMain.a(main.o)(.text+0x13ce):../../src/Scenery/scenery.hxx:369: > more undefined references to `ssgCullAndDraw(ssgRoot*)' follow > collect2: ld returned 1 exit status > make[2]: *** [fgfs] Error 1 > make[2]: Leaving directory `/usr/local/src/FlightGear-0.9.3/src/Main' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/src/FlightGear-0.9.3/src' > make: *** [all-recursive] Error 1 > > > After re-installing the regular 1.6.0 distribution of plib and cleaning, > making and installing plib, SimGear and FlightGear, everything is back > the way it was before. Something is definitely broken with the patch, it > is the only thing that I changed between the two builds. Is it possible > that I picked up a bug in FlightGear from CVS recently and the plib > patch is activating it? > > Josh > > Andy Ross wrote: > > >Josh Babcock wrote: > > > > > >>OK, the snapshot file solves that problem, but I think that main.o > > >>is failing to link. See here: > >> > >> > > > >You swapped plib versions, but still have some SimGear and/or > >FlightGear files compiled against the old one. In general, C++ > >libraries aren't binary compatible across versions. You need to do a > >complete rebuild. > > > >Andy > > > > > >___ > >Flightgear
Re: [Flightgear-devel] DC-3 3d cockpit
Jim Wilson writes: > Andy Ross <[EMAIL PROTECTED]> said: > > > Jim Wilson wrote: > > > Note, I'm suggesting adding Andy's work to plib as an alternative > > > optimizer function, not a replacement for the current code. > > > > No need for this. They produce identical results if you set the sharp > > angle to 180 degrees. > > Theoretically yes, but are you sure of that? > > > All someone needs to do is export the value via > > the loader API. > > > > I give up on the plib folks. All reports are that the current version > > of this patch produces better looking models in all cases. Are there > > any real-world cases where we want something different? > > Got me. I'm not involved directly with that project. I guess I'm taking the > conservative approach. We certainly aren't the only users. > > If the patch was finished, with the support for the old method (or an exact > match as you mentioned above) then I can't imagine that the plib folks would > not accept the patch. Steve seemed to support the idea of alternate > optimizers and like you said all reports are good. When it is ready I'm sure > all the Flight Gear folks including yours truly will lobby for it and it will > get in. I'd love to see this get into plib too. Maybe it's time to ask about it on the plib list and try and pin them down on exactly what their objections are if any, and if there aren't any maybe a reminder or two would be all it takes to get someone to apply the changes. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dead links on the FG website
Frederic BOUVIER writes: > Hi Curt, > > the 'Contributors' link give 404. The link 'thanks.html' should be > 'thanks.shtml'. Thanks for catching this ... Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot, maintaining elevation
Seamus Thomas Carroll writes: > I am playing with the autopilot and maintaining an altitidue above sea > level works great. Is there a method for maintaining an elevation above > the ground? Ctrl-t will toggle a mode that attempts to maintain the current altitude above ground. The algorithm is very simplistic though and doesn't take any sort of look ahead into consideration. It only looks at the current elevation above ground and tries to climb or decend to achieve the goal elevation. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: data/Scenery/w130n30/w123n37 light-pat-1.rgb, NONE, 1.1 baybridge-e-fb.ac, 1.1, 1.2 baybridge-fb.ac, 1.6, 1.7 baybridge-fb.xml, 1.4, 1.5 ggb-fb.xml, 1.3, 1.4
Frederic BOUVIER wrote: Thanks, glad to see you like it and it doesn't kill all the framerate. For people that are not following CVS updates, check out : http://perso.wanadoo.fr/frbouvi/flightsim/sanfran.htm The lights are brighter in FG than on jpeg but you will have an idea. That remind me that I don't have pictures of the GoldenGate nor the East span of Bay Bridge at night. If someone have some, I am interested. I'm waiting for the reflections of the bridge lights in the water. I saw this in a commercial A320 sim once and it was a really neat effect. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] illuminated baybridge
David Megginson wrote: Actually, if you're approaching a runway from about 90 degrees, it's the taxiway lights that you can see -- the runway lights are invisible until you're right overhead. Yes, it's a subtle effect and you may not notice it unless you are looking for it specifically, but all runway lighting in FlightGear is directional. In other words the lights are brightest when viewed along the direction they are pointing and dim out as you move perpendicular to them, and disappear when they are pointing the opposite direction. This shows up most clearly in that you don't see the approach lighting of the opposite ends of the runways. And the perpendicular runways are *much* dimmer than the ones you are aligned with. Several of us put in quite a bit of effort to work out the graphical tricks to make that happen. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Oh dear....
We probably should steer away from the political discussion stuff (on this forum) before we forget we are working on an open source simulator. :-) Curt. Christian Mayer wrote: David Megginson schrieb: JD Fenech wrote: This is pretty sad. It's times like this when I start to consider relocating to Canadia to find a job and live there, much as I bash on it (jokingly, of course; it really wouldn't do to be bashing our 51st state). Here's a local (New England) version of the same story, with details: http://www.recorder.com/Headlines/tuesday_basic.htm Note that the Staples clerk actually told the servicewoman and her son that instructional flying software was illegal, before he reported them to the police. And guns are still legal... I'm glad that I live in "old Europe"... CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalization?
Lee Elliott wrote: Heh - it seem to me that most of the kids here (UK) just speak pretty bad english;) That depends on how you look at it. You could say that english is whatever english speaking people are speaking these days. Or you could flip that around and come up with some defined structure of english as it existed at some point in time (and then compare that with what people are speaking today.) Of course you could argue all day long about current usage being unclear or imprecise since (err I mean because) "proper" english is usually much more clear and precise. I'd suggest that we shoot any one who says "A whole 'nother ..." instead of "Another whole ..." but I catch myself saying it too. There are a lot of people who speak english as a 2nd or 3rd or 4th language who at least right better english in their emails than I could ever hope to. :-) Having studied spanish every year of my life since probably kindergarten up through my junior year of high school, and now not having any hope of being able to follow (or participate in) a real time spanish conversation, I have a lot of respect for those that pop back and forth between multiple languages. And I appreciate all of you who switch to english now and then so that I can understand what you are saying. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Duplicate node?
John Wojnaroski wrote: Walking thru some code yesterday, I noticed the following: In tilemgr.cxx at lines 319 and 321 there are two entries for adding taxi lights. Is that what is intended? Yeah you are right, there is a problem there. I have checked in a fix to CVS. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] CVS building fails, do I have a problem here?
Vikki,
I don't see -lglut listed on the link command line. You probably want to
rerun the configure script and make sure that the glut test there succeeds.
If not, then look in your config.log to see exactly what failed.
Regards,
Curt.
Victoria Welch wrote:
Hi Folks,
A couple days or so back I updated CVS and have not been able to
rebuild FG since. Not sure if I have a problem (most likely I
think) or if there is a problem with CVS:
==
Configure Summary
=
Prefix: /usr/local
Debug messages: yes
Automake version: automake (GNU automake) 1.5
Using FGEnvironment
Building with multiplayer support
threads: yes
Making all in tests
make[1]: Entering directory `/home/vw/fgfs/FlightGear/tests'
gcc -march=athlon-xp -O2 -g -fomit-frame-pointer -mfpmath=sse -pipe
-D_REENTRANT -g -L/usr/local/lib -L/usr/X11R6/lib -o gl-info
gl-info.o -lMesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11
-ldl -lm -ljpeg
gl-info.o(.text+0x147): In function `main':
/home/vw/fgfs/FlightGear/tests/gl-info.c:59: undefined reference to
`glutInit'
gl-info.o(.text+0x153):/home/vw/fgfs/FlightGear/tests/gl-info.c:60:
undefined reference to `glutInitDisplayMode'
gl-info.o(.text+0x15f):/home/vw/fgfs/FlightGear/tests/gl-info.c:61:
undefined reference to `glutCreateWindow'
collect2: ld returned 1 exit status
make[1]: *** [gl-info] Error 1
make[1]: Leaving directory `/home/vw/fgfs/FlightGear/tests'
make: *** [all-recursive] Error 1
=
I do have glut:
=
{~/.fgfs} $ emerge -s glut
Searching...
[ Results for search key : glut ]
[ Applications found : 1 ]
* media-libs/glut
Latest version available: 3.7.1
Latest version installed: 3.7.1
Size of downloaded files: 2,479 kB
Homepage:
http://www.opengl.org/developers/documentation/glut/
Description: The OpenGL Utility Toolkit (GLUT)
=
So I am confused :-) - would much appreciate any comments on this
issue!
Thanks & take care, Vikki.
--
Curtis Olson Intelligent Vehicles Lab 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 mouse pad
Hof Markus wrote: nice layout... is this a faked frame rate? ;-) if not pretty good. how come? Probably because Eric runs on sgi hardware. :-) Curt. -- Curtis Olson Intelligent Vehicles Lab 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] CVS building fails, do I have a problem here?
From what you've sent I'm not seeing anything obvious, but perhaps you
could send me a) the console output of running the configure script and b)
your entire config.log file. (Send these directly to me, not to the list.)
What OS are you running?
Curt.
Victoria Welch wrote:
Hi Curt,
Thanks for the response. I went through config log (~=2500 lines :)
and am no more enlightended - see below :-(.
On Sunday 11 January 2004 14:14, Curtis L. Olson wrote:
Vikki,
I don't see -lglut listed on the link command line. You probably
want to rerun the configure script and make sure that the glut
test there succeeds. If not, then look in your config.log to see
exactly what failed.
grep -inA 2 failed config.log | less
117:configure: failed program was:
118-| #ifndef __cplusplus
119-| choke me
--
131:configure: failed program was:
132-| #line 2718 "configure"
133-| /* confdefs.h. */
[ 24 more iterations of the last second one ]
configure: exit 0
I am not at all sure what I am looking for, but if it is saying I
don't have c++, well true, but I do have:
{~/fgfs/FlightGear} $ g++
g++: no input files
apparent problems with glut?!?:
--
1233:configure:7842: checking for library containing
glutGetModifiers
1234-configure:7873: gcc -o conftest -march=athlon-xp -O2 -g
-fomit-frame-pointer -mfpmath=sse -pipe -D_REE
NTRANT -I/usr/local/include -I/usr/X11R6/include -g -L/usr/local/lib
-L/usr/X11R6/lib conftest.c -lMesaGLU
-lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm >&5
1235-/tmp/cc2M1u2j.o(.text+0xa): In function `main':
1236:/home/vw/fgfs/FlightGear/configure:7892: undefined reference to
`glutGetModifiers'
1237-collect2: ld returned 1 exit status
1238-configure:7876: $? = 1
--
--
1288:configure:7918: gcc -o conftest -march=athlon-xp -O2 -g
-fomit-frame-pointer -mfpmath=sse -pipe -D_REE
NTRANT -I/usr/local/include -I/usr/X11R6/include -g -L/usr/local/lib
-L/usr/X11R6/lib conftest.c -lglut -l
MesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm >&5
1289:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXBindChannelTo
WindowSGIX'
1290:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXQueryChannelD
eltasSGIX'
1291:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXChannelRectSy
ncSGIX'
1292:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXChannelRectSG
IX'
1293:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXQueryChannelR
ectSGIX'
1294-collect2: ld returned 1 exit status
1295-configure:7921: $? = 1
Sorry to include so much stuff here, but I am lost :-(.
Is it possible that I have the wrong version of glut? If so, I
would think that configure would blow out ?!?!
Thanks & take care, Vikki.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Victoria Welch wrote:
Hi Folks,
A couple days or so back I updated CVS and have not been able
to rebuild FG since. Not sure if I have a problem (most likely
I think) or if there is a problem with CVS:
==
Configure Summary
=
Prefix: /usr/local
Debug messages: yes
Automake version: automake (GNU automake) 1.5
Using FGEnvironment
Building with multiplayer support
threads: yes
Making all in tests
make[1]: Entering directory `/home/vw/fgfs/FlightGear/tests'
gcc -march=athlon-xp -O2 -g -fomit-frame-pointer -mfpmath=sse
-pipe -D_REENTRANT -g -L/usr/local/lib -L/usr/X11R6/lib -o
gl-info gl-info.o -lMesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi
-lXext -lX11 -ldl -lm -ljpeg
gl-info.o(.text+0x147): In function `main':
/home/vw/fgfs/FlightGear/tests/gl-info.c:59: undefined
reference to `glutInit'
gl-info.o(.text+0x153):/home/vw/fgfs/FlightGear/tests/gl-info.c
:60: undefined reference to `glutInitDisplayMode'
gl-info.o(.text+0x15f):/home/vw/fgfs/FlightGear/tests/gl-info.c
:61: undefined reference to `glutCreateWindow'
collect2: ld returned 1 exit status
make[1]: *** [gl-info] Error 1
make[1]: Leaving directory `/home/vw/fgfs/FlightGear/tests'
make: *** [all-recursive] Error 1
=
I do have glut:
=
{~/.fgfs} $ emerge -s glut
Searching...
[ Results for search key : glut ]
[ Applications found : 1 ]
* media-libs/glut
Latest version available: 3.7.1
Latest version installed: 3.7.1
Size of downloaded files: 2,479 kB
Homepage:
http://www.opengl.org/developers/documentation/glut/
Description: The OpenGL Utility Toolkit (GLUT)
=
So I am confused :-) - would much appreciate any comments on
this issue!
Thanks & take care, Vikki.
--
Curtis Olson I
Re: [Flightgear-devel] Panel Building ?!?
Victoria Welch wrote: I'm thinking I want to get into building panels for FG aircraft. Either I am missing it or the tools for the job are vi, gimp, an XML reference and all the FG header files ?!? Any comments or suggestions appreciated! I'll chime in with a couple comments. First off, yes this definitely looks intimidating at first glance, but give it a chance. Once you jump in and start working with the files, it's not nearly as bad as it might have first appeared. After you stare at xml for a bit, it does start to make sense and becomes much more human readable. I believe you can type "Shift-F3" to reload panel changes on the fly, so you can immediate test your change without needing to restart FlightGear or do any kind of compiling. That is *extremely* convenient when you are tweaking the instruments. There are numerous examples of panels, so in many case you could start by piecing together existing stuff. That get's you up and running quickly and then you can make aircraft specific changes at your liesure. So far, what I've said has mostly applied to 2d panels. If you are interested in building 3d panels, then you'll probably want tips and advice from the 3d panel experts (which isn't me.) :-) Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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
[Flightgear-devel] Re: yf23 brakes
Andy Ross wrote: So which wheels get controlled by the parking brake on the bo105, harrier, or 747? :) This same subject just came up a few days ago. The real bug is that we're trying to associate brake controls with individual wheels, which is just wrong. The only standard for brakes in aircraft is that there is a left pedal, right pedal, and parking brake lever. Everything else is aircraft-specific and IMHO belongs in the FDM, not the control system. Ok! I have standardized the control inputs with /controls/gear/brake-left, /controls/gear/brake-right, /controls/gear/brake-parking I have updated the code, the aircraft definition files, and the keyboard / mice / joystick bindings. On the yasim side, the correct approach when defining a gear/wheel is to specify which combination of brake control affects it (left, right, parking) I suppose at some point when we want to impliment anti-skid brakes or other complicated stuff we'll have to come back and rework this a bit. There is an open issue with JSBSim because it has the concept of a "center brake" which doesn't directly map to the standard cockpit controls. Right now I hardwire that to a value of zero. I've probably missed something becuase this change propogated through a *ton* of files (and the compiler can't catch property name mismatches), so hopefully people can try their various aircraft and make sure all the braking related stuff continues to work correctly. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: Linux User & Developer Expo 2004]
FlightGear has been offered free .org booth space and a possible speaker slot at the Linux User & Developer Expo 2004. This is Oct 20-21 at the Olympia Exhibition Centre in London, UK. You don't necessarily need to be a developer to help with the booth, but a moderate working knowledge of FlightGear (and for this show, Linux) is always helpful. Are there any UK people who might be interested in staffing a booth, bringing a pc, etc.? Anyone looking for an excuse to visit London next October? Based on past experience we should try to get this organized early so we can get a booth. If you register late, you either don't get a booth at all, or the booth you do get is in the mens room next to all the other late register-ers. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org --- Begin Message --- Thanks to generous sponsorship space is available, FREE of charge for The Flightgear in the .Org Village for Linux projects, groups & campaigns. There is also the possibility of having a speaker slot in the conference programme The Linux User & Developer Expo 2004 will take place over two days, 20th and 21st October at the Olympia Exhibition Centre in London, UK. This year the .Org Village will be the largest ever and split into three distinct areas: Campaigns, User Groups & Projects/Distributions. Space is limited so please contact me (Brian Teeman) as soon as possible. Your project/group/campaign will be provided with exhibition space including electrics, storage etc. This is a great opportunity to promote your project to a large audience at minimal (no) cost, and also to help make the .Org Village a lively discussion and meeting place for the Linux community. Now in its second year, Linux User & Developer Expo 2004 is the UKs largest exhibition and conference dedicated to this open source revolution. It brings together all the major players in the Linux computing sphere to provide the definitive review of all the latest products and services emerging around this rapidly developing technology. For further details or to book your free space please contact me at [EMAIL PROTECTED] or by phone on 0870 740 6575. For further details on the exhibition see www.linuxuserexpo.com If you are not the correct person who would deal with this in your organisation please forward this e-mail to them and to anyone else who you think might be interested. Brian Teeman uklinux.net - Sponsors of the .org Village. --- End Message --- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: Linux User & Developer Expo 2004]
Martin Spott wrote: "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: FlightGear has been offered free .org booth space and a possible speaker slot at the Linux User & Developer Expo 2004. This is Oct 20-21 at the Olympia Exhibition Centre in London, UK. You don't necessarily need to be a developer to help with the booth, but a moderate working knowledge of FlightGear (and for this show, Linux) is always helpful. Are there any UK people who might be interested in staffing a booth, bringing a pc, etc.? Anyone looking for an excuse to visit London next October? This should be a great opportunity for a European FG developer's meeting (or sort of that), We need to know as soon as possible if any one (in addition to Jon) can commit to being at this conference and can commit to helping with the booth so we can apply for and (hopefully) get booth space before it is all gone. I think if we could get another one or two people to say they are pretty certain they can be there, then we could go ahead and lock in some booth space. Thanks, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: Linux User & Developer Expo 2004]
David Luff wrote: OK, that's a definate now :-) Ok, so far here is what I have: - Al West can definitely be there. - David Luff can definitely be there. - Jon Stockhill probably will be at the show and probably can help with the booth. - Matthew Law thinks he can be there but needs to clear it with his boss first. - Jim Brennan might also be able to make it. If your name is on this list and it shouldn't be, or I have the level of "definiteness" wrong, please let me know. But I think with 2 definites, 1 probably, and a "need to get permission first", plus another maybe, we probably have enough to go ahead and reserve a booth. Sound reasonable? Any additional volunteers are also welcome. The more the merrier and the core staff always appreciates a bathroom break, or a chance to go look around the show themselves. If it gets too crowded in the booth, you can just stand outside and pretend to look interested and ask questions. Then everyone else will come over to see what's so interesting about our booth that it has a continual crowd. Also note that this is a 2-day event so it's not quite as big a commitment as LWCE which can push four days. Thanks! Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Switching
Innis Cunningham wrote: I guess this question is for David Megginson or Erik Hofman. I would like to have the ability to turn instruments on and off in the 2D panel XML file is this already possible.If so how?. If not would it be a big job to add it to the panel XML code. Thanks for any idea's. You ought to be able to do this by wrapping the instrument up inside a big conditional. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Re: Problems compiling plib
Christopher S Horler wrote: I don't use many cvs commands, but one I use a fair bit is log. However I've never figured out how to make it only display the last e.g. 5 log entries or from a certain date... if it doesn't do it it should... I don't know if there is a command to display the last 5 log entries, although you could probably do this for an individual file pretty easily via the cvs web interface. In general, I have had good luck with something like the following: cvs log -d">10/15/2003 (that's MM/DD/) Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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
[Flightgear-devel] IRC
For any of you interested in doing IRC, Nic Fischer has given us a channel on his IRC server. Just connect up to irc.flightgear.org and join the #flightgear channel. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] IRC
Arnt Karlsen wrote: On Mon, 19 Jan 2004 15:21:24 -0600, "Curtis L. Olson" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: For any of you interested in doing IRC, Nic Fischer has given us a channel on his IRC server. Just connect up to irc.flightgear.org and join the #flightgear channel. ..hey! Shouldn't we be coding instead? Or is this the wee beginnings of FG ATC, with voice, radarscreens and all? ;-) Sure IRC as an ATC start curt> This is Cessna 42 Papa turn final flyboy> lol turky381> :-P *** erik has signed off jimbo> hey erik, is that you that just went into the tree, rotflmao flyboy> lol turky381> :-P curt> I see some smoke off the end of runway 42 flyboy> lol turky381> :-P *** erik has joined #flightgear flyboy> lol, you all in one piece? turkey381> :-P erik> just testing some f16 fdm changes turky381> :-P turky381> hey flyboy, beat you this time. flyboy> lol turky381> :-P . . . . -- Curtis Olson Intelligent Vehicles Lab 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] [Fwd: Linux User & Developer Expo 2004]
David Culp wrote: On Wednesday 14 January 2004 08:29 am, Curtis L. Olson wrote: FlightGear has been offered free .org booth space and a possible speaker slot at the Linux User & Developer Expo 2004. This is Oct 20-21 at the Olympia Exhibition Centre in London, UK. You don't necessarily need to be a developer to help with the booth, but a moderate working knowledge of FlightGear (and for this show, Linux) is always helpful. Are there any UK people who might be interested in staffing a booth, bringing a pc, etc.? Anyone looking for an excuse to visit London next October? I've tried to find more information on this event on the web, but have had no luck. There *is* an April 20-21 show. Not the same one? Yes, this is the show. We were mistakenly told Oct, but in reality, the show is April 20-21. Hopefully, everyone who was going to voluteer before, can still make it to on the correct date. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed change to Terrain Following control
Lee Elliott wrote: Hello All, I'd like to propose a change to the way that the Terrain Following (TF) agl value is set and controlled. Currently, when TF mode is selected, the current a/c agl value is used but I'd like to change this so that this value is set, and can be changed via the property tree. What are people's thoughts on this? Sounds reasonable. Is the current height above terrain in the property tree someplace? FWIW (and hopefully this doesn't mean major breakage) I've been considering some changes to the autopilot infrastructure to make it more flexible. For instance, we (or at least I) could really use a mode to hold speed with pitch, or hold pitch with elevator. And it would be nice to be able to support some of the more advanced FCS concepts that right now are only accessible to JSBSim models (things like yaw dampers, and other fly-by-wire type stuff.) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Changing a model format
Tim Jelliffe wrote: Hi guys, I have a general question regarding the creation of a model. I have been working on creating a model of a Learjet 55, using CATIA V5. This is mainly because I used this during my degree and am basically familiar with it. I am also determined to have a model which is as close to the real thing as possible. This means if the fuselage is 2m in diameter, I want the model to have a 2m diameter fuselage as well! CATIA is awesome for this. A screenshot is at http://members.optusnet.com.au/~tjelliffe/Learjet55.jpg Looks very nice. :-) The problem is that CATIA works with surfaces, as you can see in the pic, but things like blender and ac3d seem to use nodes. This makes it hard to convert into .ac format. I can save the file as either wrl, stp, igs, or cgr file formats. I have tried saving it as a wrl format, and using this directly in flightgear. The file size is around 2 Mb, and the frame rate drops from ~20 to ~2 fps. I have also tried using the demo version of AC3D, and saving directly into .ac format. This still gives very big files though. One of the tough things about "real time" 3d modeling is figuring out how to do a nice looking model and at the same time keeping your polygon count low enough for real time rendering. I'm guessing that some of your complex surfaces have zillions of little pieces in order to get the accuracy you are looking for. One way to deal with this is called "LOD" or level of detail. You can specify differently detailed models for viewing from different distances. You don't need 10k polygons when the aircraft is 10 miles away. But when you are 10 meters away, you may want all that detail. There are a lot of trade offs you probably have to accept when you start doing real time 3d modeling. Often you can compensate for lower polygon counts with fancy textures. I'm not a very good 3d modeler though so I'm sure there are others here who can give you much better advice than I can. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Proposed change to Terrain Following control
Roy Vegard Ovesen wrote: Let me share my thoughts about the autopilot: * I would like to see the autopilot move from c++ code into the instrument configuration xml-files. This is my general plan. Right now I have the autopilot config in a separate .xml file * The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was "broken". Failures in the underlying instruments and systems would affect the autopilot. Yup, each autopilot component will be able to take input from any property, and output to any other property. As long as we have the instrument values modeled and placed in the property tree, we can use them. The trick will be for someone who knows a little about autopilots to be able to tell us what inputs drive what functions. * A PID-controller that can be accessed from the instrument configuration files. This could be used to build the autopilot controller structure as an instrument. This means that one could build different autopilot instruments for different aircraft. The Cub for example might have a simple autopilot with only heading hold and altitude hold. And because the Cub does not have an attitude indicator instrument, a wing-leveler would not be available. And in addition the heading hold would not be allowed to use roll information. I've been hacking things out here a bit this evening and here's what I've come up with for a simple proportional wing leveler. All of this is in a state of flux, is subject to change, and only exists on my local HD. I'll intersperse some explanatory comments ... autopilot.xml: Wing Leveler (Turn Coordinator based) /autopilot/locks/heading wing-leveler /instrumentation/turn-indicator/indicated-turn-rate 0.0 /controls/flight/aileron 0.5 0.0 -1.0 1.0 So if you set /autopilot/locks/heading = wing-leveler, this component will become active and start driving the turn rate to zero using the ailerons. Here's a more complicated two stage heading bug follower (still using simple proportional control): Heading Bug Hold (DG based) Calc Target Roll /autopilot/locks/heading dg-heading-hold /instrumentation/heading-indicator/indicated-heading-deg /autopilot/settings/heading-bug-deg /autopilot/internal/target-roll-deg true 1.5 0.0 -30.0 30.0 Heading Bug Hold (DG based) (Calc target ailerons) /autopilot/locks/heading dg-heading-hold /orientation/roll-deg /autopilot/internal/target-roll-deg /controls/flight/aileron 0.05 0.0 -1.0 1.0 So that's what I've come up with so far. Am I completely nuts? Any suggestions? I have no formal education in control theory, so what I know has been gleaned from here and there so I probably don't know much of the correct terminology and there are certainly tricks and things that I'm not aware of. I'm hoping to do a good job of roughing in the flexible xml structure and interfacing to flightgear, then get some help on the control theory side from the experts. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Proposed change to Terrain Following control
Roy Vegard Ovesen wrote: And I firmly believe that we _should_ use the instrument values because in my mind using /position/... and /velocities/... would be "cheating", theese perfect values are _not_ available in the real world. I definitely agree. We should have instrument values well modeled for the sorts of intruments typically found in smaller aircraft. I have a masters-degree in control theory, Ok, then I will depend on you to keep me from doing anything too stupid. :-) I implemented (in jsbsim) a wing leveler or I should say a roll-angle holder that was roll-angle based. It's all a matter of preference, I think (turn coordinator based or roll-angle based or ...) I believe that some real life wing levelers are based on the turn coordinator gyro which is why I did it that way. I guess it boils down to how it's done in real life on which ever particular real aircraft we are modeling. In PID controllers an offset is often to set the working-point. The point where: offset = output => target - input = 0. The aileron deflection that results in zero turn rate. This aileron deflection doesn't have to be zero, as we all have experienced :-) Yes ... Another application for the offset is to attatch it to the manual actuator, in our case the stick. This means that the pilot can still control the airplane when the autopilot is engaged ;-) , and when the autopilot is disengaged, the output = offset = stick => pilot is flying. That's an interesting idea ... and shouldn't be all that difficult to impliment. A proportional only controller will _not_ be able to drive the turn rate to zero. If the working-point were zero aileron deflection, then this controller would work but, as stated earlier, the working point is moving around. In general you need at least proportional and intgral components, in a controller, to avoid this static-error. That is true, although for a typical C172 with it's laggy and inaccurate sensors, a proportional controller might just get you "close enough." It's easy to spot small errors in a sim, but in real life there are usually much bigger errors that hide that last 0.2% that the "I" compensates for. :-) But hopefully in the end, this will all be handled in the autopilot config file which leaves the choice up to the person building the autopilot. This is called cascade control. I assume that it is a reasonable approach if there's an official name for it. :-) In stead of (or in addition to) having , and components, I would like to see a that incorporates all three and in addition features like anti-windup, reduced set point weighing, etc. Here's my suggestion: (I'm not sure about the propert names) Roll Angle Controller /autopilot/roll-angle-hold true /instrumentation/attitude-indicator/roll-angle /autopilot/roll-angle-setpoint /controls/flight/aileron /autopilot/roll-angle-controller/proportional /autopilot/roll-angle-controller/integral /autopilot/roll-angle-controller/derivate -15 20 /autopilot/roll-angle-controller/beta The hack should be moved outside of the controller. Do you have any suggestions for better ways to handle this? For heading control, -370 degrees is a lot different than -10 degrees. At some point in the pipeline, we need to be able to remap results. Either we could build a ton of tiny building blocks (at which point we might be better off just writing the autopilot entirely in nasal) or we need to have a way to tell the controller to remap the results at various stanges in the pipeline. A PID controller is very versitale, it can be a P, PI, PD or a PID controller by setting the proportional, integral and derivate gains, and in many applications a PI controller is good enough. I have a PID controller algorithm from one of my textbooks, I could send it to you with lots of comments. If it's not too much typing for you, it would be worth taking a look at. With a PID controlle we should have the tools to build good autopilots. Then comes the art-of-tuning :-) Yes. I'm worried that I might end up breaking a lot of the existing tuning. I will try not too, but it's something I'm nervous about. I'm half tempted to commit what I have to CVS. But that leaves a lot of autopilot stuff temporarily broken. So, I'm leaning towards hacking on this until I've recovered 99% of the existing functionality before doing a cvs commit. That gives others a bit less of an opportunity to track what i'm doing though. I could send a tar-ball of changes if anyone is really interested. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing
Re: [Flightgear-devel] Proposed change to Terrain Following control
David Culp wrote: This thread is scaring me. I hope we aren't deciding to hard-wire the autoflight inputs from panel instrument output? The input choice will be strictly optional, right? Figures, I just finished screwing the cowl back on ... The whole point of defining the autopilot via xml is so that we can a) set up wildly different configurations for different aircraft (like in real life.) And also so we have the flexibility to connect in just about any type of input. We would not connect directly from the panel instruments, that doesn't make much sense structurally. However, in many cases, the autopilot should be driven by the same values the instruments are reporting (in other words, both the instrument and autopilot could be driven by the same underlying instrumenation model.) Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Proposed change to Terrain Following control
Lee Elliott wrote: I've been giving quite a bit of thought to look-ahead algorithms for terrain following. The most straight forward way would be to take a number of look-ahead samples each frame, and simply take the highest point as the target alt. Taking a lot of samples each frame can't be a good idea though so I've been thinking more about single look-ahead sample alogorithms. These don't seem to be too tricky but they're pretty much limited to straight-line flight. It's possible that using several single-sample tracks might work for turns though. Let's say you were flying 240 meters/sec and generally in a straight line. Let's also assume we are drawing 60 frames/sec. That means we travel about 4 meters every frame. Let's say we want to look ahead 10 seconds. That is 10 * 240m/s = 2400 meters we would have to look ahead. Figuring a flat ground and the aircraft's pitch angle, figure the appropriate angle to point your radar or laser scaner. Now if you do one terrain intersection lookup each frame and do it 2400 meters ahead of you. But, also keep the last 10 sec * 60 fps lookups in a buffer, then assuming you are flying in a straight line, once your buffer fills up, that gives you a set of elevation points in your path at 4 meter increments looking 2400m ahead. If you turn, this blows the whole scheme so just don't turn. :-) Perhaps after sensing a turn, you could wipe the buffer and start filing it in with one extra terrain intersection lookup per frame, and scan in a binary partitioning pattern ... This would minimize computation cost and *might* work ... Curt. -- Curtis Olson Intelligent Vehicles Lab 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] enrty and exit points of main loop
Snyder Adam D Civ AFRL/VACD wrote: Not really, I just need to find a way to clean-up when I am finished. Here's one option. If you put all your code inside a class, then you should be able to put your clean up stuff into the class destructor. That should automatically be called when the program exits. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] XGL
Martin Spott wrote: Erik Hofman <[EMAIL PROTECTED]> wrote: I just read about an XML based 3d file format: http://www.xglspec.org/ We might want to keep an eye on that. I must admit that I didn't understand the advantage over existing 3D object/scene description file formats, I wonder if this is intended to be a better vrml? Although it's not clear that the authors of xgl are aware of vrml ... The thing about 3d file formats is that there's never one that does exactly everything you need. So you might as well start a new format and toss it into the mix. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] XGL
Erik Hofman wrote: Well, here is a standard that *you* can actually try to influence ... BTW. XML makes extending the existent layout without influencing the previous versions possible by nature. All that would need to happen is for someon to write a plib reader/writer for the xgl format and then we can begin using it. The modelers would have to figure out how to output in this format which could be a little trickier. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Possible typo in tilemgr.cxx line 180
David Luff wrote:
tilemgr.cxx contains the following block of code (lines 178 - 181):
xrange = (int)(vis / tile_width) + 1;
yrange = (int)(vis / tile_height) + 1;
if ( xrange < 1 ) { xrange /= 1; }
if ( yrange < 1 ) { yrange = 1; }
It looks to me like there might be a stray / sign in line 180?
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
That definitely looks like a typo. Thanks for catching this.
Curt.
--
Curtis Olson Intelligent Vehicles Lab 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] New autopilot
Innis Cunningham wrote: This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Famous Saying "if it an't broke don't fix it" Functionally the current autopilot is ok, but the underlying algorithm is very basic. Also, if you look through the code, it is a big hairy mess. And this was after a rewrite of the original C version. The problem is that we need to do more with the autopilot than what it's doing right now. For instance I want to be able to hold a specific pitch, or hold a specific speed with pitch. I might also want to hold a target roll rate (like 1 degree/sec) for 20 seconds. It would be possible to paste this onto the current system, but it's already a big mess of code in there and this will make just make the problem worse. I understand that "if it aint broke, don't fix it" but if I have to "mess with a mess," I like to clean it up. :-) That's not to say anything negative about the current autopilot contributors. Just that I think the required functionality had long ago outgrown the infrastructure we had setup and so as people have added things, it's become quite a jumble. Also, we have several people here knowledgable in the field of control theory and people that understand how autopilots are supposed to work. Add that in with someone who (thinks he) understands the internals of FG and I think we have an opportunity to really improve the entire auto pilot infrastructure. That's where I'm coming from anyway ... Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Roy Vegard Ovesen wrote: On Mon, 26 Jan 2004 13:13:44 -, Richard Bytheway <[EMAIL PROTECTED]> wrote: That would be the responsibility of the autopilot designer. If he/she designed a control structure that used two separate controllers that acted on the ailerons, that would be his/her problem. In fact it might turn out to be a good thing. ;-) Does this imply that we also need a "summer" class/unit/module which can take the outputs from various controllers and sum them to feed to the "actuator"? Yes, a "summer" class/unit/module would be a handy tool. A "gain" class/unit/module would also be usefull. This would be for control mixing, right? Elevons, ailerators, thrudders, and, flailerons, and that sort of stuff? This should be a fairly straightforward extension to the current system I am working on. Now I have a question for the expert. I see two issues, and I'm curious about the best way to solve them. Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a "generic" pid algorithm? Would we want to build in hooks to the "generic" pid algorithm so we can set up these sorts of limits? As I understand it, the autothrottle predicts the airspeed 10 seconds ahead of time, and uses that as the input. Would the differential component of the PID algorithm be able to account for this? Would we want some code someplace that puts the predicted speed into the property tree for the generic pid algorithm to use, or would we want to build in some sort of property prediction ability into the pid algorithm (in case the 'd' component doesn't quite do what we want?) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Can we ban outlook users from the list?
Jim Wilson wrote: Just a thought :-) I got lectured once in a job interview (that obviously did not go well for me.) The interviewer didn't like my answer on the future of computer security. He asserted that in 6 months (this was > 10 years ago) that all security problems would be solved because business simply can't tolerate this sort of nonsense. Market pressures would force vendors to fix all their bugs. Fortunately (for MS) market*ing* pressure wins out over market pressure. And users are all too forgiving and tolerant of bugs and problems and security holes. Being an effective monopoly definitely has it's upside. Just my opinion of course. I'm not speaking on behalf of the flightgear project here. :-) I guess what amazes me is the incredible tolerance of the computing public. I wonder what would happen if we gave our politicians the same amount of latitude that we give our computer software. Or for that matter, gave each other the same amount of margin for error as we give our computer software. :-) Of course, being a linux user means I don't tolerate this sort of crap in my software or in my politicians. I expect nothing less than complete perfection. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Can we ban outlook users from the list?
Cameron Moore wrote: Yes, we can actually. Just filter out this in Mailman: ^X-Mailer:.*Outlook Problem solved. ;-P Must fight ... the ... urge ... to ... Disclaimer. We love our outlook users, just not the virus and security problems that seem to plague this particular piece of software. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Lee Elliott wrote: Just a bit more grist for the mill - as if it were needed:) One of the type of up-coming generations of a/c are likely to be controlled by thrust alone. No moving control surfaces and probably tailess. What I haven't figured out yet is if the concept's relying upon a very simple aerodynamic model, with lots of excess thrust, in which case simulating it might be possible(?), or it might rely upon clever aerodynamics, which I would have thought would be pretty difficult to simulate. But bearing that in mind, the AP design and structure will need to be flexible enough to work with these sorts of a/c control systems. I guess it also touches on the area of missile control systems too. My understanding is that they will be doing a lot of thrust vectoring ... lots of research is/has been done in that area. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] New autopilot: Propulsion only FCS
Jon Berndt wrote: My understanding is that they will be doing a lot of thrust vectoring ... lots of research is/has been done in that area. Curt. No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf Differential thrust (per side) induces a sideslip -> induces roll. Changes in thrust (thrust line offset from CG in Z) induces pitch changes as well as accel/decel. Etc. Again, this is something that the JSBSim FCS components could handle - you need building blocks. I thought some were discussing this in the context of fighters of the future. Just ignore me. :-) Curt. -- Curtis Olson Intelligent Vehicles Lab 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] New autopilot
Roy Vegard Ovesen wrote: I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. That might be interesting. Maybe we need an official "autopilot.nas" file so the parsing of the nasal code wouldn't have to happen each frame (even though it is lightning fast.) :-) I think a hack is the way to go, and if we can use Nasal to do it we can implement this hack, the one-eighty-hack and any other hack that we might need. By the way, did you get my reply with answers and the updated PID algorithm?? I'm not sure I got through your spam-filter. Yes that got through, thanks. For what it's worth, looking at my spam filter, I see that it is catching 1 new spam message every 7 minutes on average. It's no fun being this popular. :-( I'm guessing I do lose a legit email now and then, but a new spam message every 7 minutes all day every day just isn't anything I could deal with manually. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about the threaded tile loader
David Luff wrote: Could someone please clarify my understanding of the threaded tile loader? I'll take a stab at it. :-) My initial pre-conception before reading the code was that the loader thread would simply load the data from disk, and pass off a memory buffer containing an image of the disk contents to the main thread. I was also under the impression gained somewhere in the mists of time that calling any plib code in a separate thread was a bit of a no-no. Both are reasonable assumptions, but we've tried to push our luck a bit. Calling any opengl code from more than one thread in a program is a massively big no-no.[1] It's important to note that loading a model that triggers loading a texture will trigger opengl calls, so you can never use the ssgLoadXYZ() functions from a separate thread. [1] You can get away with it if you carefully protect each opengl call so you don't get your thread interrupted in the middle of an opengl call. And you have to know exactly what you are doing in terms of how the opengl calls are interleaved. Imagine two different people in your back seat giving you "left/right/straight" directions to two different destinations and interleaving the instructions together. Any idea where you will actually end up? Neither do I. And most often in opengl land, you just crash the program. But despite all the potential dangers, calling some plib code under some circumstances from a separate thread is ok if you are careful. The main guideline is that you must be careful never to modify the scene graph while plib is trying to traverse it. However, reading the code, it appears that there's actually quite a bit of loading going on in the separate loader thread - from what I can see: The separate thread loop is FGTileLoader::LoaderThread::run() This calls FGTileEntity::load(...) when a tile needs to be loaded. From this, FGTileEntity::obj_load(...) is called. From this, sgBinObjLoad(...) is called. And finally, from this sgMakeLeaf(...) is called. Along the way, quite a bit of plib code is called, although as far as I can see no openGL functions are called. My question is, am I correct in thinking all of the above does indeed run in a separate thread, and could someone please clarify what can and can't run in a separate thread. Some more specifics. All the FG terrain textures are preloaded as part of the material library. So we can load terrain and assemble the plib scene graph without needing to make any opengl calls. We can get away with making a lot of plib calls in a separate thread if they are all referencing some newly created sub tree that is not connected into the main scene graph. That way, plib could never be rendering the tree we are fiddling with in the separate thread. We use the idea of queues (first in, first out lists) to keep track of everything. The queues are carefully designed to be thread safe and mutually exclusive and protected from concurrent access. We use the idea of a work queue so a particular thread only has to lock the queue for a very short time. Just long enough to grab the next thing to do, or just long enough to push something into the back of the line. This way, threads really can't block each other for any substantial length of time. When new tiles need to be loaded, they are pushed onto the back of a tile-load queue. The threaded loader grabs the first entry off this tile-load queue and starts working on it. It loads all the raw data off disk and builds an intermediate structure. Then it traverses this structure building a plib sub branch. The subbranch exists independently of the main scene graph. When the tile loader finishes building the structure. It pushes it on a "please-connect-me-to-the-main-scene-graph" queue. The main loop will check this queue regularly and hook anything it finds there into the main scene graph. Occasionally, a tile can reference 3d models that require calling ssgLoadXYZ() ... things like building, bridges, etc. When the threaded tile loader runs into any of these, it will push the object onto a separate model loading queue for the main loop to handle. The main loop checks the model loading queue and loads anything it finds there and connects it properly into the scene graph. This could cause big pauses in the frame rate for large models, but we really don't have a choice unless we want to completely rewrite the plib model loaders which I'm not keen on doing. There's some similar things that happens with deleting tiles. To delete a tile, we disconnect the tile from the scene graph, and push it onto a "delete queue". One thing to be aware of is that our "random object" placement system can generate parents with ***huge*** numbers of children (on the order of thousands.) plib deals with these lists linearly which is perfectly fine until it comes time to delete entries. It uses the delete the first and shuffle everything over one approach. It is no
[Flightgear-devel] [OT] Ventura publisher (really old)
Ok, I'm abusing my powers here to ask a really [OT] question. If anyone objects, you definitely wouldn't be out of line. But it's easier to ask forgiveness than permission, right? :-) I have some really old, as in ancient ventura publishing files that I'd be interesting at cracking open and at least extracting out the important stuff in order to convert to some more modern tool. I'm seeing extensions like ".WP" and ".WS" which is probably text in word perfect and word star formats. I'm also seeing extentions like .CAP .CHP .CIF .VGR .CHP .STY .GEM and .PLT Does this ring a bell for anyone? It's probably 10 year old stuff at least? netbpm supposedly has a GEM converter, but these gem files are older than what the gemtopnm util supports. Ughhh! I should probably just rm * the whole lot, have a minute of silence, and get on with my life, but I thought I'd ask first Thanks, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: Fog disappears when looking towards sun
David Luff wrote: There seems to be a problem with the fogging on my machine (Linux, NVidia card). When the sun is in, or just out of, the field of view, the fog disappears and visibility is perfect. This is most easily seen by starting at dawn or dusk, and with a low visibility (eg 5000), climb to about 1000ft agl and look or fly around, but happens with the default visibility as well, and I have seen it briefly at noon, but can't reliably reproduce it at noon. Hi Erik. :-) I'm seeing this too after a recent cvs update. Must have something to do with the sun pre/post draw call back functions. Thanks, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about the threaded tile loader
Martin Spott wrote: "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: Occasionally, a tile can reference 3d models that require calling ssgLoadXYZ() ... things like building, bridges, etc. When the threaded tile loader runs into any of these, it will push the object onto a separate model loading queue for the main loop to handle. The main loop checks the model loading queue and loads anything it finds there and connects it properly into the scene graph. This could cause big pauses in the frame rate for large models, but we really don't have a choice unless we want to completely rewrite the plib model loaders which I'm not keen on doing. O.k. ;-) I still dare to ask the question if _this_ is the effect of frame rates falling near to one on the SGI when looking from south over KSFO in the direction of SF downtown ? I'm pretty shure the Octane OpenGL hardware could render the whole view at marvellous frame rates if it gets the necessary geometry and texture data fed at the right point of time. There are a lot of examples (demos as well as real applications) for the SGI that testify incredible performance of the graphics subsystem when the data that has to be rendered comes 'just in time'. Hi Martin, Model loading would only cause a temporary disruption for a few frames until all the models are loaded. If you let the sim sit for a few seconds, the initial extreme stutters will go away and you should stabalize out to your ultimate frame rate. Here's one thing that surprised me. For a time in my life I was a unix sys admin managing sgi, solaris, and linux workstations at my university here. This was starting in the early 90's. At that time, sgi reigned supreme in the graphics world, and the perception anyways was that if you wanted to do something graphical, the sgi was the best place to do it. Sun was definitely not as far along in terms of graphics horse power, and PC unix barely had a graphical window system at the time. In 96/97 we got going with FlightGear and a big part of what made this possible was that PC's were just starting to get hardware accelerated 3d capabilities themselves with the amazing, stupendous voodoo1 cards. Even better, these had linux support. That's when the bell went off in my head and I really got fired up about the idea that we can make this FlightGear thing work for us. Where I'm going with this ... is that after we had FlightGear established and had some running code, I went back and tried running it on our supremely powerful sgi graphical workstations. We had lots of indy's floating around so I got FG compiled for irix and gave it a try. Ugghh! Indy's have no hardware texture support at all. FG crawled. We had some indigo 2's also in our lab. Certainly these would crank, but alas, they didn't have any hardware texture support either. Finally we had a $250,000 dual cpu onyx. I tried running FG on that. Yes! It worked great. I was getting a solid 60hz. It was beautiful! We also had some O2's floating around. I was really disappointed with the performance we got out of them for FG. No offense Erik! What I learned though is that good hardware accelerated *texture* support came really late in the game for sgi, and from my experience only worked really well on the extremely high end machines. I think initially sgi's approach was to concentrate good performance on non-textured 3d cad type applications. I would speculate that if you got rid of all textures in FG, it would run much closer to how you think it should on sgi hardware. When we got our first O2, it came with a slick "out-of-box experience" with neat and complex and interesting 3d demos and such. But if you look closely, they didn't use much texturing in those demos, and they played a few tricks. With FG, just about every surface in the entire world has texture pasted on it. And given that we can fly any where and look at our world from just about any perspective, we are limited in the number of tricks that we can play around with. Customers of mine who use CATIA or UG on SGI (no, it's not me who's installing these systems) load drawings of a whole car into their CAD application. This is a procedure that takes about 5 hours on a 200/300 MHz CAD workstation (be it HP, IBM or SGI) - given the file server is fast enough (I'm the guy who set up the file servers :-) These drawings are really _huge_, but once they are loaded the display system is really snappy when it comes to modifying the view in whatever way you like (rotating, zooming, adding or removing layers, views from inside or outside ). Do these drawings use any textures? I'm guessing they don't. Also, I bet a cad application can do a lot with culling pieces of the model out to reduce the rendering work load. This leads me to the
Re: [Flightgear-devel] test
Andy Ross wrote: [EMAIL PROTECTED] wrote: Mail transaction failed. Partial message is available. Oh no! Curt's infected. We have to kill him now. Is that Oregon's answer to affordable universal health coverage? :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot update.
I'm tempted to commit my autopilot changes to cvs. Here's what I have done so far. - I've implimented Roy's suggested PID algorithm. Compared to what we had, this algorithm is better behaved, is much more configurable, and much more tunable. It can be made to do a much better job of easing into large control inputs rather than slamming the controls full stop. It handles the integrator windup problem. And also impliments the "D" portion of the PID which we never had before. For what it's worth the new algorithm works on the change in error from the previous frame rather than the absolute error. - I have completely overhauled the autopilot config mechanism. The autopilot and it's various modes are now configured via an xml data file. There is a global generic one that all aircraft will inherit, but this can be easily overridden with an aircraft specific AP config in the -set.xml file. This has had a cascading effect on a lot of files (gui, input, controls, hud, etc.) that made reference to the HUD. - newauto.cxx and newauto.hxx are now axed. I will probably let them exist (but not be compiled) for a while in case there are any nuggets left in there that we still want to extract. - I've rewritten the autopilot config dialog box to match my new updates. - Here are the various modes that are currently implimented: Heading modes: - wing leveler - heading bug hold - true heading hold (the route manager manipulates the true heading) - Nav1 CDI hold Pitch/Altitude modes: - Pitch hold - AOA hold - Altitude hold - AGL hold (i.e. crude terrain following) - Nav1 GS hold Velocity modes: - Speed hold (by manipulating throttle) - Speed hold (by manipulating pitch) - You can tweak the autopilot config/gains on the fly via a roundabout mechanism. Open up the property browser and find the /autopilot/new-config/ tree. Find the particular PID controller you want to manipulate and make changes. Then select "Reconfig Autopilot" at the bottom of the Autopilot menu. Right now the autopilot config sliders don't work. What I haven't done. - I need to write up some documentation on the new PID algorithm, the meaning of the input parameters, and some basic strategies for tweaking the gains. - I haven't set up (or ported) any specific autopilot configurations for existing aircraft, other than the C172. - XML instruments that reference/control the autopilot will need to be updated. - I haven't addressed issues of FCS systems. That would be an interesting follow up of this project. We would probably need to put an abstraction layer in between the control inputs and the control surface output. For simple aircraft like the cub, these could be directly mapped, but for complex aircraft like an airbus, we could put a FCS in between. So if I do a commit now, there might be some temporary breakage and a slightly different subset of functionality, but I think this will be a good stepping stone from which we can then move forward towards addressing the remaining issues. Comments? Any objections to committing my updates? Thanks, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Autopilot update.
Jon Berndt wrote: Does this make it any easier to bypass the FlightGear autopilot (and perhaps soon-to-exist) FCS system, so the FDM could provide this functionality, if desired - perhaps by simply not including an autopilot/FCS file or definition through your new method? This is very important to the JSBSim guys, to have that capability. Not defining an autopilot for a particular aircraft (or defining a null autopilot) is trivial to do. If the autopilot is defined within JSBSim, how will it be manipulated from FlightGear (as far as activating/deactivating the different modules or adjusting the reference/target points.) What about things like route following (gps) or Nav CDI/GS holds? How does that get communicated to JSBSim? Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Autopilot update.
Jon Berndt wrote: Yes this is where it gets complicated. There are modes that are obviously relevant to mere flight dynamics, such as attitude hold, heading select, wings level, terrain following, etc. -- and even these use *sensor* inputs as opposed to actual FDM aircraft state data. The other modes that are tied more firmly to instrument/navigation/ILS etc. are of no interest to JSBSim. So, the answer might be to allow a split. Unless I am mistaken, it seems that ought not to be impossible. I can't think of a reason why that wouldn't be straightforward and doable. This question arises for several reasons, one of which is that I might want to model "non-standard" craft (I'll leave it at that for the moment). I want to control it in a specified way without worry that the flight will be affected in ways that I am unaware of -- that is, I'd like complete control (and *know* that I have complete control). I think it would be totally up to the aircraft designer how they want to impliment the FG autopilot vs the JSBSim autopilot or some mix of the two. The FG side is completely reconfigurable on a per-aircraft basis. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Autopilot update.
David Culp wrote: Comments? Any objections to committing my updates? It looks great, and I think the sooner it gets commited the better, so we'll have plenty of time to work with it before 0.9.4. I already have a wish list :) mach hold, and vertical speed hold. Ok, it's been at least an hour and no one has objected. :-) I will try to follow up with some documentation this weekend still. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Autopilot update.
Norman Vine wrote: Hmm... 1 hour 08 minutes on a weekend Was any discussion really wanted :-) Being a volunteer and doing this on weekends and evenings, I've got to move quickly when I do get the chance. I've been working hard on this and trying to factor in comments and suggestions made over the last week or two. I was just giving people a last chance "speak now or forever hold your peace." :-) Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Autopilot update.
Frederic Bouvier wrote: Small glitch at run time : route = 0D7673D8 Failed to load autopilot configuration: fgfsbase/Aircraft/Generic/generic-autopilot.xml CVS Updated and no generic-autopilot.xml Gaahhh! I swear I added that file. Ok, it's there now. Sorry about that. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] CVS Compile
Fred, I just committed a variation of this (assuming I understood the problem correctly hopefully this will fix it.) Otherwise just holler. Curt. Frederic Bouvier wrote: John Wojnaroski wrote: There has been a fix applied to both configure.ac and src/Cockpit/panel.cxx. Make rue those files are up to date and rerun autoconf and configure before proceding. I did a fresh CVS checkout late Saturday night (PST). I'll try again... Okay, started a fresh build with files dated: 14965 Jan 27 01:31 configure.ac 28060 Jan 27 01:31 panel.cxx 14313 Jan 22 10:42 panel.hxx ->sh autogen.sh ->/configure --with-threads The config log shows that the test for truncf was successful but the compile error is still there. Some sort of path/environment problem Try the patch below -Fred I:\FlightGear\cvs\FlightGear\src\Autopilot>cvs -z3 -q diff -u route_mgr.cxx Index: route_mgr.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Autopilot/route_mgr.cxx,v retrieving revision 1.1 diff -u -r1.1 route_mgr.cxx --- route_mgr.cxx 31 Jan 2004 19:47:45 - 1.1 +++ route_mgr.cxx 1 Feb 2004 16:21:02 - @@ -21,11 +21,11 @@ // $Id: route_mgr.cxx,v 1.1 2004/01/31 19:47:45 curt Exp $ +#include "route_mgr.hxx" + #include #include -#include "route_mgr.hxx" - FGRouteMgr::FGRouteMgr() : route( new SGRoute ), ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson Intelligent Vehicles Lab 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] CVS Compile
Hi John, Try configuring with out the -with-weathercm option. Someone might need to go in and do some clean up there possibly. Curt. John Wojnaroski wrote: It's me again ;-) There has been a fix applied to both configure.ac and src/Cockpit/panel.cxx. Make rue those files are up to date and rerun autoconf and configure before proceding. I did a fresh CVS checkout late Saturday night (PST). I'll try again... Okay, started a fresh build with files dated: 14965 Jan 27 01:31 configure.ac 28060 Jan 27 01:31 panel.cxx 14313 Jan 22 10:42 panel.hxx ->sh autogen.sh ->/configure --with-threads The config log shows that the test for truncf was successful but the compile error is still there. Some sort of path/environment problem Okay, that problem got cleared up, on to the next ran ./configure --with-threads --with-weathercm Upon compiling: g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/ X11R 6/include -g -O2 -D_REENTRANT -c -o atis.o `test -f atis.cxx || echo './'`atis. cxx In file included from atis.cxx:40: ../../src/WeatherCM/FGLocalWeatherDatabase.h:63: Main/fgfs.hxx: No such file or directory make[2]: *** [atis.o] Error 1 make[2]: Leaving directory `/usr/local/SimFG/source/src/ATC' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/SimFG/source/src' make: *** [all-recursive] Error 1 Looking back it appears this file no longer exists in 0.9.3. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson Intelligent Vehicles Lab 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
[Flightgear-devel] New Autopilot Documentation
Roy Vegard Ovesen wrote: I've slapped together a short document on controller tuning. [ snip ] Thanks Roy! For everyone: I've integrated this into a larger document which attempts to explain the basic ideas behind control theory and then describes the specific PID algorithm we have implimented for FlightGear. This information isn't strictly necessary for building aircraft specific autopilot configurations, but it's such cool stuff it's worth mentioning. :-) The last two sections of the document describe the autopilot configuration file format and provides some specific tips for tuning the PID modules to work well for your specific aircraft. There is a generic/example autopilot configuration which all aircraft will inherit by default. So, aircraft designers don't necessarily need to create something from scratch. 99% of the time you should be able to copy an existing configuration from a similar aircraft and mostly be 99% done before you've even started. But we need to boot strap ourselves and get a few well working config files for the various classes of aircraft before my previous statement is 99% true. :-) http://www.flightgear.org/Docs/XMLAutopilot/ This document is a first stab. I'm sure it's full of mistakes and possible misunderstandings or oversites. Hopefully there aren't too many outright falsehoods. Feel free to submit feedback and corrections. Original is in latex format. I already know I need to work on the html formating of the description of the algorithm variables. :-) Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] 3D aircraft model
Vivian Meazza wrote: I've been amusing myself for the last couple of months creating a 3d model of the Hawker Hunter. It's as accurate as I can make it, with a few minor fudges for YASIM. Some views are at: http://myweb.tiscali.co.uk/vmeazza/FlightGear/fgfs-screen-004.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/fgfs-screen-002.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/fgfs-screen-003.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/fgfs-screen-008.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/pilots-notes.pdf Don't know if it is of any interest to you guys. It flies easily using YASIM, but it's 7,500 vertices flying in close formation, so it makes my Pentium III 866 creak a bit, especially around the Bay area. Of course, it lacks a decent electrical, hydraulic, engine control system... might get around to those sometime soon. The instruments are very similar to those used in the Seahawk with which it was a near contemporary, so it wouldn't be a major effort to produce a 3d cockpit for that model, with Lee's permission... I have access to the Pilot's Notes for that aircraft, so I might be able to come up with something pretty accurate. Hi Vivian, Your Hawker Hunter looks great. I'm sure many others would love to try flying it. Since you are the author you get to decide how to distribute it, but I'm happy to add it to our aircraft cvs archives. Feel free to send it to me [off-list] and I can commit it to CVS. Also, I bet Lee would be happy to have someone help get him going on 3d cockpits. He's been talking about A-10 texturing, so he must be getting bored. :-) Thanks! Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
Richard Bytheway wrote: A question. When defining a cascade controller, is it important that the early stages of the controller go before the later stages in the config file? Yes, this is the optimal arrangement. > Alternatively, do the individual PID controllers get processed in the order they appear in the config file each frame ... Yes. ... or are any dependencies worked out behind the scenes? No, the pid evaluator just runs each pid module in the order they are specified in the config file. If order is important, I assume that you could get a 1 frame lag between each PID stage if they are in the wrong order. Yes, that is what would happen. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model
Vivian Meazza wrote: I'll try to put it on a vertex reducing diet - what is a reasonable target? It's a very complex model though, with a number of moving parts. Once I've cleaned it up a bit, I'll send it to Curt off list - it'll be a few days though. Vivian, for a first release I wouldn't worry too much about polygon count. If it turns out to be a serious problem, you could look at putting in the extra work to reduce the polygon count. I think it's ok for FlightGear to have a range of aircraft with varying amounts of polygons. We don't want to waste polygons needlessly, but as someone else mentioned, there are a number of simpler models available to people with less hardware power. Just like there are any number of simpler scenery areas as well. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
