Re: [Flightgear-devel] turbine inlet temperature in the seneca (TIT)
Ok, I made a pretty gross hack for now, and used EGT but made the gauge show 100°F higher :-P On the other hand, since I am making a custom panel for the senecaII anyway, I could just make the gauges EGT for now, as they serve more or less the same purpose in engine management anyway. Torsten, you seem to be the maintainer for the SenecaII, would you be interested in including the gauges in the seneca at some point? Could make another nice fullscreen minipanel, since the small engine gauge cluster fits nicely in a monitor with the basic "sixpack".. https://gitorious.org/fgfs-ftd-mik/mik-ftd/blobs/master/OH-TWN/Panels/screenshot.jpg If yes, how would we proceed? And if yes, should they go in Aircraft/Instruments/ or into the SenecaII folder? I could also do some textures for the Seneca instrument panel, if that is a welcome idea? I have some panel photos I took a while ago that could be useful there.. //Tuomas On 6 December 2011 22:37, Ron Jensen wrote: > On Tuesday 06 December 2011 07:39:48 Torsten Dreyer wrote: > t. >> >> Ron Jensen is the master of the JSBSim piston engine code. IIRC he has >> the supercharger model on his backlog, maybe TIT will be part of his >> solution.. > > The current supercharger code is old, and strictly RPM based, and I don't have > a good solution. > > The EGT calculations changed slightly in the last (2.5) release, and will > change again (already in git) in the next release, so they may be more > accurate to use as a base for TIT. > > As I understand it, TIT is exhaust gas temperature measured before the turbo > and EGT is exhaust gas temperature measured after the turbo, so TIT will be > higher than EGT. The temperature difference should be somewhat proportional > to the boost ratio. The more boost being produced, the higher the > back-pressure in the turbine impeller, and higher pressure implies higher > temperature. > > Ron > > -- > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Snow line based on METAR
Hmm. As far as I know, METAR snow information only focuses on the runway surface. Imagine a nice sunny day in late march, where the runway is just dry asphalt, yet there can be lots of snow in the ground. On the other hand, if the runway surface has snow, we can pretty safely assume it exists on the landscape as well. But missing snowtam does not mean there is no snow in the landscape..! //Tuomas -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat update (lowercase names etc.)
Btw, if anyone feels intrigued about Mario's flying pizza airport, here it is: http://maps.google.com/maps/place?ftid=0x86415b90e61a4049:0xab0e9da4a50a2a4&q=mario%27s+pizza+sealy&hl=en&ved=0CA0Q-gswAA&sa=X&ei=YxfhTpzhJdXVOKDNuAw&sig2=M8avv0_jhvFgnD-ytx5bBQ Can't see planes on the ground, I suspect that the airstrip is mainly in support of ag-work planes and a stopover for cross-country fliers that want a quick snack. The double fence working as cattle pen is a nice touch of class > From: w...@jentronics.com > To: flightgear-devel@lists.sourceforge.net > Date: Thu, 8 Dec 2011 13:58:32 -0600 > Subject: Re: [Flightgear-devel] apt.dat update (lowercase names etc.) > > On Thursday 08 December 2011 07:07:58 Geoff McLane wrote: > > I guess the only thing is concerning 'closed' > > airports. Should they be in apt.dat at all? > > > > But if they are retained for 'historic', or > > other purposes, it would be good if they were > > all consistent... > > Just because an airport is 'closed' does not mean the runways no longer > exist... The Gimli Glider incident comes to mind. > http://en.wikipedia.org/wiki/Gimli_Glider. > > Even if the runways are removed and built over, often outlines are visible > from the air for years after the airport is removed. See > http://www.airfields-freeman.com/ for some examples. > > Ron > > -- > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat update (lowercase names etc.)
On Thursday 08 December 2011 07:07:58 Geoff McLane wrote: > I guess the only thing is concerning 'closed' > airports. Should they be in apt.dat at all? > > But if they are retained for 'historic', or > other purposes, it would be good if they were > all consistent... Just because an airport is 'closed' does not mean the runways no longer exist... The Gimli Glider incident comes to mind. http://en.wikipedia.org/wiki/Gimli_Glider. Even if the runways are removed and built over, often outlines are visible from the air for years after the airport is removed. See http://www.airfields-freeman.com/ for some examples. Ron -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat update (lowercase names etc.)
HB-GRAL wrote > -Original Message- > From: HB-GRAL [mailto:flightg...@sablonier.ch] > Sent: 08 December 2011 17:44 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] apt.dat update (lowercase names etc.) > > Another small question might be for ourairports names like this one: > > " Mario's Flying Pizza Airport " (sic!) > > should this become ... > > a) Marios Flying Pizza Airport > b) Mario s Flying Pizza Airport > c) Mario Flying Pizza Airport > > (This is serious, this is "2TA4" and it is in FlightGears apt.dat.) > > Origin in apt.dat is a) in apt.dat, but my script eats it up. So better > no change for this case ? > > Cheers, Yves > > > > Am 08.12.11 13:36, schrieb HB-GRAL: > > Hi all > > > > I am recently trying to update apt.dat airport names (in all flightgear > > relevant data versions, means original xplane 8.10/8.50 and flightgear > > apt.dat). I noticed caps in names, i.e. I am changing this names to > > upper/lower case, and I wrote a small python script to update the names > > from another data source in public domain (ourairports.com). > > > > I wish to submit this changes and updates. But I am asking you to review > > the different changes/possibilities of the script in a code 1 line of > > apt.dat : > > > > a) Same name, but to lower: > > Old line: '13141 0 1 01MT CRYSTAL LAKES RESORT' > > New line: '13141 0 1 01MT Crystal Lakes Resort' > > > > b) No shortcuts, but still<= 40 letters > > Old line: '13020 0 1 04CA GRAY BUTTE FLD' > > New line: '13020 0 1 04CA Gray Butte Field' > > or > > Old line: '1 940 0 1 0NY7 Murphys Lndg Strip' > > New line: '1 940 0 1 0NY7 Murphys Landing Strip' > > > > c) Same name, but marked as closed in apt.dat when ourairports says > > "closed": > > Old line: '1 250 0 1 03VA Whipoorwill Springs' > > New line: '1 250 0 1 03VA [X]Whipoorwill Springs' > > > > d) Take "new" names from ourairports > > Old line: '1 18 0 1 04W Keech\n' > > New line: '1 18 0 1 04W Field of Dreams Airport\n' > > > > What changes (0 or a/b/c/d) do you think are useful and will be accepted > > (also by developers working with apt.dat for FlightGear "side projects" > > like Maps, Launchers etc.) ? > > Marios Flying Pizza Airport If you can't do Mario's Flying Pizza Airport Vivian -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat update (lowercase names etc.)
Another small question might be for ourairports names like this one: " Mario's Flying Pizza Airport " (sic!) should this become ... a) Marios Flying Pizza Airport b) Mario s Flying Pizza Airport c) Mario Flying Pizza Airport (This is serious, this is "2TA4" and it is in FlightGears apt.dat.) Origin in apt.dat is a) in apt.dat, but my script eats it up. So better no change for this case ? Cheers, Yves Am 08.12.11 13:36, schrieb HB-GRAL: > Hi all > > I am recently trying to update apt.dat airport names (in all flightgear > relevant data versions, means original xplane 8.10/8.50 and flightgear > apt.dat). I noticed caps in names, i.e. I am changing this names to > upper/lower case, and I wrote a small python script to update the names > from another data source in public domain (ourairports.com). > > I wish to submit this changes and updates. But I am asking you to review > the different changes/possibilities of the script in a code 1 line of > apt.dat : > > a) Same name, but to lower: > Old line: '13141 0 1 01MT CRYSTAL LAKES RESORT' > New line: '13141 0 1 01MT Crystal Lakes Resort' > > b) No shortcuts, but still<= 40 letters > Old line: '13020 0 1 04CA GRAY BUTTE FLD' > New line: '13020 0 1 04CA Gray Butte Field' > or > Old line: '1 940 0 1 0NY7 Murphys Lndg Strip' > New line: '1 940 0 1 0NY7 Murphys Landing Strip' > > c) Same name, but marked as closed in apt.dat when ourairports says > "closed": > Old line: '1 250 0 1 03VA Whipoorwill Springs' > New line: '1 250 0 1 03VA [X]Whipoorwill Springs' > > d) Take "new" names from ourairports > Old line: '1 18 0 1 04W Keech\n' > New line: '1 18 0 1 04W Field of Dreams Airport\n' > > What changes (0 or a/b/c/d) do you think are useful and will be accepted > (also by developers working with apt.dat for FlightGear "side projects" > like Maps, Launchers etc.) ? > > Cheers, Yves > > -- > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat update (lowercase names etc.)
On Thu, 2011-12-08 at 14:02 +0100, Roland Häder wrote: > On Thu, 2011-12-08 at 13:36 +0100, HB-GRAL wrote: > > I wish to submit this changes and updates. But I am asking you to review > > the different changes/possibilities of the script in a code 1 line of > > apt.dat : > > > > a) Same name, but to lower: > > Old line: '13141 0 1 01MT CRYSTAL LAKES RESORT' > > New line: '13141 0 1 01MT Crystal Lakes Resort' > That will be better. I have noticed it on many airports/airfields. > > > > > b) No shortcuts, but still <= 40 letters > > Old line: '13020 0 1 04CA GRAY BUTTE FLD' > > New line: '13020 0 1 04CA Gray Butte Field' > Also better in full words, not shortcut. > > > or > > Old line: '1 940 0 1 0NY7 Murphys Lndg Strip' > > New line: '1 940 0 1 0NY7 Murphys Landing Strip' > Same above. Nice improvement. > > > > > c) Same name, but marked as closed in apt.dat when ourairports says > > "closed": > > Old line: '1 250 0 1 03VA Whipoorwill Springs' > > New line: '1 250 0 1 03VA [X]Whipoorwill Springs' > Can you please try to remove that [X] or is it somehow important? > > > > > d) Take "new" names from ourairports > > Old line: '1 18 0 1 04W Keech\n' > > New line: '1 18 0 1 04W Field of Dreams Airport\n' > I think it is hard to validate them but these \n are not parsed well in > my view (as a sim-pilot). > > > > > What changes (0 or a/b/c/d) do you think are useful and will be accepted > > (also by developers working with apt.dat for FlightGear "side projects" > > like Maps, Launchers etc.) ? > My launcher won't be affected by it, but maybe fgrun? And how about > taxidraw? > > > > Cheers, Yves > Regards, > Roland > Hi Yves, All looks like a good idea ;=)) I guess the only thing is concerning 'closed' airports. Should they be in apt.dat at all? But if they are retained for 'historic', or other purposes, it would be good if they were all consistent... - It seems there are already some 16 with [X], but most are with a space after this, except UHP1 [X]Lenino The others are all like 3R3 [X] Austin Executive Airport XBEL [X] Bellows AFB ... etc ... - But 2 just have the word 'closed', no [X] EIGM Gormanston (closed) YLUT Laverton (Military - Closed) - One with both KAUX [X] CLOSED Robert Mueller Municipal - One with just X, no square braces, and closed VHXX X CLOSED Kai Tak As stated, would be nice if they were all similarly 'marked', if retained... Just my 2 cents ;=)) Regards, Geoff. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat update (lowercase names etc.)
On Thu, 2011-12-08 at 13:36 +0100, HB-GRAL wrote: > I wish to submit this changes and updates. But I am asking you to review > the different changes/possibilities of the script in a code 1 line of > apt.dat : > > a) Same name, but to lower: > Old line: '13141 0 1 01MT CRYSTAL LAKES RESORT' > New line: '13141 0 1 01MT Crystal Lakes Resort' That will be better. I have noticed it on many airports/airfields. > > b) No shortcuts, but still <= 40 letters > Old line: '13020 0 1 04CA GRAY BUTTE FLD' > New line: '13020 0 1 04CA Gray Butte Field' Also better in full words, not shortcut. > or > Old line: '1 940 0 1 0NY7 Murphys Lndg Strip' > New line: '1 940 0 1 0NY7 Murphys Landing Strip' Same above. Nice improvement. > > c) Same name, but marked as closed in apt.dat when ourairports says > "closed": > Old line: '1 250 0 1 03VA Whipoorwill Springs' > New line: '1 250 0 1 03VA [X]Whipoorwill Springs' Can you please try to remove that [X] or is it somehow important? > > d) Take "new" names from ourairports > Old line: '1 18 0 1 04W Keech\n' > New line: '1 18 0 1 04W Field of Dreams Airport\n' I think it is hard to validate them but these \n are not parsed well in my view (as a sim-pilot). > > What changes (0 or a/b/c/d) do you think are useful and will be accepted > (also by developers working with apt.dat for FlightGear "side projects" > like Maps, Launchers etc.) ? My launcher won't be affected by it, but maybe fgrun? And how about taxidraw? > Cheers, Yves Regards, Roland signature.asc Description: This is a digitally signed message part -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] apt.dat update (lowercase names etc.)
Hi all I am recently trying to update apt.dat airport names (in all flightgear relevant data versions, means original xplane 8.10/8.50 and flightgear apt.dat). I noticed caps in names, i.e. I am changing this names to upper/lower case, and I wrote a small python script to update the names from another data source in public domain (ourairports.com). I wish to submit this changes and updates. But I am asking you to review the different changes/possibilities of the script in a code 1 line of apt.dat : a) Same name, but to lower: Old line: '13141 0 1 01MT CRYSTAL LAKES RESORT' New line: '13141 0 1 01MT Crystal Lakes Resort' b) No shortcuts, but still <= 40 letters Old line: '13020 0 1 04CA GRAY BUTTE FLD' New line: '13020 0 1 04CA Gray Butte Field' or Old line: '1 940 0 1 0NY7 Murphys Lndg Strip' New line: '1 940 0 1 0NY7 Murphys Landing Strip' c) Same name, but marked as closed in apt.dat when ourairports says "closed": Old line: '1 250 0 1 03VA Whipoorwill Springs' New line: '1 250 0 1 03VA [X]Whipoorwill Springs' d) Take "new" names from ourairports Old line: '1 18 0 1 04W Keech\n' New line: '1 18 0 1 04W Field of Dreams Airport\n' What changes (0 or a/b/c/d) do you think are useful and will be accepted (also by developers working with apt.dat for FlightGear "side projects" like Maps, Launchers etc.) ? Cheers, Yves -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trying to get more performance out of the 3D clouds!
2011/12/8 Mathias Fröhlich wrote: > The cloud code changes its internal data structures in the draw call? > Or are these lists per context data structures? > This is kind of proboblematic for two reasons: > 1. draw happens in paralell in all configured multi viewer contexts. So I fear > concurrent modifications on a shared datastructure. > 2. The eyepoint on different cameras can be different which might give > different > results in sorting I guess? > While the second point might not happen in current flightgear implementations, > I still think that we should try to keep this in mind. Good point, and one I'd not thought about before. > And, more performance related. > I see that single quad that is used to draw the clouds. Then we have this loop > over all the sprites. So what the driver does is on every new quad there is a > new geometry setup that happens. And this is one of the expensive things in a > driver. Mostly this is the best optimized code path since this happens often, > but still it is relatively much work on the CPU to teach the GPU that there is > a new bunch of geometry to render. A rule of thumb that really depends on the > kind of shaders that are used and how much fragments are renderd, but for our > average models, including the clouds I think, It will take about the same time > to render one quad or a single bunch of 1000 quads. It's just the GPU is so > fast and the geometry setup on the CPU dominates. > > So having a huger array of vertex attributes done with one draw command > consisting of only one osg::PrimitiveSet could improove rendering speeds. > Sure this needs some more infrastructure to change this at the right time in > the frame. Also this is concurrent with the depth sorting we have discussed > before. So the question is what is the right compromise then? Having > relatively huge bunches of geometry helps rendering and osg's sorting speed. > But huge bunches might give problems with the sort order blending in the wrong > order. Which is BTW the kind of artefact that somebody pointed out on a recent > X-Plane screenshot. So we are currently better, but still, we need to get back > to 'real time' ... So it sounds like I should create a single geometry per cloud, rather than per-sprite? If I'm doing that I might as well scale the geometry when I create it, rather than relying on the shader to do so for me. The major problem I can see with this is performing the billboard rotation. To do that in the vertex shader, I'll need to pass in the center of each sprite. However, I wonder if I can make this more efficient by doing it outside of the shader, and a) performing the same rotation on each sprite within the cloud b) only performing rotation when required, rather than per-frame. Presumably I could retain the manual sorting we do at present, and simply sort the geometry itself. Or is that better left to OSG? In fact, this may remove most of the function from the shader itself! > How much ShaderGeometry's do we have? One per cloud? > For me this also raises the question of reproducible clouds. If we have > multiple independent viewers in the future, we need to draw the same clouds on > each with a bare minimum of communication. So, what is needed to generate the > exactly same cloud. May be an initial seed for the random number generator, a > position and a size? I need to check, but I'm fairly sure we use an initial seed already. > We may need to identify such a set of parameters and may > be we should have a peudo loader for osg producing this kind of clouds from > these parameters. The you would be able to load and use these clouds from > fgviewer and see isolated statistics about the draw/cull whatever steps. This > might also help in understanding what is going on. We already have export/import methods, though I've never used them in anger! Certainly using fgviewer would be an excellent idea. > If I do not respond to list mails when you need some response, fell free to > contact me directly. I just miss some mails every now and then ... Thanks for the offer. Will do. -Stuart -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
