[Flightgear-devel] To Eric Hofman the T-38
Ok Eric The T-38 animations are finished.Much easier to animate with no diehedrial and sweep on the wings and tail. I will winzip the file.Where should I email it to.There are three files the .ac file the xml file and the texture for the conopy which I have added a mask to so it is now transparent. Cheers Innis _ Chat via SMS. Simply send 'CHAT' to 1889918. More info at http://ninemsn.com.au/mobilemania/MoChat.asp?blipid=6800 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] To Eric Hofman the T-38
Innis Cunningham wrote: Ok Eric The T-38 animations are finished.Much easier to animate with no diehedrial and sweep on the wings and tail. I will winzip the file.Where should I email it to.There are three files the .ac file the xml file and the texture for the conopy which I have added a mask to so it is now transparent. You can post an URL, or sent it directly to me if you wish. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ssgLoadAC error on KEMT + patch
On 9/18/03 at 11:25 PM Thomas Arendsen Hein wrote: When updating from CVS I got a conflict in AILocalTraffic.cxx, because I removed two obsolete lines in my patch which still are in CVS. The problem is, I forgot to attach my patch! So here is another one which removes these two lines. Thomas Thanks Thomas, this is now in CVS. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT Satelite Images
Norman Vine [EMAIL PROTECTED] said: Awesome view of Hurricane Isabel just touching the East Coast of the US http://rapidfire.sci.gsfc.nasa.gov/gallery/ This evening the outer fringes of the storm were overhead here on Cape Cod 42.3N 71.7W and was as spectacular a sunset as I have ever seen. note center of storm was at 31.1N 73.3W Thank goodness that the top was blown off of this storm and it is no where as powerful as it once was. Nice photos. I was looking at wc130 hunter articles and came up with a couple: http://www.knoxstudio.com/shns/story.cfm?pk=ISABEL-EYE-09-17-03cat=AN http://www.sunspot.net/news/weather/hurricane/bal-inside0918,0,2496337.story?coll=bal-home-headlines And this page has a couple of eyewall photos: http://www.hurricanehunters.com/isabel.htm I read somewhere that Isabel's three days at category 5 levels is one of the longest on record and it afforded several people the opportunity to fly into a category 5. That got me thinking that it would very interesting and unusual to build a simulation of a hunter flight. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: help]
Erik Hofman wrote: Hi I have the following questions about FlightGear-0.9.2. Could you please help me to post the following information to the development group? The questions are as follows: In FlightGear-0.9.2, the file size of fgfs.exe I download from website is 2,656 KB, but the size of the same file became 46,414 KB when I compiled the source code with the Cygwin compiler under Windows 2000. Could someone tell me how to optimize the compiling process? Could someone tell how to compile the FlightGear source code to the MS Windows binary version with the Cygwin compiler? This looks like it is bloated with debug info, and maybe a case of including static libraries where dynamic libraries are available. I was just realized there is another issue. Most developers compile without in-lining any code. Tests have shown that in-lining code doesn't make a huge difference (actually the code might become slower ...) but it decreased the executable tremendously. Try disabling in-lining during compile time. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [Fwd: help]
Erik Hofman writes: Tests have shown that in-lining code doesn't make a huge difference (actually the code might become slower ...) but it decreased the executable tremendously. IMO the jury is still out on this :-) Compiling with minimal inlining *will* decrease compile times and IIRC was the prime motivator for those making the argument that inlining doesn't do any good. statistics-like-code-can-be-tweaked-to-prove-anything'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] alpha blend and color animation
I'm looking at adding the ability to animate the emissive color properties of model objects. While it might seem unlikely that both emissive and alpha blend would be used on the same object, maybe we should have a color animation instead of a blend animation which can then have multiple property values for all the various color/material components that could be changed. That way we could limit scenegraph traversals if more than one color property is to be animated on the same object. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] alpha blend and color animation
Jim Wilson writes: I'm looking at adding the ability to animate the emissive color properties of model objects. While it might seem unlikely that both emissive and alpha blend would be used on the same object, maybe we should have a color animation instead of a blend animation which can then have multiple property values for all the various color/material components that could be changed. good idea... hmmmaybe this should be material animation Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] alpha blend and color animation
Norman Vine wrote: Jim Wilson writes: I'm looking at adding the ability to animate the emissive color properties of model objects. While it might seem unlikely that both emissive and alpha blend would be used on the same object, maybe we should have a color animation instead of a blend animation which can then have multiple property values for all the various color/material components that could be changed. good idea... hmmmaybe this should be material animation I'm not sure I understand completely what you are trying to do, but the code is there now. I needed it for some things, and as long as that's still available I don't really mind. We have two places where it is used right now, so changing the name wouldn't cause much pain either. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: help]
Norman Vine wrote: Erik Hofman writes: Tests have shown that in-lining code doesn't make a huge difference (actually the code might become slower ...) but it decreased the executable tremendously. IMO the jury is still out on this :-) Compiling with minimal inlining *will* decrease compile times and IIRC was the prime motivator for those making the argument that inlining doesn't do any good. statistics-like-code-can-be-tweaked-to-prove-anything'ly yr's True. But given that there was no noticeable effect I guess we're safe. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] alpha blend and color animation
Erik Hofman [EMAIL PROTECTED] said: Norman Vine wrote: Jim Wilson writes: I'm looking at adding the ability to animate the emissive color properties of model objects. While it might seem unlikely that both emissive and alpha blend would be used on the same object, maybe we should have a color animation instead of a blend animation which can then have multiple property values for all the various color/material components that could be changed. good idea... hmmmaybe this should be material animation I'm not sure I understand completely what you are trying to do, but the code is there now. I needed it for some things, and as long as that's still available I don't really mind. We have two places where it is used right now, so changing the name wouldn't cause much pain either. I haven't worked out how the xml might look, but the general idea would be that multiple material properties could be manipulated simultaneously, instead of just the diffuse alpha as it is now. In any case, yes the alpha blend will still work, it'd just be a matter of changing the xml. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Beyond presets
Unfortunately, while the presets hierarchy brought some benefits, it also broke saving and restoring flights. I think that it's time to consider doing away with the presets hierarchy, and trying something like this: 1. Make an in-memory copy of the property tree that we can revert to when the user wants to reset; we could even keep a stack of reset points, if that was useful to anyone. 2. Add a few /sim/startup properties to indicate what information should be used for position, orientation, etc. For example, /sim/startup/init/position-type : (latlon|airport|navaid|runway) /sim/startup/init/altitude-type : (msl|agl|glidepath) /sim/startup/init/orientation-type : (rph|runway) /sim/startup/init/time-type : (utc|local|sunpos) etc. I'm sure that people can think of a better classification. From this point on, then, our initialization code can simply look at these to decide whether to initialize based on the airport, etc. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
David, I'm open to something more sensible, but let's proceed with caution. I have a side project that is critically wired into the current presets arrangement and I can't afford to have that broken, at least not for very long. Hopefully if you do make changes you are willing to work with me to make sure my other stuff doesn't get seriously broke. Thanks, Curt. David Megginson writes: Unfortunately, while the presets hierarchy brought some benefits, it also broke saving and restoring flights. I think that it's time to consider doing away with the presets hierarchy, and trying something like this: 1. Make an in-memory copy of the property tree that we can revert to when the user wants to reset; we could even keep a stack of reset points, if that was useful to anyone. 2. Add a few /sim/startup properties to indicate what information should be used for position, orientation, etc. For example, /sim/startup/init/position-type : (latlon|airport|navaid|runway) /sim/startup/init/altitude-type : (msl|agl|glidepath) /sim/startup/init/orientation-type : (rph|runway) /sim/startup/init/time-type : (utc|local|sunpos) etc. I'm sure that people can think of a better classification. From this point on, then, our initialization code can simply look at these to decide whether to initialize based on the airport, etc. All the best, David ___ 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.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] Beyond presets
Curtis L. Olson wrote: David, I'm open to something more sensible, but let's proceed with caution. I have a side project that is critically wired into the current presets arrangement and I can't afford to have that broken, at least not for very long. Hopefully if you do make changes you are willing to work with me to make sure my other stuff doesn't get seriously broke. I've always had difficulties deciding where the initialization of a property should go: in the presets functions, or in preferences.xml file. I opt for the latter. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Wish-list idea
Hello all, Once you've started FG, the tower views are permently fixed to the departure airfield. Would it be difficult to optionally switch the tower views to the destination airfield, when one is set in the AP waypoint list? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
On Fri, 2003-09-19 at 13:00, David Megginson wrote: Unfortunately, while the presets hierarchy brought some benefits, it also broke saving and restoring flights. I think that it's time to consider doing away with the presets hierarchy, and trying something like this: 1. Make an in-memory copy of the property tree that we can revert to when the user wants to reset; we could even keep a stack of reset points, if that was useful to anyone. 2. Add a few /sim/startup properties to indicate what information should be used for position, orientation, etc. For example, /sim/startup/init/position-type : (latlon|airport|navaid|runway) /sim/startup/init/altitude-type : (msl|agl|glidepath) /sim/startup/init/orientation-type : (rph|runway) /sim/startup/init/time-type : (utc|local|sunpos) This sounds awful close to /sim/presets, so it sounds to me like we may always need the functionality. That being the case, why change it? etc. I'm sure that people can think of a better classification. From this point on, then, our initialization code can simply look at these to decide whether to initialize based on the airport, etc. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Opengc-devel] Linux Hardware
Hi John, On Thu, Sep 18, 2003 at 10:50:24AM -0700, John Wojnaroski wrote: Hi, Over the course of the last year I've been trying to find simulation hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support open source programs like FlightGear and OpenGC. All I could find was Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot of interest in developing stuff for open source software under Linux. Sadly, this is true. Maybe Flightgear will change this in the future. In the home cockpit building community, Linux and flightgear don't seem to be very well known and used. I think that flightgear is especially suited for that since its open source so you can get information in and out easily and dont have to rely on peek'ing and poke'ing the memory of the running simulator program. Well, I never followed the herd and was not about to move over to Windows or FS. That would be a step back, wouldn't it :-) So I sat down and designed an interface board for the MCP and EFIS as starters. Turns out, the board is somewhat generic in that it takes rotary enconder data and key scan circuits and along with the Linux driver stuffs the data into a small file that the application can read/write. Using the board goes like this: The board has a standard parallel port interface (I wanted to use IEEE1284 EPP but opted for the most common, simplest for the moment). It will run either on your printer port or any additional parallel port board (ISA or PCI) you care to install or I've got a custom ISA board with three programmable ports I used for development and testing. I've done something very similar. I'm using the serial port, however. The whole thing is based on microchips PIC line of microcontrollers. (Like someone else pointed out in this thread, these are very good for our purposes) Right now I'm tying things together to build a board that can take up to 1024 inputs (switches/rotaries/..), 35 analog input channels, and 64 digital 8 bit channel outputs for things like 7segment displays, steppers, Digital to analog,... I've written a joystick kernel driver for linux for a earlier 16 channel analog to digital system. And its Flightgear tested :-) I've made Panels myself for a 747-400 MCP and EFIS. I thing all other things except the analog inputs will not be driven by a kernel driver, but rather by a user mode program that can connect to flightgear. That way, I can specify mappings eg. for the switches without having to unload/reload the kernel module over and over. So if you were running a MCP panel the data would be airspeed, mach, heading, vvi, and altitude. Plus the state of the pushbutton switches on the panel which would go to the FMC for the appropriate action and control of the system autopilot(s) and such. Or you could configure it as a NAV/RADIO panel and process the data as frequencies. Or whatever. The board and driver run in kernel space and use an interrupt to process changes in the state of the connected panel I'm still testing the board but getting close to a decision on moving from a breadboard to a PCB layout. Best guesstimate on cost is between $100 and $200. ( I have no idea on what the manufacturing costs beyond the production of the bare PCB look like, as always very dependent on size of the lot and quantity discounts for parts and amortization of start-up costs,etc,etc) Costwise, I estimate my currently in-progress circuit schematic would cost around $50-70 in components, depending on the prices of your suppliers. Trying to gauge the interest in such an item and welcome any feedback, questions, etc. For a look at some of the hardware panels I plan to use check out http://www.a-g-t.com I'm glad I'm not alone doing things like that under linux. Some older circuits and pics of my MCP/EFIS panels can be found at my home cockpit site: http://cockpit.varxec.de/ If you are interested, I can send you a png of the circuit I'm working on right now. Oh, and - of course - everything is released under the GPL, including the PIC assembly language firmware programs. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
Tony Peden writes: /sim/startup/init/position-type : (latlon|airport|navaid|runway) /sim/startup/init/altitude-type : (msl|agl|glidepath) /sim/startup/init/orientation-type : (rph|runway) /sim/startup/init/time-type : (utc|local|sunpos) This sounds awful close to /sim/presets, so it sounds to me like we may always need the functionality. That being the case, why change it? Not really -- the difference is that the actual values (lat/lon/alt/hpr/airport/navaid/etc.) live in the main property tree, and these tell us only where we should look for them. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wish-list idea
Lee Elliott writes:
Hello all,
Once you've started FG, the tower views are permently fixed to the departure
airfield. Would it be difficult to optionally switch the tower views to the
destination airfield, when one is set in the AP waypoint list?
Hi Lee,
There is code in the ATC system to find the closest ATC service of a given type to a
given point. It shouldn't be too hard to piggy-back that to get the closest tower
view to the user if desired.
In commlist.hxx - FindClosest(...) It writes the info into an ATCData, but it would
be trivial to write a wrapper to return the ICAO code so the main program wouldn't
have to know about ATCData. Likewise it requires the atc_type (TOWER, GROUND, etc) to
be passed in, but once again a wrapper function assuming tower could be quickly
written so that the main program need know nothing about atc_type.
Oh sod it, I can't resist, putting the below in commlist.cxx with a header in
commlist.hxx *should* work
commlist.hxx:
// Return the ICAO code of the nearest tower within m miles
// Returns if no tower within distance (defaults to 100)
string FindClosestTower(Point3D p, double m = 100);
// Return the ICAO code of the nearest tower within m miles
// Returns if no tower within distance (defaults to 100)
string FGCommList::FindClosestTower(Point3D p, double m) {
ATCData d;
double n = FindClosest(p.lon(), p.lat(), p.elev(), d, TOWER, m);
if(n) {
return(d.ident);
} else {
return();
}
}
You wouldn't want to call it every frame though - searches by area are not the most
efficient. (The ATC services are mapped by tile-id, but within the search area every
tile-id is traversed, and the resultant ATC services found ordered by distance.)
There are a fair few tiles within 100 miles = 200 X 200 miles = 40,000 sq miles!
Given that that's too far to see, I've just added miles to be passed in to the above,
since we can't see the plane at 100 miles! I believe that I found some problem with
very small distances such as 10 though - I seem to recall that if the centre of a tile
fell outside the distance then the tile was excluded, and an ATC service quite close
but on the edge of the tile could get overlooked. Somewhere between 20 and 40 miles
called intermittently (globals-get_current_commlist()-Find... etc) would probably do
you.
Good luck!
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wish-list idea
On Saturday 20 September 2003 01:33, David Luff wrote:
Lee Elliott writes:
Hello all,
Once you've started FG, the tower views are permently fixed to the
departure
airfield. Would it be difficult to optionally switch the tower views to
the
destination airfield, when one is set in the AP waypoint list?
Hi Lee,
There is code in the ATC system to find the closest ATC service of a given
type to a given point. It shouldn't be too hard to piggy-back that to get
the closest tower view to the user if desired.
In commlist.hxx - FindClosest(...) It writes the info into an ATCData, but
it would be trivial to write a wrapper to return the ICAO code so the main
program wouldn't have to know about ATCData. Likewise it requires the
atc_type (TOWER, GROUND, etc) to be passed in, but once again a wrapper
function assuming tower could be quickly written so that the main program
need know nothing about atc_type.
Oh sod it, I can't resist, putting the below in commlist.cxx with a header
in commlist.hxx *should* work
commlist.hxx:
// Return the ICAO code of the nearest tower within m miles
// Returns if no tower within distance (defaults to 100)
string FindClosestTower(Point3D p, double m = 100);
// Return the ICAO code of the nearest tower within m miles
// Returns if no tower within distance (defaults to 100)
string FGCommList::FindClosestTower(Point3D p, double m) {
ATCData d;
double n = FindClosest(p.lon(), p.lat(), p.elev(), d, TOWER, m);
if(n) {
return(d.ident);
} else {
return();
}
}
You wouldn't want to call it every frame though - searches by area are not
the most efficient. (The ATC services are mapped by tile-id, but within the
search area every tile-id is traversed, and the resultant ATC services found
ordered by distance.) There are a fair few tiles within 100 miles = 200 X
200 miles = 40,000 sq miles! Given that that's too far to see, I've just
added miles to be passed in to the above, since we can't see the plane at 100
miles! I believe that I found some problem with very small distances such as
10 though - I seem to recall that if the centre of a tile fell outside the
distance then the tile was excluded, and an ATC service quite close but on
the edge of the tile could get overlooked. Somewhere between 20 and 40 miles
called intermittently (globals-get_current_commlist()-Find... etc) would
probably do you.
Good luck!
Cheers - Dave
Ta - I'll give it a try:)
LeeE
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] heads up - aircraft reorg
Heads up aircraft designers! I just committed a fairly significant change to both fgfs source and data CVS repositories. This is another step towards making aircraft self contained in their own subdirectory. The end goals is to be able to install / remove / distribute aircraft that are entirely contained in their own subdirectory tree making things easier on everyone [hopefully]. :-) YAsim aero config files have moved out of Aircraft-yasim/ and into their respective aircraft subdirectories. Two areas of concern. There are about 40 variations on the c172 and about 20 variations on the c310 with different incantations and aliases and various conglomerations of yasim, jsbsim, 3d cockpits, 2d cockpits, etc. etc. etc. This was kind of messy since they all tend to refer back and forth to each other and all over the place. I think I got everything tweaked correctly, but those of you who care about these should maybe double check that I didn't screw something up. At some point it might be worth taking a pass through the existing aircraft and moving those that have significant problems or significantly missing pieces off to some other area ... We might also want to start thinking of an official organization hierarchy such as: Aircraft/ LightSingles/ JetFighters/ CommercialJets/ CommercialTurboProps/ Bombers/ WWI/ WWII/ SailPlanes/ Experimental/ Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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
