Re: [Flightgear-devel] Simgear/ShivaVG compile fails on windows
Thomas wrote:
Am 2012-11-05 18:30, schrieb Vivian Meazza:
I'm using the Nasal API - it used to all work before today's update.
Can't really see what to change
Are you using canvas.setColorBackground(r, g, b, a)
I have this:
m.canvas.addPlacement(placement);
m.canvas.setColorBackground(0.36, 1, 0.3, 0.02);
which is a direct copy from
http://wiki.flightgear.org/Canvas_HUD
and is there a function
setColorBackground: func () { me.texture.getNode('background',
1).setValue(_getColor(arg)); me; }
No - there isn't one in
http://wiki.flightgear.org/Canvas_HUD
in your Nasal/canvas/api.nas?
Are there /canvas/by-index[i]/color-background/[red,green,blue,alpha]
nodes in your property tree or just a single
/canvas/by-index[i]/background
string property per canvas?
And no other references to color-background
Vivian
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG Steering Committee :-) Was: Stand-alone ATC client and Canvas
Martin wrote: On Mon, Oct 08, 2012 at 09:33:36PM +, Martin Spott wrote: Well, but the wording You are advised not to start working on anything directly related to this is highly inappropriate. Apparently someone has completely failed to understand the topic. It came to my attention he's a Wiki moderator and it looks like he enjoys abusing his powers to enforce advice against development ideas which don't conform to his personal favourites. This is sad, very sad, But who is he, and can he be reminded of the error of his ways, or be removed? Vivian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim and documentation
James wrote, -Original Message- From: James Turner [mailto:zakal...@mac.com] Sent: 05 October 2012 11:54 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] YASim and documentation On 5 Oct 2012, at 11:32, Alexis Bory wrote: When you do that code reading (as I do it currently for the engines) it appears that at least some crucial parts are not such a woodoo and it appears that adding features to improve the FDM capabilities is not such a crazy idea. For that we would only need to understand precisely the whole existing system/code and document it, then design our features and get help from a C++ expert for the writing. We can do that. Just to say, there are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions. Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :) So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. Suggestions for that means in practice, are most welcome! Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working. Andy is still around, but inactive. It might be possible to run stuff by him once in a while. But I would in general worry about mucking about with such a critical part of FG, unless I was very sure about what I was doing. Vivian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound and HSI problems with Lightning
Alan wrote AJ With Debug-Browse Internal Properties I see that the properties instrumentation/heading-indicator are stable, but instrumentation/heading-indicator-dg are changing rapidly. When I press the Push Source button the HSI stops rotating and indicates North, but this does not agree with the RMI or Magnetic compass, which are in agreement with instrumentation/heading-indicator/indicated-heading- deg. The chirps in the engine sound exist in other aircraft to a greater or lesser degree. e.g. the Sea Vixen. With most it is barely audible, but with the Lightning and my TSR2 development it is very obtrusive. Hope this helps. Alan -Original Message- From: AJ MacLeod Sent: Friday, October 05, 2012 6:03 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Engine sound and HSI problems with Lightning On Sat, 29 Sep 2012 10:59:18 +0100 Alan Teeder wrote: The second problem is that the HSI spins continuously until the “Push Source” button at the bottom of the instrument is pressed. Pressing this button twice results in rotation once again. Hi Alan, I've made a few minor changes to the Lightning sounds and sound XML - sadly none of them fix the main issue you reported (it seems to be a wider FG issue as you say) but the warnings about stereo sounds are addressed. Vivian will hopefully be committing these changes at some point when he gets a moment - to my ears the startup sequence sounds a little bit better though if I had the time I think I'd do it differently... feel free to improve it in the meantime! The HSI issue on the other hand I don't see at all here so not sure what might be causing that unfortunately. Does anyone else have the same issue? AJ's update has been pushed. The stereo warnings should have gone away. However, I'm hearing noise spikes in the engine sound. I'm also seeing this error: ALC Error (sound manager): Invalid Enum at context creation. I'll try to analyse the sound to see if the noise spikes are present in the sound file. I can see no problem with the HSI either on the panel or in the property tree. HTH Vivian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Gitorious] Activity: fredb pushed 1 commits to nextnext...
James wrote On 27 Sep 2012, at 09:40, James Turner wrote: Here the aircraft model appears 5 sec before the scenery, I'm seeing this intermittently too, I think it's related to ThorstenB's clean-up of the scenery init process. I'll let him comment how likely that is. then the throttle is wide open and the brakes are off despite the settings in the ~.set file, so the aircraft races down the runway. That's bad enough on an airfield, but it really screws up the start on a carrier. I'm not seeing that with the aircraft I test regularly - Bravo, c172 and 777. I also didn't see it with the Vulcan or CRJ1000 yesterday. It's possible it's related to my moving the FGcontrols init, but a bit research on if it's aircraft specific, and if so, why, would be helpful. I've just pushed some changes that should help this (or not!) - please test and let me know if you see any improvement. I've just pulled and built SG/FG/FGData. The start looks fine now, after only a short test. However, I only see incomplete language resource on the splash screen during the start sequence, and the spinner starts about halfway through. I don't see any of the old messages. I will do some more testing to try to ensure that this initial test result isn't aircraft-dependent. Sorry about the tardy reply - I've been away on a short break. Good to come back and find it fixed. Vivian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Gitorious] Activity: fredb pushed 1 commits to nextnext...
James wrote On 26 Sep 2012, at 21:35, Gitorious wrote: commit ba8190d97f62b60f5b040ae332cddef9c607048d Author: Frederic Bouvier fredfgf...@free.fr Date: Wed Sep 26 22:34:48 2012 +0200 Close Sqlite3 database *before* trying to delete the file. Will avoid a segfault when the schema is out of date Thanks Fred! Apparently Unix is more tolerant of this :) After 2 days of struggle here, and thanks to Fred, I now have a working FG under Windows. But it's a bit of a mess, o say the least. I suppose/hope that it's work in progress. Here the aircraft model appears 5 sec before the scenery, then the throttle is wide open and the brakes are off despite the settings in the ~.set file, so the aircraft races down the runway. That's bad enough on an airfield, but it really screws up the start on a carrier. We seem to have a problem with the nasal start order as well. This looks like someone is mucking with something they don't really understand. Let's hope not. Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata trouble
Martin wrote: Alan Teeder wrote: Twice I left it running overnight, but it failed both times after several hours during the fgdata clone. Which server do you clone from ? If you don't already do so, then you should consider fetching the initial clone from mapserver and to change the remote origin afterwards. The fact remains that I believe that the current fgdata is too large and is not fit for purpose. The need to re-organise it exists now, as it did last year. Perhaps you, or someone else, could comment on that. Indeed, the current evil is asking for a *clever* solution but every of those I've seen so far (at least most of them) had been ignoring one or another quite relevant context and I think we're not well-advised to embark on yet another significant evil to get rid of the current one. I don't know the 'perfect' recipe either. My favourite would be to keep just the default Cessna in the base package and to move all the other aircraft into one single, separate repo but as far as I remember, this plan doesn't have much support (for various reasons, I guess). Yes, that would be an obvious plan, but the elephant in the room is that it is the Aircraft folder which contains the bulk of the problem, so as you said, we swap one evil for another. I suppose if there were an answer to this problem we would have implemented it by now. Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
Syd wrote: -Original Message- From: syd adams [mailto:adams@gmail.com] Sent: 20 September 2012 16:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nav-cache would any of these changes have affected the Equipment/map performance ? I get a lot of disc activity now while panning the map ... and it takes 10 -15 seconds now before it refreshes , and thats with every mouse drag.This only used to happen when zooming out , and the refresh time was much shorter... First time I used it, it took 10 mins to zoom out to the full extent, but once the cache was established it refreshed very quickly. Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] license
Thorsten wrote: -Original Message- From: Renk [mailto:thorsten.i.r...@jyu.fi] Sent: 06 September 2012 10:47 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] license There remains this strange discrepancy between what people are outraged about and what could potentially stand in court. snip * violations of GPL because the source code is not really available. So we're really down from fraud to the availability of source code on a website - and if FlightProSim would make all the code easily available by simply cloning the Flightgear repositories, you'd all be happy because they are now in complicance with GPL? Somehow I don't think so, somehow I think this isn't what upsets people. Even that is available, or used to be. I downloaded a copy, which AFAIKS was just our source code, despite their claims to have modified it. Qs you say - that's how it is. I think we ought to try to avoid having this discussion every 12 months or so, covering the same ground, and coming to exactly the same conclusion. Caveat emptor. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D models import webform in production.
Fred, -Original Message- From: Frederic Bouvier [mailto:fredfgf...@free.fr] Sent: 18 August 2012 12:23 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] 3D models import webform in production. I sent model updates to fgf...@stockill.org a while ago. Is there any chance they will be inserted in the database ? Nobody monitors this address anymore ? My model is made of 3 xml, 3 .ac and 2 textures . How can I submit it ? And effects and shaders ? It came to me that a future-proof solution would be to allow any number of files of any kind, maybe with a check on a set of allowed format/extensions. BTW: here is the list of modified models in the base package that are not in the database : - Golden Gate bridge : http://scenemodels.flightgear.org/modeledit.php?id=78 (with fixed geometry by the way. The one in the database got corrupted I don't know how). - Bay bridge west : http://scenemodels.flightgear.org/modeledit.php?id=75 - Bay bridge east : http://scenemodels.flightgear.org/modeledit.php?id=77 - Airport beacon : http://scenemodels.flightgear.org/modeledit.php?id=34 - Airport light pole : http://scenemodels.flightgear.org/modeledit.php?id=359 I think Gijs modified the Alcatraz model : http://scenemodels.flightgear.org/modeledit.php?id=74 I've been trying to contact Jon for a week now - no luck - perhaps he's on holiday. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D models import webform in production.
Fred wrote: -Original Message- From: Frederic Bouvier [mailto:fredfgf...@free.fr] Sent: 18 August 2012 15:23 To: Olivier; FlightGear developers discussions Subject: Re: [Flightgear-devel] 3D models import webform in production. It came to me that a future-proof solution would be to allow any number of files of any kind, maybe with a check on a set of allowed format/extensions. It'll be hard to parse and test any number of files formats/extensions. Currently for 3D models we have approximately 30 to 40 tests (on the thumbnail, the textures, the XML, the AC3D...) running for each submission, and a visual check, to make sure that what is committed is right and not putting into danger our shared infrastructure. Don't know how we would cope with a infinite number of format. Not an infinite set of formats. A fixed/allowed number of format. Say : . AC3D .AC (AC3D) to be consistent . OSG (several variants) . PNG . JPG . RGB . EFF (effect) . FRAG/VERT/GEOM (shaders) . XML You cover a wide range of needs if you allow any number of files in this set of formats Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dan Freeman and ProFlightSimulator
Gene wrote -Original Message- From: geneb [mailto:ge...@deltasoft.com] Sent: 14 August 2012 22:36 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Dan Freeman and ProFlightSimulator On Tue, 14 Aug 2012, Ivan Abolit wrote: I am not sure if this is the right forum for my topic but I feel some one else in the flight simulator world should be aware of this. I ordered the 4DVD Edition of ProFlightSimulator from the company's website on 4 April 12; paid $150.00 CAD for both the product and shipping by credit card, and received the product shortly after. Unfortunately you got rooked. As far as we've been able to tell, he's selling a very old copy of FlightGear (v1.9.1 I think) as well as a number of free or public domain publications. I would really, really, really like to get my hands on those disks you got - I want to see first hand what kind of crap he's been throwing at people. Is there any chance you could copy them for me? I'd be happy to reimburse you for media and postage costs. Thanks and I'm sorry to hear you've been ripped off. If I were you, I'd contact my credit card company and have the charges reversed. g. Here's what they claim to be their source code that I got from their website a while back: http://www.abbeytheatre2.org.uk/flexshare/flightgear/FlightProSim/ AFAIKS it's our source code unaltered. It ought to install and run, but I never checked it as I hadn't got the right data handy. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog for Release 2.8.0
Torsten wrote: -Original Message- From: Torsten Dreyer [mailto:tors...@t3r.de] Sent: 13 August 2012 20:32 To: FlightGear developers discussions Subject: [Flightgear-devel] Changelog for Release 2.8.0 Hi everybody, we are very close to our release date, just a few days left until we hopefully ship our latest-and-greates-ever FlightGear version. Please check the changelog at http://wiki.flightgear.org/Changelog_2.8.0 and make sure every new feature is noted at a prominent place there. These are not only core features but also new/updated aircraft, scenery improvements, usability changes - whatever made FlightGear better since the last release. The changelog is often copied by online media and might help to attract new user, so please help creating a persuasive advertising for FlightGear 2.8.0! My reaction was: is that all?. I haven't been following developments all that closely over the past few months as trying to keep up with Fred has taken much of my time, so perhaps it is. Surprised me though. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog for Release 2.8.0
Curt, I'm sure we could do a pretty good screenshot of Vinson. I'll see what I can come up with. Vivian From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 14 August 2012 15:47 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Changelog for Release 2.8.0 On Tue, Aug 14, 2012 at 9:43 AM, Frederic Bouvier wrote: By the way, maybe we could contribute few screenshots (the best) to the OSG new website : http://www.openscenegraph.com/index.php/gallery/screenshots For the moment, FG is absent in this page. How about a cool Rembrandt shot showing some nice lighting or shadows? The Vinson is pretty cool although I don't know how well that shows up as a screenshot? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog for Release 2.8.0
Curt, Here's a few: https://www.dropbox.com/home/Public/Vinson Any good? I can soon rattle up a few more. Vivian From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 15 August 2012 16:19 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Changelog for Release 2.8.0 On Wed, Aug 15, 2012 at 10:13 AM, Vivian Meazza vivian.mea...@lineone.net wrote: Curt, I'm sure we could do a pretty good screenshot of Vinson. I'll see what I can come up with. Vivian Hi Vivian, I'd love to have a couple nice Vinson shots -- at least one with shadows, and at least one with the new deck lighting. I keep wanting to make some new carrier ops videos -- watching the aircraft pass through the deck lights and get lighter/darker is subtle and happens quickly, but is pretty cool. Also watching the shadow on landing is also pretty cool, as is seeing the spinning radar dish shadows cast across the deck ... Curt. From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 14 August 2012 15:47 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Changelog for Release 2.8.0 On Tue, Aug 14, 2012 at 9:43 AM, Frederic Bouvier wrote: By the way, maybe we could contribute few screenshots (the best) to the OSG new website : http://www.openscenegraph.com/index.php/gallery/screenshots For the moment, FG is absent in this page. How about a cool Rembrandt shot showing some nice lighting or shadows? The Vinson is pretty cool although I don't know how well that shows up as a screenshot? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog for Release 2.8.0
Curt, Never easy is it? This might work: https://www.dropbox.com/sh/js2hm48d5amsjzy/ediTgCHinD/Vinson Vivian From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 15 August 2012 16:50 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Changelog for Release 2.8.0 Oh, that link doesn't reference your name so it doesn't work (I get my own public folder) :-) On Wed, Aug 15, 2012 at 10:42 AM, Vivian Meazza vivian.mea...@lineone.net wrote: Curt, Here's a few: https://www.dropbox.com/home/Public/Vinson Any good? I can soon rattle up a few more. Vivian From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 15 August 2012 16:19 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Changelog for Release 2.8.0 On Wed, Aug 15, 2012 at 10:13 AM, Vivian Meazza vivian.mea...@lineone.net wrote: Curt, I'm sure we could do a pretty good screenshot of Vinson. I'll see what I can come up with. Vivian Hi Vivian, I'd love to have a couple nice Vinson shots -- at least one with shadows, and at least one with the new deck lighting. I keep wanting to make some new carrier ops videos -- watching the aircraft pass through the deck lights and get lighter/darker is subtle and happens quickly, but is pretty cool. Also watching the shadow on landing is also pretty cool, as is seeing the spinning radar dish shadows cast across the deck ... Curt. From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 14 August 2012 15:47 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Changelog for Release 2.8.0 On Tue, Aug 14, 2012 at 9:43 AM, Frederic Bouvier wrote: By the way, maybe we could contribute few screenshots (the best) to the OSG new website : http://www.openscenegraph.com/index.php/gallery/screenshots For the moment, FG is absent in this page. How about a cool Rembrandt shot showing some nice lighting or shadows? The Vinson is pretty cool although I don't know how well that shows up as a screenshot? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master, updated. 79e3dccf888d19a5cfa8372a5b6b592c0505f06d
Fred -Original Message- From: eric Bouvier [mailto:fredfgf...@free.fr] Sent: 06 August 2012 11:23 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master, updated. 79e3dccf888d19a5cfa8372a5b6b592c0505f06d Hi Vivian, - Mail original - De: Flightgear-commitlogs mar...@hypersphere.calit2.net À: flightgear-commitl...@lists.sourceforge.net Envoyé: Lundi 6 Août 2012 12:14:14 Objet: [Flightgear-commitlogs] FlightGear Base Package branch, master, updated. 79e3dccf888d19a5cfa8372a5b6b592c0505f06d The branch, master has been updated - Log - commit 79e3dccf888d19a5cfa8372a5b6b592c0505f06d Merge: e610e85 ca39a67 Author: Vivian Meazza Date: Mon Aug 6 10:28:22 2012 +0100 Merge branch 'master' of gitorious.org:fg/fgdata into work You could avoid this long commit log (and salvage the commit tree as James once explained) if you'd do : git rebase origin/master after pulling and before pushing. You may need to do git stash // before rebase followed by git stash pop // after rebase if you have uncommitted local mods in your tree I pulled, and did a rebase before pushing, but my stuff came halfway through yours chronologically, and seemed to have got tangled up with yours. At least, TortoiseGit seemed not to be able to do it any other way. At least it's trying to rebase nowadays. And if I had any uncommitted changes, I would have stashed, but I never have any in my master clone. Btw - what is the practical application of all that clever stuff? Any chance of a review of FGRun to include some of the new items? Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ideas for terrain shader structure in 3.0
-Original Message- From: Stuart Buchanan [mailto:stuar...@gmail.com] Sent: 30 July 2012 09:35 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Ideas for terrain shader structure in 3.0 On Fri, Jul 27, 2012 at 8:43 AM, Renk Thorsten wrote: Since we usually don't have roadmaps and things, I thought I might try to put this up for discussion early on. I've been experimenting with a partially procedural texturing approach, and I think this is the way to go forward, the outcome looks very convincing. My experiments are coded within the atmospheric scattering framework, but do not require it, and since all code is the fragment shader, it'd be straightforward to port things also to the default rendering scheme or to Rembrandt, if so desired. After some thinking, it seems easiest to me to organize the terrain shading scheme in such a way that one default shader handles most of the visible terrain and the exceptions are declared as effects. I'm all for the idea of having a single terrain uber-shader, as at present we have too much of a mish-mash of effects. If we do down this route, I think we really need buy-in from all the people modifying materials to ensure that we apply it to the full set of material definitions and clean up the unused effects that at then replaced. I think that is you, me, Vivian, Emillian and Fred (urban shader). Anyone else? I think the current approach of the uber-shader-deferred is a good one, the base effect defines everything, and specializations of the effects can switch individual features on/off. I'm not sure at this point what to do with agriculture. Large fields have a really bad tiling problem, and variants of the crop shader technique (which I haven't studied yet) might address this. But this would completely screw the object placement masks which require the underlying texture to be fixed rather than dynamically generated. So this should be discussed, it isn't appealing to get some terrain down to 10 cm resolution and other terrain at 2 m, but I like the placement masks very much. I'm very keen on the placement maps myself, but they are fundamentally incompatible with the crop shader, as the placement information is required well above the shader layer. It'd be really cool to be able to specify a few more parameters in materials.xml to be passed as uniforms - for instance we could then generate custom heightmaps for the terrain rather than hard-coded ones. Since I use tiling-less noise functions, we could easily get a 1cm scale heightmap for runway textures for instance, and we could give sand dunes same larger wavelength noises than rock. I can do this fairly easily. As mentioned previously, I think I'd want to handle this as a generic framework allowing properties to be defined in the materials.xml file that are then passed through to the effects and can be used in the parameters section. I'll certainly do what I can to help this one along. However, I'm not clear how this all ties in with the Rembrandt project. Are we in danger of having to tear it all down and starting over? I, too, am a fan of the placement masks: they have made a significant improvement in the realism of our scenery. On the other hand, I have long since abandoned using the crop shader. Let me know what it is you think we need. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reduced tiling (was Re: Shader menu structure)
Hey, Curt AND Martin kidding around! Is this a first? J. Well that's a weight off my mind. Good. Back to preparing the goodies. Vivian From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 12 July 2012 21:36 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reduced tiling (was Re: Shader menu structure) On Thu, Jul 12, 2012 at 3:28 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Please, please, don't change the plan now! Let's get the release out of the door as planned. There are lots of goodies in the pipeline - but that's exactly where they are - in the pipeline. They might or might not be ready for release in 6 months. Martin and I were kidding around ... there's no change in the official release plan. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reduced tiling (was Re: Shader menu structure)
Please, please, don't change the plan now! Let's get the release out of the door as planned. There are lots of goodies in the pipeline - but that's exactly where they are - in the pipeline. They might or might not be ready for release in 6 months. Vivian From: Olson [mailto:curtol...@gmail.com] Sent: 12 July 2012 17:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reduced tiling (was Re: Shader menu structure) On Thu, Jul 12, 2012 at 10:53 AM, Frederic Bouvier fredfgf...@free.fr wrote: ..this kinda blending looks so good it should IMHO go into the current release, even if it means delaying the release. Delayed 6 month ? We could do a release now and another release in 6 months? :-) Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear developers discussions flightgear-devel@lists.sourceforge.net
Thorsten -Original Message- From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi] Sent: 26 May 2012 18:21 To: FlightGear developers discussions Subject: [Flightgear-devel] FlightGear developers discussions flightgear- de...@lists.sourceforge.net Done. Could do with some more refinement, but it works. If you input speed-kt, then position updates are ignored and positions are calculated from input speed and pitch. Here are the patches: http://dl.dropbox.com/u/57645542/0001-SG%20Make-Models-move-with- headi ng-and -speed.patch http://dl.dropbox.com/u/57645542/0001-FG-Make-models-move-with- heading -and-s peed.patch http://dl.dropbox.com/u/57645542/0002-FG-Calculate-horizontal-and-vert ical-s peeds.patch Next, I'm going to allow input of vertical and horizontal speeds (fps) as well. Seems to have very little impact on framerate, but it involves a for loop (and you know how much I like those), so there are limits. Great - thanks! I'm travelling at the moment, so I won't be able to look into this until a week from now, but I'll test this as soon as I am back. We won't need it for many clouds (usually less than 10, for pure Cirrus skies still less than 50), so I don't see any large number coming up (of course there may be non-weather applications...) * Thorsten The patches have been moved to https://www.dropbox.com/home/Public/FG-Models-Movement They are sequential so you will need to apply each in turn FG to Flightgear SG to Simgear. I've tested as far as I am able - seem to work. I hope you can make use of them. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Thorsten
(Even if this works fine, please do not commit yet, I am not 100% sure
that I didn't create an instability somewhere).
Turns out I broke at least the visibility interpolation - to restore it,
uncomment line 726 in Nasal/local_weather/local_weather.nas
if (vis 0.0) {setprop(lwi~visibility-m,vis);} # a redundancy check
(there's a better way to deal with this, but for the time being that seems
to
solve the problem).
I have tested using only the test tile so far. The time spent in events is
dramatically reduced to around 70ms vice 210ms. There remains some odd
cyclical frames coming in, but the results are broadly in line with Basic
Weather. The details are here:
http://dl.dropbox.com/u/57645542/Adv-Weather-data.png
I tried some airborne tests using the test tile, and the visual results are
satisfactory, again comparable to Basic Weather. The spikes in framerate can
be measured, but are not too visually intrusive. Like you, I have been
unable to identify the source so far.
I extended the test by setting all settimer loops to 0.0. There was little
measurable change in either frame rate or stability.
I'm now going to test with more representative weather.
Vivian
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Thorsten I have tested using only the test tile so far. The time spent in events is dramatically reduced to around 70ms vice 210ms. There remains some odd cyclical frames coming in, but the results are broadly in line with Basic Weather. Okay, that's good news. I'll continue working along these lines then, although I expect that the rest is just cleanup work which will not gain that much performance any more. The biggest issue is that in this version the movement of the Cirrus clouds is broken, and under some (somewhat unusual) conditions that would show (since tiles themselves still move, there'd be a pileup of clouds in a given location in strong winds if the aircraft doesn't move much). But it seems the quadtree code to move them is simply too heavy - either a lighter scheme is needed, or some other solution. What's the prospect of adding hard-coded movement to models loaded from Nasal? AI models defined on startup can have a heading and an airspeed and these can even be changed at runtime - just models loaded from Nasal at runtime don't seem to have that feature, and so they require per frame position updates from Nasal. Looks doable - but then everything does until the difficulties become apparent :-) I'm just doing a little experimentation here now on that. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Thorsten Not that we're there yet Heiko and Vivian, please try the following version and let me know if this improves anything. If possible, do all tests with the weather tile type 'Test' (that has no randomness in the cloud configuration selection, so it delivers a fairly reproducable situation in terms of cloud count). http://users.jyu.fi/~trenk/files/advanced_weather_v1.47.tgz I've tested this in the default shading with the ufo in window mode without expensive shaders running so that I got a high framerate. I've seen framerates of 65 fps with max frame delays of order 15 ms (which seems okay so far). Every few seconds there was a prolonged frame of 30 ms (still within my design targets, but suspicious). I've tested the hypothesis that the only loop not running per frame now causes this (the tile management loop) and switched it off - the problem persisted unchanged, so to my ability to test this feature was not caused by any Nasal code running (it might still have to do with Nasal overhead like GC or so, that I couldn't establish). Every 30-40 seconds I had a freak-frame of 150 ms duration coming in. To test what is going on here, I disabled all running Nasal code by clear/end - the problem persisted. To my ability to test, this is also not caused by running Nasal code but by something which I couldn't identify. I've subsequently tested the visual impression of flying with an aircraft rather than the ufo and took the Harrier for a spin through 6/8 cloud cover (one of the low pressure scenarios). It certainly felt smooth to me, although the framerate and frame delay readings were a bit more jittery than with the ufo. So, I'd like to know if that helps you as well and if we're on the right track here. (Even if this works fine, please do not commit yet, I am not 100% sure that I didn't create an instability somewhere). Testing underway, Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Thorsten just a quick note to this interesting thread ... its elsif in nasal , not elseif ... no e Thanks. That would explain it ;-) I hope you're not suggesting that C++ is always slower than Nasal? :-) Pascal summarized it nicely - we already have ported the important stuff to C++, so what remains in Nasal is a small fraction of the total performance cost and we gain little as such by porting that as well. I'm sure the loop computes even faster in C++, but I don't have the means to measure that. It'd be intersting though to see how much the difference actually is. It was just a couple of mouse clicks to remove the unused vars and change to elsif. The best than can be said is that if I look really closely I can convince myself that there is less time spent in Events - from about 210 ms down to 195. The worst that can be said is that it looks a bit prettier. Improved frame rate? Possibly. It's just tinkering on the margins, as you said. I didn't do more than that - since it was more than a couple of mouse clicks, and I expect that we will gain much more by removing redundant code so that GC has less to do. Just to remind ourselves, Andy Ross (the author of Nasal) says: Performance is not a design goal. Nasal isn't especially slow. Early benchmarks of the garbage collector showed it as faster than perl's reference counter, and its number crunching performance is on par with python. But in all cases, simplicity, transparency and a sane feature set are preferred over speed. It is a scripting language that is an abstraction layer over C, so we might expect it not to be as quick as code written in directly in C++. And as we know, we're running into GC issues. Andy also says of GC: The current implementation is a simple mark/sweep collector, which should be acceptable for most applications. Future enhancements will include a return early capability for latency-critical applications. The collector can be instructed to return after a certain maximum delay, and be restarted later. Fancy items like generational collectors fail the small and simple criteria and are not likely to be included. I don't think it was a design aim to handle time-critical stuff like Advanced Weather: that it does is a bonus. Were the future enhancements ever implemented? I don't recall. Porting to C++ might be a little faster, but it might also be the only way to avoid GC issues. Not that we're there yet: here with all settimers() set to 0.0, I can get acceptable framerate and stability. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
Thorsten Conclusion: don't try to optimise, particularly for a poor system - you might make it better for that system, but more likely you will make it worse for everyone else. Judging by framerate comparisons with people in the forum, my system is still somewhere in the upper third - many people have to live with less. Judging by user requests and comments, more than 90% want higher framerate out of the system by any means, you represent a minority of users who would be willing to sacrifice framerate for smoothness. With your scientific background you should know better than cherry-picking that statistic. Those on the forum are a self-selected minority of our users. We have no idea what our users out there are using, neither hardware nor OS. We don't know if they have tried Advanced Weather and abandoned it, or put up with stuttering, or never tried it. Anecdotally, there are plenty of complaints about stuttering, and AFAIKS these are really only apparent with Advanced Weather or Concorde. Most of us are happy to see Rembrandt or lightfields with anything resembling 20 fps. So, just who is that 'everyone else'? And for whom do we optimize? You're basically saying I should optimize things for you - but that would make it worse for everyone else not running a high-end system. No I'm most definitely not. What I'm saying is that by optimising for a subset of users, you run the risk of sub-optimising for the rest. Right now, with Advanced Weather we have a weather simulator with a FlightSim attached. We're spending 10 (yes 10!) times as long in the Events Sub-module with Advanced Weather than in Basic, and 5 times as long as we spend in Flight. That'd probably be because Advanced Weather does ~10 times more complex calculations than Basic weather... And I'm not surprised that it takes more than flight either - flight is comparatively cheap, that ran with decent accuracy 10 years ago. To compute a non-local environment (i.e. that knows that conditions 'here' are different from conditions 'there') is quite a bit more expensive and we could not do that 10 years ago. As for your comment, yes, that's quite true - that's just how the problem is. Teaching thousands of clouds where convection is, or how to flow over terrain obstacles is expensive, even if you do it schematically. That's what's needed to give you semi-realistic distributions of clouds. If you're happy with just clouds in the sky, that's cheaper, but not what Advanced Weather is for. I think Advanced Weather is good. I'd like the opportunity to exploit my (fairly - it's getting a bit long in the tooth now) high end system to enjoy it - not have to put up with an experience that is not as good overall as basic weather. Writing data to the Property Tree is bad. This one is not evidence based That's evidence based (I have done some testing a while ago just how long it takes) - it's currently minimized in my code, but the tree is the interface between menu, C++, Shaders and Nasal, so ultimately some stuff has to be written or read. To be honest, I think there are design difficulties with Advanced Weather. There should only be one loop - the update loop - running at main frame rate which activates/deactivates the various sub-modules as required. I think I have done enough work here to demonstrate that this is a viable way forward. The current design with multiple loops * has robustness (a problem in one submodule doesn't crash the whole system) * has good framerates (which is an issue for the majority of us) * is easy to debug (as it doesn't hand over too many parameters between iterations) Unfortunately, Advanced Weather can and does crash Fg here. I haven't looked into it properly - but there's no obvious reason atm. If running the individual loops at main framerate solves your smoothness problems, then we can start for instance making the loop timers user- configurable. Sacrificing framerate for smoothness is a compromise you might be willing to make, but I am not, I need the framerate. Yup - with bare fg I can see over 200fps (not at KSFO of course). I can spare a few for smoothness. I agree that for your problem, your solution is the correct way forward - but my problems are different from yours. So what do we do about that? For a start we can try to make the Nasal better, I think that might help a bit. I spent an hour or so picking over your code. So far I've found: 88 declared but unused variables 47 declarations of the same or similar variables 427 instances of else if instead of elsif 100 instances of I = I + 1 instead of i+=1 Numerous examples of variables declared inside for loops, and some of those are inside other for loops Variables declared inside condition statements. Nasal is tolerant of those kind of things where other languages/compilers would at least warn you, and might throw an error. Nasal might even optimise them away, I don't know.
Re: [Flightgear-devel] Sea color
Alan On the subject of frames rates I have a couple of questions. 1. Is there a mechanism for odd and even frames (or even frame.1,frame.2,frame3...frame.n for a once in every n frames task) to be run separately, or is everything that is scheduled at a specific rate executed one go? 2. Is there a mechanism for making the core - fdm, afcs, equations of motion etc. run at a higher priority than the rest of the simulation? If you go to the menu item Debug Monitor System Performance you will see which sub-modules run at main frame rate and those which run at 2 x main frame rate. Items can be made to run at greater than main frame rate, but not at less, easily, and I guess more sub-modules could be added to the 2x list with more effort. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
Thorsten Testing continues Concorde has of the order of 6000 lines of active code, and yes, it displays exactly the same discontinuities as Advanced Weather (approx. 10,000 lines of code). So far, I have not found any other examples. Just to idly continue my list - the A380 has in excess of 8000 lines of Nasal, the 777 has about 3500 lines, ... I don't know what you usually fly, but the modern, more complex aircraft tend to accumulate a lot of Nasal when aircraft makers start to care about systems. A380 - broken Mig 15bis - broken B777 - works - framerate is adversely affected and stutters a bit, but acceptable. Notably, it increases the time spent in the Events sub-module, but only by approx. 10ms, or 2 times. I have just tried to start Flightgear without the Advanced Weather module loaded, disabling all weather, using the ufo to minimize any Nasal impact. The bottom line is, no matter what I do, as soon as I actually move around I always get spikes in the frame delay raging from 30 to 45 ms, i.e. I never have a smooth framerate even if I throw out basically everything. The ufo is far from a Nasal-free zone. Compare it with the Seahawk? It has no pooh traps. So I can't ever get to the smooth state you apparently have on your system, which means I can't meaningfully test what makes a difference. I can only suggest that you try disabling the loops I suggested and play with the loop timings. If you think letting loops run per frame helps, by all means try - with the possible exception of the tile management, I'm fairly certain the rest can run per frame without bad side effects - the times are chosen to give the best performance on my system, but this may not work the same way for you. Nil weather is very smooth in basic weather with shaders on but veg, obj, and bldgs off. Tried METAR. Basic weather now shows some stutter. Now set all Advanced Weather settime() to 0.0 and retest with METAR. Wow!!! Improvement, not as good as Basic Weather , but much better. Worst fps is stable at 24, av. is still unstable. That's the good news - the bad news is that Emilian does not see an improvement. Conclusion: don't try to optimise, particularly for a poor system - you might make it better for that system, but more likely you will make it worse for everyone else. If you can find a working combination, I'll make it an option in the GUI and see if it helps others. Yes, I was around when Nasal was introduced to Flightgear. Up to now it's been a few 100s of lines, not many 1000s. We have long been aware that GC could cause problems, but haven't fixed it because the effects weren't too bad while Nasal was small and framerates were low, and we had no obvious solution. You know what really bugs me? The direction fingers are pointing. Well, as Gene Buckle pointed out: if you point a finger, then 3 are pointing right back at you. We have an implementation of Nasal which dumps all the GC into a single frame and is apparently sensitive to the total amount of code, regardless if the code is actually run or not. This fact has historically not been widely advertized or explained. That turns out to be a problem. We were aware that GC was a problem. We also avoided dumping nasal into the Nasal folder because everything in there runs. Too much stuff is either buried in obscure Wiki pages or are simply part of the hive memory; there are fewer worker bees than there were and the memory grows weaker. The way this usually comes across is 'Advanced Weather causes stutter'. But it actually doesn't really (or at least that remains to be shown) - what causes stutter is mainly the GC, and Advanced Weather just happens to trigger this. The range of suggested solutions in the past included almost everything, from avoiding Nasal to porting code to Nasal to hacking around the problem to loading things on-demand - except fixing the actual cause of the problems. To be honest, I think there are design difficulties with Advanced Weather. There should only be one loop - the update loop - running at main frame rate which activates/deactivates the various sub-modules as required. I think I have done enough work here to demonstrate that this is a viable way forward. I don't honestly know how complex code to collect garbage across many frames is, but somehow I doubt that in terms of man-hours the effort beats porting the existing large-scale Nasal codes to C++. Just my 2 cents in any case. Sorry, this really had to get out. Now, back to being constructive. As I said, I try to do what I can in terms of getting old code out and streamlining the rest - hopefully we get some improvements. Right now, with Advanced Weather we have a weather simulator with a FlightSim attached. We're spending 10 (yes 10!) times as long in the Events Sub-module with Advanced Weather than in Basic, and 5 times as long as we spend in Flight. It would be a good design aim to get this all more in
Re: [Flightgear-devel] Sea color
Thorsten I did a bit of testing of my own yesterday, and I have made a few other observations as well. User feedback: I've largely come to ignore that (with few exceptions such as Vivian's performance table), because trying to make sense of it is a path into madness. Just a few examples: On my own system, Advanced Weather tends to lead to better framerates than Basic Weather for similar cloud cover. In fair weather, I'm getting 10% more, in overcast conditions sometimes even a factor 2. I have some user feedback (4 cases by now) confirming that. Heiko recently said that he previously got better framerates using Advanced, but not any more. My problem - I didn't really change anything except parameter values and such things between the two occasions. Logical conclusion: The performance of Advanced Weather can change uncorrelated with changes in the code, and it affects different users in a different way? I too saw improved framerates in Advanced Weather a short while back, but they seems to have disappeared. It is quite hard to compare like-with-like between Basic and Advanced Weather. A while ago, the user sgofferj experienced 'stutter' when running Flightgear. Vivian was kind enough to immediately blame Advanced Weather on the occasion, however the screenshots clearly showed (and sgofferj later confirmed) that he had never loaded Advanced Weather (read the story here http://www.flightgear.org/forums/viewtopic.php?f=68t=15235). Logical conclusion: Advanced Weather is able to cause stutter even if the module is never loaded? So, for some it's faster and they gain a lot of performance, for some it's slower, for some it causes stutter when loaded, for others the mere presence on the harddisk causes stutter, for some it works fine... should any of this really cause action from my side? Largely, this is anecdotal evidence. Yes. You have produced a very nice piece of work which gives variable results in different systems. We need to at least understand the cause and try to fix it 'Bare Flightgear' My testcase was France Custom Scenery with the ufo, visibility probably 50 km or so, no shaders. Removing *all* weather and just remaining stationary, I get 70 fps with a worst frame delay of pretty constant 14 ms, since 14*70 = 980 ~ 1000 this means I get very evenly spaced frames. However, just flying in a circle, my worst frame delay starts to get jumpy every 2-3 seconds, it goes to 35 - 45 ms, a bit dependent on the scenery to sky ratio. My interpretation is that I'm seeing the scene being shuffled in and out of the GPU memory - as I turn, the scene in the visual field changes, and the GPU needs to compute the changed elements, causing delayed frames. Pity you didn't use standard scenery. I don't think custom scenery and the ufo will produce representative results. Just flying straight, the worst frame delay also changes and jumps to 45-55 ms every few seconds. After a bit of experimenting, that's probably the effect of loading and unloading of scenery tiles, objects and such like. Loading and unloading scenery tiles every few seconds? Any evidence for that? That is to say, the bare structure of Flightgear has discontinuous workloads as well, and they cause frame durations of up to 55 ms on my systems. There are also genuine (but rare) pathologies like the first look back in the F-16 (a few seconds of frame delay...) - I guess that's particularly large texture sheets loading. Yes it probably does. And we should be trying to eliminating these wherever feasible. And don't forget that there's Nasal everywhere which is doing its Garbage Collection. 'Full Flightgear' In my favourite setting, I have weather and lightfield shaders on and a decent visibility. On the occasion, that delivers me a framerate of ~20 fps with a constant worst frame delay of 50-55 ms. Since 20 *50 = 1000, the frames come nice and like a clockwork whatever I do - scenery loading causes upward spikes to 55 ms from 50 ms, but that's all, i.e. now the GPU is slow enough to allow all CPU-related stuff to finish nicely. I can reproduce that here. If I throttle the framerate to 20, less than the worst framerate, then I get a steady framerate, but then I get very noticeable but even stutter on the display. I'm aware that there is a school of thought which suggests that regular flickering can trigger epilepsy, but I'm not at all sure if what we are producing falls into this category. Increasing the throttling framerate above the worst (23 fps) makes things gradually worse, reintroducing the spikes in framerate at 30hz. I think we need better than 50 hz for good visual appearance. 40Hz can be acceptable. 'Shader impacts' Vivian always goes talking about smooth framerate, but for instance the water shader is one of the worst offenders in this department, because on my system it makes the framerate dramatically dependent on the view angle. Looking up into the sky and looking
Re: [Flightgear-devel] Sea color
Thorsten Does the problem go away if you set local-weather/dynamics-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/timing-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/effect-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/interpolation-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/housekeeping-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/tile-loop-flag=1 from the property browser *after* Advanced Weather is started? Tested extensively today, and the short answer is no. There is some improvement as the flags are successively set to 0, but Advanced Weather never becomes as smooth as Basic Weather (and that's not without staggers of its own). The longer answer is that the symptoms are readily seen in the System Performance Monitor. There are large differences between the worst and average frame rates, exceeding 50%. In contrast, the Basic Weather difference is approximately 10%, with some occasional excursions beyond this. Switching from Basic Weather to Advanced, I see that the submodule events changes dramatically. With Basic Weather, the numbers in this submodule are consistent with other submodules. With Advanced, events stands out from the rest: not only are the numbers much larger than any of the others but they fluctuate wildly from sample to sample. The total time spent in event during a sample are 3 times that spent in the next largest,flight which is the FDM. It is my understanding that submodule events is where much of the work for nasal is done: listeners, loop timers and the like. I have placed todays test results here: http://dl.dropbox.com/u/57645542/stagger-data.htm What can be done? I cannot speak authoritatively here - perhaps some expert can jump in. Personally I would try trading in some framerate for smoothness, and let all loops run at maximum frame rate. I think at least some of the problem is load variation as various loop cut in. Loops with diverse time intervals must coincide from time to time; perhaps we are seeing that. I did try starting loops at random intervals in AI Models at one time, but that seemed to make things worse. We know that for loops do not help, perhaps those loops can be advanced on index per frame. We know we have problems with Garbage Collection. I suppose the bottom line is that this just might beyond what Nasal was designed for, and we need to migrate to C++. HTH Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
ThorstenB On 11.05.2012 10:21, Renk Thorsten wrote: The problem with that consequence is: As you switched all loops off, the Nasal part of Advanced Weather ceased to run completely and all that's left is the same cloud-generating functionality which is responsible for Basic Weather (C++ and shader work). If killing all Nasal did not solve the problems, then they can't be caused by Nasal, and porting to C++ will not fix them. Not quite true. A significant part of Nasal-related frame rate impact is caused by garbage collection. Its delay/jitter only depends on the number of Nasal objects and their references which need to be searched. Increasing the number of Nasal objects (code+data) existing in memory also increases the delay. The amount of Nasal code which is actually being executed only influences the g/c frequency, i.e. whether the effect is visible every few seconds vs several times per second. This is why we are loading large Nasal modules, like advanced weather, on demand only (= only when feature enabled). We're not unloading objects when disabling a feature though - this usually requires restarting fgfs. This should be remembered when comparing such features (i.e. restart fgfs after disabling advanced weather etc). Thanks for that explanation. In the light of this I did some more testing. Switching from Basic to Advanced Weather increases the time spent in the events submodule from a stable 44 ms to over 1000 ms unstable. Setting all flags to 0 reduces this to 90 ms. Switching back to Basic, the time drops to 75. Adding more nasal loops into the equation by lowering the flaps and gear on the Seahawk, I think I can see the effect as a slight increase in the time spent in the events submodule. I'm not clear how deleterious having one submodule taking significantly more time than any other might be. If that is a problem, then large nasal script are not a good idea even if we only enable them on demand. The instability is clearly not a good thing, but is this a GC problem? If it is, then again, large nasal scripts are not good. Perhaps James can fix the GC issue, and this issue will disappear. I hope so. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
Thorsten There are good sources for sea colour out there - here is one: http://oceancolor.gsfc.nasa.gov/FEATURE/IMAGES/A2008129125500.Scotlan d .png The Northern North Sea, away from the turbidity and major river outfalls of the Southern North Sea, is indistinguishable from the Atlantic, the other side of Scotland. 4 West, 54 North I get an rgb value of (93, 113, 121) 2 East, 54 North I get (31, 71, 83) 2 E 54N? that's the Southern N Sea off the Humber estuary. That is one of the major sources of silt flowing into the North Sea . The depth is probably less than 150m there. 4 W 54N? That's just off Morecambe Bay, which forms part of the Irish Sea. It is the largest expanse of intertidal mudflats and sand in the United Kingdom! Neither of these locations could be remotely described as deep ocean, and yes, we should certainly be investigating how to best model such areas of sea. There's pretty significant variation everywhere, but I don't see that in that picture that the two would even be similar. There are many examples in this archive, and if there are differences in the deep ocean colour in any of the oceans they are darned hard to spot. Similarly, if there is a difference between the Atlantic and the Mediterranean, it's very hard to see. We might not be after the same thing here... In reality, water color depends on a lot of factors: * light reflection at the surface, i.e. light diffuseness, intensity, wave patterns, sky color, ... - we have a decent way to account for that in the shader * sediment and algae in the water - water being a flowing substance, all these are variable phenomena, - rivers carry a lot of mud in spring when the snow thaws, algae bloom - seasonally,... we can't model this realistically in any case * near the coast, depth and nature of the bottom - white underwater sand looks quite differently from overgrown rocky bottom, deep water looks different from shallow water... we simply don't have this information - we might get depth somehow, pass true depth to the shader, use it to determine color, then let the shader move the vertex up to the water surface, but it's a bit tricky. Yup - getting to grips with all that is difficult. Not too dissimilar to getting reasonable representations of towns and countryside in various regions in the world, I suppose Given that we can't do so much realistically anyway for lack of data (and lack of framerate - I could probably write a detailed water color computing code, but that'd really drive framerate down), my idea is more to re-create iconic pictures. When approaching Nice in sunshine, I want to see one of these postcard Cote d'Azur pictures. When landing on a drilling rig in the Northern Sea, I don't expect to see this deep blue. Probably in reality the differences are driven by differences in lighting, average weather and some sediment/algae component - but when I can't do the realistic thing, I might as well do the iconic thing. Many people (including myself) seem to feel that the sea should look different in different places. I'm entirely willing to tweak physics here a bit to create a better illusion that one is in the place by fulfilling the expectation. True, the actual Caribbean deep ocean is not turquoise. Then again, the actual Caribbean city doesn't look the Flightgear way either. But making sea color a lighter turquoise in the Caribbean helps me to maintain the illusion that I am in the Caribbean rather than the Northern Sea. Feel free to disagree, but for me creating the visual environment has much more to do with credible illusions than with getting the physics of the scene right (disclaimer: my position is diffferent for the fidelity of the FDM where we can actually get the physics really right since we have often the required amount of data). I do feel free to disagree - the Caribbean just isn't turquoise, as you say. There was a time when we prided ourselves on FG being the most realistic sim around. Making the ocean the wrong colour to maintain an illusion just doesn't seem to me to sit right with that. But I would also agree that we need to sort out some of the more obvious problems of the shallow seas, if that is possible. Anyway, on a more prosaic note - your sea colour script appears to be bugged here. After I got it to run (my bad, I broke it) I discovered that it iterates at 1 sec not 5 as stated. If I restart Advanced Weather the sampling locations are re-added to the interpolation_vector which grows in size: I have reached 32 so far, but sometimes FG crashes before that point. In any case running Advanced Weather FG crashes here at some point, running out of memory. I would be surprised if this were related to sea-colour, and might indeed be a general problem which Advanced Weather runs into sooner than Basic Weather. You re-instantiate var ppos in each of your locations: nasal doesn't seem to mind, but I wouldn't have thought
Re: [Flightgear-devel] Regional textures merge request
Stuart Snip ... It is possible to use the same scheme to change sea color (this is asked now and then in the forum), but that would produce sharp transitions which don't look very natural - I've cooked up a different scheme to smoothly change base (= for clear sky) sea color (which is then modified by the environment) which seems to be working just fine. All this needs is the following information # St. Maarten s = seaColorPoint.new(18.03, -63.11, 1.0,0.08, 0.40, 0.425); which is latitude, longitude, weight (in 1000 km), (rgb) - if the weight is 1, the declaration will be valid about 1000 km around the specified radius, if the weight is 0.1, it will be valid about 100 km, and so on. So please consider submitting any sea color information in this form rather than as a regional texture statement. I see/sea what you mean, having done a grep in Nasal/local_weather and found it in sea_colors.nas. Nice solution. Might be worth a note in the next newsletter to suggest that people submit sea colors. 50 years ago I joined the Royal Navy to see the world, and what did I see? I saw the sea. So far as I remember, it's mostly dark blue, apart from where the river outflows make it a muddy colour. Where the sea is deep (more than approx. 50m) it is pretty much the same everywhere. The Caribbean is not a light blue/green, apart from shallow water over sandy beaches. Of course there are phytoplankton blooms, but these are of a transient nature. This scheme introduces yet another for loop in Nasal, of undetermined size. This potentially introduces yet another source of stagger to FG, or it would if it worked, but as far as I can see it never runs here. Is it meant? Or do I need to do something to make it work? Nevertheless, perhaps it has promise in introducing muddy water. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Thorsten This scheme introduces yet another for loop in Nasal, of undetermined size. This potentially introduces yet another source of stagger to FG, or it would if it worked, but as far as I can see it never runs here. Is it meant? Well, anticipating your reaction, yes, at this point it's meant not to run by default. It is an experimental feature which you get to see only when running Advanced Weather and lightfield shaders - meant as a proof of concept, borrowing the load-by-default structure of Advanced Weather. I wouldn't dream of sneaking any Nasal loop running by default into FGData, I know very well how that would be received. If the idea catches, I will bother to give it a separate on-demand control structure. Hmm I've got something wrong here then - if I understand that right I select Advanced Weather, and skydome and the sea colour stuff should run? I get this: http://dl.dropbox.com/u/57645542/fgfs-screen-190.png It doesn't seem to have any interpolation. Having said that, your argument about performance is actually rather far fetched. The loop runs every 5 seconds (!), in each loop iteration it updates the distance table for one single interpolation point (i.e. the loop performance consumption doesn't really increase even if you have 1000 interpolation points in there because I'm not doing 1000 distances per iteration, I'm doing one), so I seriously doubt you will ever be able to measure the performance footprint of the thing even if you try really hard. So, I don't think there's a good case against this apart from general dislike of Nasal solutions. I was thinking of this for loop for (var i = 0; i ivector_size; i = i + 1) I take the view that any for loop is not good, but if ivector_size is small, I guess it won't matter. I put a print statement inside this loop - and so far I've not seen it run. I also put print statements in the sea_color_loop, and one in init_sea_colors, but they don't run either. I'm definitely missing something here. Nevertheless, perhaps it has promise in introducing muddy water. It's an interpolation system. The output depends on the input - how to determine reasonable input is quite a different matter. My take on that is that, for whatever reason, I never got the impression that the North Sea ever looked like the Mediterrainean to me. So there is more to water color than just the reflected sky. In any case, having the possibility to change things runtime seems perferable to me over not having it. There are good sources for sea colour out there - here is one: http://oceancolor.gsfc.nasa.gov/FEATURE/IMAGES/A2008129125500.Scotland.png The Northern North Sea, away from the turbidity and major river outfalls of the Southern North Sea, is indistinguishable from the Atlantic, the other side of Scotland. There are many examples in this archive, and if there are differences in the deep ocean colour in any of the oceans they are darned hard to spot. Similarly, if there is a difference between the Atlantic and the Mediterranean, it's very hard to see. The scheme is certainly not completely realistic and also a bit simplistic - but it's more realistic than a constant water color everywhere, and it is so at the expense of one distance computation every 5 seconds (and sums which don't really count because basic arithmetics is dead-cheap to do). Whilst variations in the blue of the deep oceans is arguably not worth the effort, there are many regions where the deep ocean blue is not appropriate - the outflows of major rivers, the turbid shallower seas and so forth We can do muddy. Phytoplankton blooms! To difficult! Hope I can make this work soon Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] XML parser error
James On 5 May 2012, at 20:10, ThorstenB wrote: This is actually showing to be a really bad issue. We have loads of XML files with invalid encodings. Also, there's many files which even explicitly state ?xml version=1.0 encoding=UTF-8? so they are explicitly asking for UTF-8 decoding - but then these files still contain non-UTF-8 (usually Latin1 byte codes). So, even changing the parser's default to use Latin1 (which would be hack anyway) wouldn't help. List of files with invalid encodings (will be rejected by the parser now) is attached. What do we do? Ask maintainers to fix each XML file? Run a script to fix these issues on fgdata? Suggestions? Ooof :( Run a script gets my vote, but I had no idea I was opening up such an issue when I made this change. Looks like just one maintainer to me. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Chris It would be interesting to use skeletal animation to get rid of some of the batch spam with complex multipart models. It wouldn't even necessarily require reworking the model data -- we could initially do the merge and bone attachment when a model is loaded. What are the animation cases? So far I have: - Things move or rotate - Things get removed completely Both of these are representable easily in a matrix palette (removal via w=0); Anything else? I've been waiting for this for years. I animated a couple of pilots way back using the available animations, but haven't done any since - just too much like hard work! Additional animation - spin (special case of rotate) Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Björn Vivian: A combination of canopy features with individual features scattered around the edge? Just like in the Enemy Engaged series of helicopter sims? (See picture) http://www.nexgam.de/media/cache/nexgam/img/articles/8753/Enemy- Engaged-Comanche-vs-Hokum-1.jpg I say this would be a viable option for rendering patches of forest. If the canopy texture can be spiced up with e.g. a bump map, you'd get a fairly good looking, but still fast result. Thats what I had in mind. Perhaps we could use individual trees (outliers) around the edges. It's not an original idea. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Stuart -Original Message- From: Buchanan [mailto:stuar...@gmail.com] Sent: 25 April 2012 10:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Random Buildings On Wed, Apr 25, 2012 at 10:06 AM, James Turner wrote: For me, the builds are extremely expensive - no idea why. The actual density doesn't make a huge different (1.0 vs 2.0, I will experiment more later). Eg my draw + GPU times go from 15msec to 100msec when I enable random buildings. This seems suspicious, since this a single state, texture and primitive set, right? I am testing over Berlin, so there's a lot of urban tiles, but even so, it's a very drastic change. That's very suspicious. There are a small number of states/primitive sets being used (for LoD purposes). Even at density=1.0 in a large urban area there will be many thousands of additional vertices being drawn, so it's possible that is saturating your GPU. One random thought - I think the texture (data/Textures/buildings.png) may still have an alpha channel. It might be worth checking if that's the case, and removing it. (I'm not at my FG computer right now so can't check myself). Looks good here - minimal impact on frame rate. Well done Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Stuart -Original Message- From: Stuart Buchanan [mailto:stuar...@gmail.com] Sent: 25 April 2012 10:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Random Buildings On Wed, Apr 25, 2012 at 10:06 AM, James Turner wrote: For me, the builds are extremely expensive - no idea why. The actual density doesn't make a huge different (1.0 vs 2.0, I will experiment more later). Eg my draw + GPU times go from 15msec to 100msec when I enable random buildings. This seems suspicious, since this a single state, texture and primitive set, right? I am testing over Berlin, so there's a lot of urban tiles, but even so, it's a very drastic change. That's very suspicious. There are a small number of states/primitive sets being used (for LoD purposes). Even at density=1.0 in a large urban area there will be many thousands of additional vertices being drawn, so it's possible that is saturating your GPU. One random thought - I think the texture (data/Textures/buildings.png) may still have an alpha channel. It might be worth checking if that's the case, and removing it. (I'm not at my FG computer right now so can't check myself). It has an alpha channel Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
-Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 25 April 2012 10:46 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Random Buildings One random thought - I think the texture (data/Textures/buildings.png) may still have an alpha channel. It might be worth checking if that's the case, and removing it. (I'm not at my FG computer right now so can't check myself). It has an alpha channel Removed in Git Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
Thorsten wrote: Vivian: I'm sure this is all very well and good - but what are we meant to be testing/doing/patching? Your last patch was all very good - except it only worked with advanced weather, so I was forced to abandon it. Needless to say, the last patch did not 'only work with advanced weather', it just used a single property to summarize cloud coverage instead of computing the cloud coverage inside the shader as I had explained all along. It is a few line Nasal computation to set the property for Basic Weather if needed, a property rule can do the same job I guess, it is a change of one number to make the patch run with the 'cover' parameter in the current version of the shader instead... There's the problem Thorsten. I didn't have the info or the knowledge to do the second bit. I tried the patch you proposed, and as I said, what I had only worked with the Advanced Weather. The code inside the shader was always a workaround to compensate for the fact that we were not getting consistent stuff from the 2 forms of weather. If you fix the weather stuff, I'll fix the shader right away. Vivian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
Thorsten wrote -Original Message- From: Renk mailto:thorsten.i.r...@jyu.fi] Sent: 22 April 2012 12:03 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Water shader issues After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not working than thanks for things working, and all in all I perfer a pleasant atmosphere on the mailing list, and critique of someone's code tends to lead to the opposite. But then, we had a performance discussion, and I had my share of criticism about my use of Nasal slowing things down, and in the end it's information which is better transmitted than not. Let me nevertheless start off by thanking all the people who worked on the shader codes I've been looking at - I learned a lot about how this is done and what can be done by just taking things apart and putting it back together again, I have often enjoyed the effects before starting to mess with shaders myself, and I guess many others also do. I've been over the water sine wave shader again, seeing if I could make run it faster. What I found reminded me of something I (mean-spirited as I am) did to a PhD student starting to work for me. I asked him to write a code evaluating a quantum mechanical scattering process. He did so using an established general-purpose Monte Carlo integral solver. I wrote a code for the same problem, we compared the results and they were the same, so we did solve the same problem and had the same solution - just my code was 100 times faster. Afterwards, he was ready to accept that he can learn from me how to code physics properly. That miracle was accomplished by me telling the integral solver where performance is needed and where not (technically, this involves using an a priori suitably biased sampling distribution, which after the fact gets corrected by conditional probability calculus - which can be proven to work, but looks like black magic). To give a very simple simple example, if we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good strategy to spend an hour to calculate a billion digits of pi. It requires to understand the problem and not use all-purpose, but specially designed problem-solving strategies. The same accuracy statement is true of the shaders by the way - so far all I have seen use the Blinn-Phong shading model, so it's completely useless to aim for an accuracy beyond what that can deliver, because Blinn-Phong is already an approximation which limits the precision that can be achieved. Now, it struck me that the water shader computes wave patterns and foam on a meter-scale. It does so even for a pixel which is 120 km distant (and which probably represents an area of 100x400 m or so). We first calculate a very detailed wave pattern and foam for that pixel, then let the renderer average everything out again to give the pixel a color. That didn't strike me as a particularly efficient way to do things. I replaced the wave pattern in the distance by something that averages to the same thing. That's not the average wave pattern (=a flat surface) because reflected light intensity is a non-linear function of the surface distortion, but noise with the right amplitude, leading to the same standard deviation and the same average, gets the job done. I also asked not to compute any foam beyond some other distance. As a result, the shader performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at 30.000 ft looking at the horizon, 120 km visibility range). In general, how much performance one spends on distant stuff doesn't influence the visuals drastically, because these pixels are more and more fogged and more and more details are averaged out. But more than 80% of the vertices in the scene are farther than half the visibility range, and a fair share of pixels is, and that's the stuff you see from a typical cockpit perspective. So in terms of performance, simplifying the rendering of distant objects counts a lot. I have spent 30 minutes testing the visual impression of my changes in different winds, in different light and from different altitudes, and I could not spot any problem - the shader just ran faster. Despite this, it's possible that there is a problematic situation somewhere. But the answer to this should not be to revert the changes, the proper answer should be to code an exception dealing with the particular problem. I did not get the impression that there was so far any attempt made to optimize the performance of the water sine shader. It's difficult to compare directly since I added the whole terrain haze and lightfield rendering, but I suspect that if all I did (remove redundant
Re: [Flightgear-devel] An empassioned plea
Vic wrote: It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. The point is that those have halfway decent hardware can use the new features, and those who haven't can't. If we want to make the effort - well that's free. If we could find a way of doing shadows etc. which could run on older hardware then we would. Perhaps as development continues we will be able to optimise the system to find more framerate. By the way - just how old is the hardware you are using? The hardware needed to run this stuff can be picked up on eBay for peanuts. Vivian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
Thorsten wrote:
Plus, if you neglect the curvature effect in every relevant vector,
the rendering artefacts at the tile boundaries must go away, because
the differences in rendering geometry between tiles go away, and
they're the only thing which can introduce the artefacts in the first
place.
Turns out I was wrong here - found and eliminated the tile boundary bug.
The problematic thing seems to be refTex in the following code block of
the
water_sine fragment shader:
//load reflection
vec4 tmp = vec4(lightdir, 0.0);
vec4 refTex = texture2D(water_reflection, vec2(tmp)) ;
vec4 refTexGrey = texture2D(water_reflection_grey, vec2(tmp)) ;
vec4 refl ;
if(cover = 1.5){
refl= normalize(refTex);
}
else
{
refl = normalize(refTexGrey);
refl.r *= (0.75 + 0.15 * cover);
refl.g *= (0.80 + 0.15 * cover);
refl.b *= (0.875 + 0.125 * cover);
refl.a *= 1.0;
}
If refTex is replaced by refTexGrey, the problem goes away (but the sea
becomes grey even in sunshine), so there's something odd with the texture
(?). But the whole block is actually obsolete. It basically loads a
128x128
homogeneous grey and a 128x128 homogeneous white texture, samples
both, since both textures are homogeneous it finds the same color every
time no matter where it is sampled, then chooses one of the textures and
discards the other one to determine an (rgb) vector to be modified for
cloud
cover.
Apparently we have the GPU power and texture memory by the bucketful
so that we can use that procedure to determine a color vector. On the way,
I
also eliminated a few normalize(some_vector); statements of vectors which
were already normalized before passing them, so the whole shader has
other obsolete steps as well.
Not that I would be an expert in shader design, but about the same output
(without tiling artefacts) can be achieved in a two-liner:
// basic water color
vec4 refl = vec4 (0.148, 0.27, 0.3, 1.0);
// de-saturate for reduced light
refl.rgb = mix(refl.rgb, vec3 (0.248, 0.248, 0.248), 1.0 -
smoothstep(0.4, 1.0,
scattering));
That has the neat side effect that we could even pass the basic color as a
uniform from outside the shader and change the water color smoothly from
the shore to deep ocean and dependent on latitude (the weather system
happens to know if there's terrain in the vicinity or not).
Feel free to do whatever you want with the information provided, after all
it's open source...Oh, and why do I read so often that coding in Nasal is
a
problem for the performance actually?
I don't think your analysis can be correct; are you saying that the
surrounding if.. else statement is a non op? The intention is to set the
reflection colour as white if cover = 1.5 else set it to grey. AFAIK it
works that way as well. Something wrong with the texture? I don't think so.
It also works with your modification. If we had a better input with which to
set the sea colour to reflect the sky conditions then I would have used it.
It's all an attempt to emulate the cloud cover over the sea and stop it
being a lovely blue in the middle of a storm. I don't see that your
modification honours this intent. The basic colour of the sea is, without
the effects of particulates and phytoplankton in the water, salinity,
reflection from the bottom and other factors, a surprisingly dark blue, but
when there is cloud cover present the sea is more grey.
Proximity of land is only a very rough guide to depth of water. You can go a
long way from shore in the North Sea without finding deep water, but the sea
gets very deep very fast off the Azores. If we can represent all this
better, then I'm all for it.
Vivian
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
Thorsten wrote: I think that is what we have for now. You can do better by increasing your shadow map size to 8192 or 16384, but at the 16384 resolution my performance goes into the tank, and at 8192, there are still many shadow artifacts due to lack of resolution. (clearly blocky/xelated/aliasing edges, something that looks like z-buffer fighting for objects further way, etc.) Hopefully this will improve with future tuning. Okay, just to be sure, I've now also compared what I see to the IAR-80 on Vinson video by Fred and to the Cub flying around Kufstein video by HHS. I'm seeing a number of issues: 1) The shadows around the aircraft have a ragged egde. That I understand is a function of the shadow map size. I can't go beyond 4096, I get an error on the console trying to go higher - but 4096 works fine with acceptable framerates, the edge is just a limit of my GPU and that is okay. 2) I see shadows flickering (I tried the Cub cockpit for comparison) when I'm in level flight where they shouldn't move - the effect is a bit like a shadow cast by a candle flickering in the wind. In Heiko's video that is sometimes visible (he doesn't fly straight much, and when the shadows actually move the effect is masked). I've never seen it in Fred's videos - is it not there, or just not in the video? Personally, I find that flickering maddening - I've ended my test flight after 5 minutes because I was starting to get a headache. 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? 4) Fred's IAR-80 video has the camera circling around an IAR-80 parked on the Vinson. I tried to do this as well, but for me the effect comes out very differently. The amount of shadow I see depends on the angle of the view axis with the sunlight direction - under some angles I see dark shadows, under some angles I see no shadows at all whereas in the video the shadows behave as expected, i.e. they stay the same independent of view angle. Under some angles (sun in my back) I also get a whiteout of bright textures. I haven't seen this issue in any of the videos, but it likewise looks very unrealistic - I watch an object, and as I overfly it, the shadow goes away... The disappearing shadow was caused by the sun camera and range animation and was fixed a while back - can you confirm that you are using the very latest fg/sg/fgdata? And it's probably worth checking that you have the very latest nVidia drivers. It looks to me as if you are pushing the very limits of your GPU; I think you might have to accept that you are not going to be able to use the added facilities provided by Rembrandt. Vivian Vivian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
Thorsten wrote: -Original Message- From: Renk [mailto:thorsten.i.r...@jyu.fi] Sent: 11 April 2012 09:33 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] No Rembrandt here... Be sure I value your feedback, but we are exploring new lands here. There is not so much OSG deferred rendering example or real application around, so please be forgiving. And I don't think Flightgear is unusable for anybody. The Rembrandt renderer is optional and the classical/2.6 renderer should work for everybody. Sorry if that came across the wrong way. I am well aware of this - I am probably more worried about aircraft and/or scenery being converted and committed at this stage than about project Rembrandt as such, since the default renderer is working just fine. What also bothers me is the attitude I've come across with other people (not you!) which goes like 'Don't bother writing something for the 2.6 renderer because Rembrandt will be there.' - which sounds more like replacement than optional. I'm also observing statements being made in the forum by various people - some are rather cautious, others raise expectations for a release which may backfire badly if there turn out to be issues with many cards. So I'm not writing this out of the blue. Personally, I can live without shadows if my GPU turns out not to support this at all in the end - but I can't really if all aircraft at night use Rembrandt in a non-optional way and all I get to see with default rendering is darkness. And so on. I'll explore your suggestions and let you know what happens. Ah the dangers of forums! Whether or not an aircraft is converted to Rembrandt depends on the aircraft developer. Personally, I have taken the route of adding a Rembrandt version to the inventory and leaving a version still fully compatible with 2.6.0. This is by way of being a test-bed for Rembrandt. So far it has taken several weeks, and most of it is just eye-candy. This is partly my learning curve, partly bugs, and not least the sheer size of the task. I think that you are quite right to express your concerns. I suppose in the future there might be aircraft or scenery developed purely for Rembrandt (and that would be a poor decision by the developer), but at the moment I cannot see why your fears would be realised while Rembrandt remains optional. Vivian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More Rembrandt Feedback
Torsten wrote The cost of shadows is the difference in fps between night and day, as shadow rendering is disabled at night. No moon shadows? I see a long discussion coming up about how unrealistic this all is ;-) Did we not have a discussion a while back about our nights being too dark? I think moonlight would be great, but we would need to take into account the phases of the moon. Something to do as a future enhancement. Vivian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More Rembrandt Feedback
Stuart wrote Hi All, Rembrandt works well on my GT260M, and really moves FG's graphics on massively. I think it's a fantastic enhancement to FG, and we should really consider naming the July/August release as v3.0.0. Does anyone know whether FG is unique amongst desktop simulators in offering this? I have no experience of X-Plane nor FS-X. I've noticed significant slowdown on my computer in the following circumstances: - Forests (e.g. KHAF). Having not looked at the code, my guess is that some NodeVisitor for the rending is delving too deeply into the OSG tree for the random vegetation. - Urban areas. My guess here is that is purely due to the number of models being rendered, each of which is casting a shadow. I know that there are still optimisations to be made, but could I suggest a property switch to limit shadowing to the user's aircraft? IMO the self-shadowing in the aircraft cockpit is the most impressive part of Rembrandt, and the combination of that plus shadowing on the ground might be an acceptable frame-rate compromise for many users. Don't get over excited. Fred is doing a great job, but there are many bugs to iron out yet. We haven't been able to port the water shader nor the ubershader completely to Project Rembrandt yet . Each aircraft in the inventory needs checking for 2 sided faces, panel lights need converting, and nice to have are nav. lights and landing lights. Much of the shared and scenery models need similar checking: the windsock is an obvious one. Can you imagine the task for USS Vinson? Random Vegetation is unusable. Frame rate is taking a big hit for most if not all systems . With a fair wind, and if we can jump over some of the technical hurdles, I think it might just be feasible to get something called FG 3.0.0 out of the door by the end of this year, but I wouldn't bet on it at this stage. Vivian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More Rembrandt Feedback
Fred wrote: Each aircraft in the inventory needs checking for 2 sided faces, panel lights need converting, and nice to have are nav. lights and landing lights. Much of the shared and scenery models need similar checking: the windsock is an obvious one. Can you imagine the task for USS Vinson? Hopefully two sided issue is fixed. I don't think it was rocket science though. Oh - I missed that one. I just wasted an hour our or 2 fixing up 2 sided faces. Never mind, it looks better done properly anyway. Regards Vivian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gpl scenery
HB-GRAL wrote -Original Message- From: [mailto:flightg...@sablonier.ch] Sent: 25 February 2012 19:49 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] gpl scenery Hi Syd Am 25.02.12 17:04, schrieb syd adams: I use Aerodrome charts for reference , and then modify the existing scenery tiles by the measurements written on those charts. Ive used Qgis with shapefiles from a canadian wms server as a background image to tweak the shapefiles from http://mapserver.flightgear.org/ .I assumed these were non-gpl work habits so never bothered offering to submit them. When you're referencing NAV CANADA charts here, I fear this charts and your work can't be published under GPL terms, because you don't get this charts for free and commercial use is prohibited explicitly. I think you are over-doing this one. If the charts are just used as a reference or source, and not republished in some way, then the 3d model produced is analogous to the 3d model of an aircraft produced with reference to 3 view drawings. Syd is only using them to check the positions of parts of his work. Syd's finished work is original, the copyright is owned by him, and can have any licence he cares to give it IMO. BTW - if I am wrong - then almost all the work on all our 3d models cannot be GPL. Vivian -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Douglas Dc 3 in GIT
All, I'm sure that there's right and wrong on both sides of this discussion, and I'm aware that some have some difficulty with the English language but could we please continue it in a more decorous manner, and take the personal abuse elsewhere. The Devel list has a long tradition of avoiding personalizing discussion, and I for one wiish it to remain so. Vivian -Original Message- From: Pierre Mueller [mailto:pierre.muel...@ymail.com] Sent: 12 February 2012 17:53 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] The Douglas Dc 3 in GIT When the team of the PAF has decided to prohibit access to their work to me, they also requested the opportunity to put it on ILM. They only banned you from the PAF-Forum. Simply because you offended some users there just for having a different opinion than you. That can be read by everyone in the forum, without beeing registered. And everyone can download their work, without beeing registered. I have seen that you nearly always act like that, even on the official forum and here on the mailing-list. Lacking social skills I would say. When I finally got access to their improvements, through a person who has nothing to do with them but that dispatched the wiki link that I did not know, so I logically integrated all their work to my airplane. Thus it has always worked. To YOUR aircraft? THEIR work? You started the work on the aircraft, but it was the team who finally finished it. So to make it clear: it's not alone your work, and not alone their work. It is a work of ALL INVOLVED! And they published the link in the official forum- you can't have missed that. I always took the time to report the authors of the additions in my site because it seems normal for me. If the team of the PAF not appreciate the principle of respect of the original authors of the open source, they go to make aircraft for FS X or X Plane. In addition, it can make money Muaahahaha - ROFL! 1.) Who is the original author? You? Again: You just started a work; the real work- making it flyable and usuable- was done by this group. Without them it would have been another crappy aircraft made by you as the other more than hundred (!) ones by you. They are the original authors as well, like beside you! I would even say, that have made the main work! So there are multiple original authors- that's something you have to learn. And you have to respect them as well. You didn't learn from the AlouetteII-conflict last year, right? 2.) YOU want tell us about the principle respect of original authors? I can still find the already mentioned copyright violations in your aircraft! But see below. I'm tired of seeing all these kids puerile want to use the work of others, to obtain recognition as authors. I have searched through the forums and mailing-list, and it still seems to me that you did not really understand OpenSource. And back on the 5 or 6 files with licensing issues in my airplanes is ridiculous. As usual, Clement did not consider before speaking. Because most have been fixed. 5 or 6? I can remember more - still too much. And much too much for someone who accuses others here for disrespecting OpenSource. Since I started I've always done anything that try to bring something to FG and to please the greatest number. I'm not trying to please me personally. But this, it seems that the PAF can not understand. Sorry, I have to doubt your words, I'm not trying to please me personally. is looking too suspicious to me! And they do the same what you want to make us believe you do: trying to bring something to FG; and please to greatest number. And it seems to me that they do with great success- as many more users are tired of the many half finished, unusuable aircraft made by you. It's a shame. The team is talented, but seems guided by a kid with goals unrelated to FG and Open Source. I don't see that, can you prove it? I wonder how many discussions like that will follow- there seems to be a coherence between your acting and understanding of teamwork and OpenSource and such discussions- OSG-Particles, Bell UH1, AlouetteII, Velocity-XL, and now the DC-3 Why I don't see such discussions on Gijs, Martins, Syds and others work? Why? Pierre Mueller Switzerland -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal API generator
Adrian Hi all, I've written a parser to generate a local API documentation for Nasal scripts inside $FGROOT/Nasal. Here is a preview of the result: http://ompldr.org/vY2kwNA/nasal_api.html Is there any interest to add the parser and API doc to the repository? Seems like a very useful piece of work. Lets get this into the repo soonest. Vivian -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
thorsten I've noticed recently more or less by accident and to my dismay that model-default.eff is used both by models placed in the scenery and by typical aircraft 3d cockpits. This is rapidly looking like a bad idea when a more detailed atmosphere model enters the game - the terrain haze shader has altitude-differential fog, the sunrise/set code I'm working on has position-differential lighting and fog coloring. Models placed into the scene need essentially the same shader as the terrain and skydome, otherwise they don't blend properly - no choice here. However, half the visual field is typically taken by the cockpit, and the vertices and pixels of that don't really need to go through ~120 lines of differential fogging and lighting code just to discover that they get the default light at the position and no fog. One could probably write some provisions into the shader to make a distance check first and if the model is very close not to go through all the motions, but it seems more reasonable to me to do this on the level of the effect declarations and simply feed the 3dcockpit through a different default effect file which never tries to do any fogging in the first place. Would this be complicated to do (i.e. require changing all aircraft xmls), or is there an easy way to do this? I'm just testing the waters here... as far as I know none of the position differential shading code has been committed yet, but I'm sort of developing strongly into that direction, and I want to identify trouble as soon as possible... If I understand this correctly, you want to change the default behaviour for the scenery models while leaving the cockpit as is with the current default behaviour? Does it also involve changing the behaviour of the non-cockpit parts of the aircraft model? At first glance this seems to be a huge task to modify each aircraft model, but it might be automatable. I would think the work should lie where it falls - if you want to change the default behaviour of scenery models do just that and leave the aircraft alone. Just some final thoughts - what is the framerate cost of this enhancement? And with Project Rembrandt waiting in the wings is this worth doing at this stage at all? I take it that whatever you do it is not for the upcoming release? Vivian -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Martin Spott Gijs de Rooy wrote: How about moving these messages to --log-level=warn or the like? I strongly object: People are willfully committing proprietary stuff into FlightGear. As long as we can't stop this, writing a warning is one of the best things we (The FlightGear Project) can do. While not taking any position on the need or level for this alert, could it please be meaningful! Image D:/Git_New/my_fgdata/Textures/Terrain/sand6.dds contains non portable co mpressed textures. Usage of these textures depend on an extension that is not guaranteed to be pres ent. Just what is the user meant understand or to do about it? Vivian -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Mathias Hi, On Sunday, January 15, 2012 10:56:14 Vivian Meazza wrote: Just what is the user meant understand or to do about it? What do you want to read? I would suggest Image D:/Git_New/my_fgdata/Textures/Terrain/sand6.dds uses compressed DDS textures which may be unsupported by your video driver and not display properly. Vivian -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Mathias On Sunday, January 15, 2012 12:08:14 Vivian Meazza wrote: I would suggest Image D:/Git_New/my_fgdata/Textures/Terrain/sand6.dds uses compressed DDS textures which may be unsupported by your video driver and not display properly. Ok, Can you help me further: It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably have the same effect. So I think simply ommitting DDS is ok? Also, much more important, the comment is not about 'your video driver'. It is in your (Vivian) case even wrong. Your driver will display this fine. So, in the end I do not care if it is 'your particular video driver' that does not like this. You will just see this in the best case as the models look wrong, and in the worst case fgfs just crashes the driver if these textures are used. What I really care about is that these files are expected not to work on a huge amount of graphics boards out there. The point is to tell people doing textures that they should omit compression so that this message disapears. Ideas how to write this? If what we want to do is to alert users, we could use this: Image D:/Git_New/my_fgdata/Textures/Terrain/sand6.dds uses compressed textures which may be unsupported by your system and may not display properly. Such a message could be displayed on the splash screen of individual models rather then as alert, on the assumption that the many users never see the console which is hidden behind the fgrun window. On the other hand, if you are trying to tell aircraft modelers not to use these forms (.dds .ivs) of compression, then: Image D:/Git_New/my_fgdata/Textures/Terrain/sand6.dds uses compressed textures which may be unsupported some systems. To remove this alert, decompress this texture. My concern with the latter form is that it only applies to very limited number of aircraft models and developers, while it is at best meaningless to the user, and may lead to confusion. Vivian -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
-Original Message- From: Mathias Fröhlich [mailto:mathias.froehl...@gmx.net] Sent: 29 December 2011 20:04 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Improving random trees buildings Vivian, On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote: I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? Well, the default f16 does not work anymore for example. I have also never tried the new textures, but I assume that these also contain precompressed data? Also you claimed that the old texture files start to bitrot comared to the new ones which makes me think that the new standard should be the dds files. This together makes me think that the dds files should replace the traditional image files. Yes - the new textures do contain pre-compressed data. Emilian is the driving force behind the new .dds terrain textures, and some of the features he has used cannot (as I understand it) be back-ported to png textures. So yes, there would be merit in making the dds terrain textures the default, but since we were aware of at least some of the problems this might cause we made it a switchable option. FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. Well, the drivers are fully compiant. And if compliance would be a problem I would rather improove the driver than raise this at an application level. These kind of precompressed images limits their usage to a specific set of drivers. And no, due to the patent issues no open source code including ours is allowed to implement compression/decompression code for these image formats. Even if this is easy implementation wise. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. The hangs are caused by mipmap generation on the fly by OSG? Ok, for that you might need to understand that the reason for Erik to use the dds files for the f16 is that they appear to improove the hangs that occur with ati and nvidias drivers on mipmap computation. I would expect that. Of course, dds should improve the situation. Which means either use the f16 together with the closed source stuff or don't use the f16. This is as of today *practically mutually exclusive*. That isn't the only solution - it is not difficult to provide an F16 with png texures and one with dds, allowing the user to select which one is most suitable. Not ideal, but a workaround I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? As long as all is optional, the 'old stuff' is not bitrotting and as long as the usual model still work, this should not be a huge problem. I already told, I can tolerate not having the f16 - that would be sad, but ok - but if the same happens with the majority of our texture files, I would object. The old texture files are static and I would expect them to work into the future, but the new dds textures will leave them further behind as work progresses. The only problem in htat is that some users will lose out on some eyecandy - it will not affect the basic operation of the sim. And this is what I try to do now: Object against using these patented compression algorithms. I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL driver can use this and displays this fine. Think: Intel has the hugest marketshare in graphics today. If I remember right, they sell more than ati and nvidia together (*). This kind of change in effect rules out the majority of users as intel cannot work with these files. (*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins). ... or something along the lines - you get the idea. I have checked in a change
Re: [Flightgear-devel] Improving random trees buildings
Stuart On Sun, Dec 4, 2011 at 10:14 PM, Stuart Buchanan wrote: I've already managed to use a second texture to mask where trees are placed. The following screenshot shows a golf course where I've used a mask so that the random trees are only placed in the rough. http://www.nanjika.co.uk/flightgear/golf.jpg As an update on this, I've now written some code to apply the same technique to the random objects and rotations, so the green channel determines the random vegetation density, the blue channel determines random object (i.e. building) density, and the red channel indicates the rotation. Using the DDS textures, the effects can be quite convincing: http://www.nanjika.co.uk/flightgear/object_mask.jpg Note that these are all random objects - none of the buildings or trees were placed manually. The rotations aren't perfectly aligned with the textures, but it's fairly close. Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Creating the masks is a bit of work, and not something one would want to do if the textures are likely to change. No, there is no intention to replace the materials.xml file with the materials-dds.xml file, at least while there are those systems that cannot use .dds. Equally, we cannot, for obvious reasons, backport all of the new stuff in dds format to png, so over time the two files will drift further apart. There are significant gains in performance and appearance by using dds, so it's worth running both formats in parallel. The current phase of work is largely complete; I think Emilian has some tidying up to do. Apologies for the tardy reply: I replaced one of my HDD with a SSD on Christmas Day - it worked well for 3 hours or so then it all fell apart. The hardware is fine - but I'm still rebuilding all the software from scratch. I expect to have it all back by the end of the weekend. (OK, I'm an optimist.) Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Mathias On Tuesday, December 27, 2011 00:27:41 Stuart Buchanan wrote: Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Hmm, regarding dds. I have to say, that not all OpenGL drivers support texture compression, and the models with dds files, are those that I cannot display, because of that. And in fact this will not happen to the open source drivers before something about 2020 because of patent issues. Sorry to step in this so late - probably way too late - but is there a reason that the on disk format must be compressed? The previous strategy to have on disk an format that everybody can read and to make the driver compress them as needed/possible is better I think? So, for me the f16 lost its livery lately - where I can live with this for the f16, I hope that this does not happen to flightgear as a whole ... There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? I assume closed source drivers are OK? Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Stefan On Thursday 29 December 2011 10:21:11 Vivian Meazza wrote: That said - why use drivers that cannot handle .dds compression formats? I assume closed source drivers are OK? They simply are not. I currently cannot use FlightGear due to simply unusable performance with free drivers but still, it's worth this tradeoff for me after years of pain with closed source drivers (both NVidia and ATI/AMD). Free drivers allow me to: * do my job which is programming which needs loads of text on the screen (closed source drivers gave unusably low performance here) * have multiple X servers running, so my girlfriend can have her own user on my computer without either of us having to log out all the time * upgrade to current (development) kernel any time * have decent video performance * actually get support for kernel problems In sum, these features are worth more to me than FlightGear, though I miss it very much. The free radeon drivers nowadays are good enough for many games and other software. It would be nice if FG developers acknowledged their existence and avoided breaking their user's experience. Personally I hope to get back to at least flyable performance levels with a CPU upgrade in the near future. But even if not, I would never go back to closed source drivers. I hear your pain - but as I said - you don't have to use materials-dds.xml - it's not the not the default. Neither do you have to use any shaders - they are switchable. If you still can't run Flightgear - well you know the solution - upgrade your system. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Mathias There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? Because there is no other driver. Like for the intel ones for example. Because work on other interresting system stuff gets much more annoying with any closed source driver. I just do not want to limit myself to flightgear - so I really apprechiate that you could do even serious development to the closed source drivers. Because most stuff that the average linux user cares work perfect with the open source driver stack. And that makes manny people just use these. Then when one of them tries flightgear he will see that it does not work as expected and most of them will then just never again try flightgear. Some of them will land here and probably get saied that he should use an other driver. But most people just don't ask and probably tell others that they have a new laptop but once they tried flightgear, that boring game just does not work anymore ... I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. I assume closed source drivers are OK? The ati and nvidia closed source drivers can do this. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Erik, On Thu, 2011-12-29 at 17:36 +, Vivian Meazza wrote: Mathias I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. At least the bug where switching from internal view to external view cause a big 'pause' for the F-16. It also effects livery switching for the F-16. The F16 is just excellent here. I get a slight pause on firest switching from an internal to external view, but I expect that is the testure loading for the first time. Thereafter it is as near instantaneous as you could wish. Likewise livery changes. Couple of small bugs - a USAF insignia seem to get left behind on the lower wing surface when changing liveries and some errors: Property systems/hook/tailhook-cmd-norm is already defined. Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Some of the textures aren't properly aligned on the RNlAF-J015-demo livery Overall an excellent experience! However, this is perhaps not a totally fair test: I'm running Windows XP on a 128GB SSD, with a Core2 Quad and nVidia GTX 260, so I would expect quick switching etc. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grassland vs. GrassLand
Martin Ah, BTW, thorsten.i.r...@jyu.fi wrote: I believe the intended spelling is 'GrassLand', [...] No, it wasn't ;-) [Pedant Alert] Strictly speaking - in English it is Woodland, Floodland, Grassland etc. But I'm sure we all know that anyway. Vivian -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announcing Project Rembrandt
Fred i am so excited I couldn't resist to share the first milestone of my current project : http://frbouvi.free.fr/flightsim/project_rembrandt_1.png As the name of the project hints, this is only the beginning. So Xmas has come early this year :-)! Excellent progress after all these years. Regards Vivian -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Weather issues for 2.6
Thorsten, ... snip ... 9) Water shader (very impressive!!!) doesn't react to wind/overcast in Local Weather. Vivian, Emilian - at some point we discussed an interface of how to pass the situation to the shader. Technically it's really easy for me to write in any form you like - just tell me where you want to pick up that info. We are still looking into this one. At first glance there doesn't seem to be any good reason for the wind not being honoured. The overcast is a problem of interpreting different implementations between Global and Local weather. Now you are back operational we will try to come up with a suggestion in the next couple of days 10) Skydome scattering shader - is now basically broken in overcast situations when visibility is low, because the clouds fade rapidly but the shader doesn't react, so more blue sky is seen when visibility goes down. In October, I had a near-seamless solution to that involving the ground haze shader, a modified skydome shader, and modified cloud distance fading behaviour which did the trick both for local and global weather (which was also posted in the forum as very experimental feature). Is anyone (Vivian, Emilian?) still working on that - or should this better go into the next release? We had some problems with adapting the ground haze shader to the new, universal fog scheme. At the moment, our results are unacceptable for release. We are not clear at this stage if we can do it at all, and we are unlikely to come up with a tested and tuned solution by the 17th. We will continue to work on it in the next few days to come up with a better informed decision on the way ahead. All in all, the performance requirements of the current version are weird. I took my Carrier-Ops flight from Vinson to Nimitz in the F-14b which used to have good framerate (no terrain) and I ended up with 14 fps. Not really improved a lot by switching water shader off... I then wanted to know how far down it'd go in really detailed scenery and used the Lightning to blast around Hawaii to Maui - with similar cloud coverage I ended up with twice the framerate and a comfortable 24-30 fps. With the Concorde on the runway in Seattle, I had a whopping 3 fps (never seen anything this low...), but the AAr with the F-16 around Las Vegas gave me 34-40 fps (again in similar clouds). Doesn't agree at all with my previous experience. Some improvements to the wake of Vinson are likely to have cost some framerate. These can be reverted by selecting a lower quality setting so it should be possible to compare like-with-like. Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
HB-GRAL -Original Message- From: [mailto:flightg...@sablonier.ch] Sent: 15 December 2011 17:37 To: Olivier; FlightGear developers discussions Subject: Re: [Flightgear-devel] Re : Arresting Type Devices Am 15.12.11 18:26, schrieb Olivier: Hello Yves, Arresting cables for runways do already exist in FG: see them in action at LFRJ Naval Base for instance. Olivier Errm, Is this BAK12/14 or MA1A, ES or E28/B ? ;-) The ones I did in fgdata are BAK12. You can see them at Miramar (KNKX) Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
Martin Vivian Meazza wrote: The ones I did in fgdata are BAK12. Just for the record, the original BAK-12 was provided by David Culp: http://scenemodels.flightgear.org/modeledit.php?id=918 We're having two models of a BAK-12 in the Base Package because some people here are incapable to comprehend the world beyond their own nose ;-) Look under your own - one is non-op - the other functioning. You can pick whichever you prefer Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
-Original Message- From: Martin Spott [mailto:martin.sp...@mgras.net] Sent: 15 December 2011 19:39 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Re : Arresting Type Devices Vivian Meazza wrote: The ones I did in fgdata are BAK12. Just for the record, the original BAK-12 was provided by David Culp: http://scenemodels.flightgear.org/modeledit.php?id=918 We're having two models of a BAK-12 in the Base Package because some people here are incapable to comprehend the world beyond their own nose ;-) No, I'm wrong. The one I did which says this: * Add runway arrester gear type BAK-12. Based on Dave Culp's original work. is operational. The other one, which used to be non-op, seems to have gained operational capability along the way. It was the original intention to have 2 - a simpler, non-op one and a more complex functional one. The distinction seems to have become blurred along the way Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound support broken by AI traffic
Erik On Mon, 2011-12-12 at 20:22 +0100, ThorstenB wrote: Hi Erik, Am 12.12.2011 13:31, schrieb Erik Hofman: I've implemented a mechanism to free OpenAL sources that are farther away than max-distance (3km for the current AI models). This might solve your problems, although it is not a one size fits all solution. I'm still getting many error messages at EHAM - but it's better now. It's starting ok and I'm hearing AI sounds. Nice :) However, XML conditions for AI aircraft have no effect. All AI sound samples are played unconditionally as soon as the aircraft is in range. That's the problem of the AIModel code that models hardly any properties suitable for sound playback. It should be extended and the config file should be updated to match the changes. play once AI sound samples are also played continuously. I think it's caused by an issue with your last update. Attached patch restores the effect of the XML conditions for me - and also play once samples work as expected. Not sure if that's the correct way to fix it though... Not entirely no.. it looks like the looping setting gets lost in the process, I'll take a look at it. As of this mornings Git with MSVC10 build and WinXP I'm getting this continuously repeated: Sound manager: No more free sources available! At KHAV with the traffic manager disabled. Frame rate is reduced to 4-5 and the system is unusable. Vivian -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ 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 3Dclouds!
Thorsten wrote: IIRC clouds were moved into bin 10 to improve appearance vis-à-vis particles. If we put clouds back into bin 9 and particles remain in 10 all the cooling towers, chimney efflux, aircraft contrails, exhausts etc. are drawn after the clouds i.e, in front. Rather looks as if we can have realism or framerate but not both. Are these assignments runtime-changeable? Not that I can see at the moment - right now particles are hard-coded to go into bin 10, and the others are shader based which can be changed relatively easily - but not during runtime. If so, one could use a simple criteria to get it (roughly) right. * particle effects associated with an aircraft are always drawn in front (they must be nearby to see them anyway) Sort of true - but this will generate odd effects in tower views. * aircraft contrails are always treated as clouds (they are clouds) Yes - true - but they are particle based so they will follow whatever heuristic is appropriate for aircraft above. So they will almost never be right. The persistent contrails are shader based, and can go into whichever bin the clouds go, and will work fine, except they will not necessarily match the particle based contrails. * ground-based model effects are drawn in front if the current view is below some decision altitude, and they are drawn at back if the aircraft is above (with the decision altitude being the lowest cloud layer) We make no distinction between types of particles - they're all the treated the same atm and get bunged into bin 10. This set of rules should get so much right that the exceptions don't really matter. So you can see why the decision was made to lump them all together into 10 and let God, sorry OSG, sort them out. And so it does by and large, making a pretty good job of it, but it takes its time over it. Catch 22 or what? Vivian -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ 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 3Dclouds!
Emilian On Sunday 11 December 2011 22:04:02 Stuart Buchanan wrote: On Thu, Dec 8, 2011 at 10:47 AM,I wrote: 2011/12/8 Mathias Fröhlich wrote: 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. I've had a look, and I think I can change the code to create a single PrimitiveSet for each cloud fairly easily. On thinking about this a bit more, one thing that I don't quite understand is why the behaviour for clouds should differ so much from our random vegetation. The random vegetation code we have is very similar - a small number of geometries being used again and again. Yet, the performance is far, far better, even with much higher numbers of objects. I had thought that the main difference was the use of transparency, where the clouds are larger and generally more transparent than the trees. If so, and the alpha blending of the textures has the most impact on framerate, will changing the geometry help significantly? Or is it the case that the transparency _within_ a geometry is much more effectively handled by OSG than the transparency between different geometries? -Stuart On a sidenote to this discussion, all cloud*.eff files force render bin 10, moving them back to render bin 9 (as they were before according to this: http://mapserver.flightgear.org/git/?p=fgdata;a=commitdiff;h=f94af651aecc6 3ea1989529f0114b28b4bcef48f and also to the setup in simgear/scene/util/RenderConstants.hxx ) gives me back a lot of performance (roughly from 15fps to 30 fps with fair weather, and much less framedrop in cloudheavy configs with a 8600gt). Maybe there's some performance to be gained back from that too? IIRC clouds were moved into bin 10 to improve appearance vis-à-vis particles. If we put clouds back into bin 9 and particles remain in 10 all the cooling towers, chimney efflux, aircraft contrails, exhausts etc. are drawn after the clouds i.e, in front. Rather looks as if we can have realism or framerate but not both. At the time performance was not unduly hit - but I might be remembering incorrectly. Vivian -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ 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.)
Yves -Original Message- From: HB-GRAL [mailto:flightg...@sablonier.ch] Sent: 10 December 2011 10:25 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] apt.dat update (lowercase names etc.) Am 10.12.11 07:52, schrieb Tuomas Kuosmanen: Wouldn't it be useful to somehow flag the airport as closed/restricted/whatever in the data, so that nav displays and gps/fms units could show a different airfield symbol if desired for closed airports? Does the data format support this? There is one field left in apt.dat airport line which is deprecated. This would be the only possibility to set a flag (0=open, 1=closed ?), but I think with this flag set FG apt.dat is not compatible anymore with original xplane data. I guess some external apt.dat readers around use the [X] somehow ? (Remark: What I wrote about FAA and Cl is wrong, there are three states in US data: CI - closed indefinitely; CP - closed permanently; O - operational, so closed in apt.dat should mean CP I think.) I think the difference between CI and CP is too subtle to matter to us. If we only have a binary value then we should think O = 1, 'not O' = 0 where 'not O' = CI or CP. If we can have a ternary value then O = nil or undefined, CI = 0 and CP = 1 Works for me anyway. Vivian -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ 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] Snow line based on METAR
Csaba wrote: -Original Message- From: Halász [mailto:csaba.hal...@gmail.com] Sent: 06 December 2011 16:55 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Snow line based on METAR On Tue, Dec 6, 2011 at 5:15 PM, Gijs de Rooy gijsr...@hotmail.com wrote: I wrote a Nasal script, everything works fine, but I stumble accross a problem with my listener. For some reason the snow-cover property seems to be tied and therefore it always reports nil to a listener (AndersG said so, I got no idea what that means). Would it be possible to untie the prop? Or is there a better solution? You can find the script below. You can attach the listener to the metar/valid node which is left untied for this exact purpose. Make sure you trigger for all writes, not just changes (to catch valid-valid updates). I'm not sure that this is correct. Nasal listeners don't mind if a property is tied or not - this must be true or else weather-utility.nas wouldn't work to untie properties for use by effects. Effects use c++ listeners, and these do care if a property is tied. 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] Trying to get more performance out of the 3Dclouds!
Stuart wrote: On Mon, Dec 5, 2011 at 8:26 AM, Thorsten Renk wrote: Since according to the newsletter Stuart's current ongoing quest is to get better performance for 3d clouds, here are some of my observation: Thanks very much for the observations. Lots of food for thought :) As an FYI, the investigations I've been doing haven't born much fruit. In fact, I've been thinking that my quest is a bit like that of the Holy Grail - something you never actually attain :) I had come to the conclusion that the only way to get a signficant increase in performance would be move to using Impostors. That's a big change, particularly as the OSG implimentation appears to be broken/bit-rotted. I've been strenuously avoiding having to think about implementing it myself, but I may have to just bite the bullet. Either way, it isn't going to happen for 2.6.0! * I've noticed that when I use the relatively lowres Altocumulus texture sheet (3x3 on one sheet) I can basically use a ridiculous number of sprites without performance deterioration, whereas when I use the hires Cumulus sheets (1x2 plus 1x3) the number of sprites I can show before performance takes a nosedive goes down substantially. That's very interesting information indeed. I will do some like-for-like experiments One contributing factor may be differences in the amount of transparency in the different textures. * There seems still to be stuff computed in the shaders per vertex that is actually an uniform per frame - eyepos for instance. I wonder if the computations could be speeded up significantly by consequently pulling all things that are really uniforms out of the shaders. I'll take a look. Vector and matrix calculations should be very efficient in the GPU, and we're only performing these per-vertex rather than per- fragment, so there may not be much benefit. * We're likewise fond of computing stuff per frame that changes more like per minute. The orientation of faraway clouds doesn't have to be computed per frame, because it can't change much per frame. If there'd be a way to store the value used last time, then (based on a distance criterion), one could assign clouds into n task groups and recompute a task group only every nth frame and use the last stored value otherwise. Back when I rotated clouds from Nasal, this did work and improved performance by a factor 5 or 6 - not sure how much it could do with a Shader setup, not sure how to do it technically, but my guess is that it would speed things up. We already use this technique for sorting the sprites within the cloud, by using a heuristic that if the sprites were already sorted the previous time we checked, they probably still are. We could do something similar for calculating the eyepoint outside of the shader, but as pointed out above, I'm not sure this is the main perf limitation. Emilian and I noticed that the local cloud effect files are using render bin 10 - thus competing with all other transparent objects, while the global clouds use render bin 9 - the dedicated cloud bin. We have tried moving all the clouds to render-bin 9: Emilian reports a significant gain in performance but I see little change here. However, we are not aware of the reason for the use of different bins. We also note that you are back to using the .png textures with their black edges etc., rather than the .dds that we provided. Use of .dds textures should at least be no worse than .png and at best will provide a small performance advantage. Unfortunately, we are only scratching around the edges for improved performance using the existing technique, and really we need to try something a bit more radical. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] Shader Development
James On 1 Dec 2011, at 22:47, Vivian Meazza wrote: I think it's all in Gitorious now - so you should be able to see for yourself. Getting a couple of compile errors from my Radeon 3870: glLinkProgram FAILED Program infolog: ERROR: No definition of fog_Func in vertex shader ERROR: No definition of fog_Func in fragment shader Scaling image '/Users/jmt/Library/Application Support/flightgear.org/TerraSync/Objects/e000n50/e004n52/pharos.rgb' from (24,312) to (32,256) FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: ERROR: 0:59: Call to undeclared function 'texture2DLod' ERROR: 0:109: Call to undeclared function 'texture2DLod' ERROR: 0:110: Call to undeclared function 'texture2DLod' glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled Any hints on narrowing down the errant shader? I really we could report the shader file name :) This is at EHAM with the UFO, if it matters. After much searching, we have found and fixed this one: glLinkProgram FAILED Program infolog: ERROR: No definition of fog_Func in vertex shader ERROR: No definition of fog_Func in fragment shader We haven't done anything to Lod - so that one is a bit more mysterious. In Gitorious - see if we fixed it Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Stuart Hi All, Having seen some recent screenshots from X-Plane 10, I've been thinking about ways to improve our random scenery, in particular buildings. At present, we have random building scattered over the scenery, based on .ac models, plus the Urban shader. The former are limited in that performance suffers significantly as density increases, and there is little control over their placement. The Urban shader provides an good impression of a complex city-scape, but the sides of the buildings are rather gray, and the visuals suffer at low viewing angles. It also has a significant performance impact. I'm wondering whether there is any mileage in using a variant on the scheme we use for random vegetation to create a cityscape. As you may be aware, the random vetegation uses a small number of geomerties instantiated all over the terrain, and uses a vertex shader (which is much cheaper than a fragment or geometry shader) to provide height, width and texture information. Of course, there's no point at all in doing this unless it provides better performance than the urban shader. The Default materials.xml tree density is 4000m^2, or a tree per 63mx63m square (ish). The trees themselves have similar geometric complexity to a cuboid (same number of vertices), but buildings don't generally have any alpha blending requirements. So to a first level of approximation, we should be able to populate the urban area with textured cubeoids at the same density as the trees for a similar cost performance-wise. To provide more interesting buildings, I'm anticipating using a cuboid per floor, plus a modified cuboid for the roof, so probably ~ 4x the complexity of trees geometrically for a 3 storey building. Obviously there would be XML controls in materials.xml (or a linked XML file) for the length, width, number of floors, textures, and roof. At the same time, I'm anticipating aligning the buildings with the texture, and probably using a second texture as a mask to indicate where buildings may, or may not, be placed. This latter technique may also have applications for the trees, so that trees only appear a the edges of fields, or in the rough of golf courses. I'm interested in peoples opinions on this, and in particular what their view is of the current forest and urban shader performance. It may be that my system is unique in that one is cheap and the other expensive, and this is all pointless! Sounds a good idea - I hate the random objects - they are always the wrong style/size and in the wrong place. Just do it - we'll make it switchable at runtime. Users can make up their own minds (or as it has been said of users: what they are pleased to call their minds). Looking forward to testing it, Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: CMake, tomorrow (Sunday 23rd)
Alan, It's probably exactly the error as described :-). Possibly generated cmake without checking the jsbsim box. Easy to check - is fgJSBSim project in the Solution, and is it selected for build in the Configuration Manager? If that checks out then is option(ENABLE_JSBSIM Set to ON to build FlightGear with JSBSim FDM ON) in ~\Flightgear\CMakeLists.txt But that's all pretty obvious - so perhaps the problem is more complex . Vivian -Original Message- From: Alan Teeder [mailto:ajtee...@v-twin.org.uk] Sent: 28 November 2011 15:58 To: FlightGear developers discussions Cc: fatima.iervol...@eads.net Subject: [Flightgear-devel] Fw: CMake, tomorrow (Sunday 23rd) This was sent directly to me. Does anyone know what her problem is likely to be? (I, and others , have already given several answers to this question on the FG forum) Alan From: Iervolino Fatima mailto:fatima.iervol...@eads.net Sent: Monday, November 28, 2011 2:18 PM To: ajtee...@v-twin.org.uk Subject: Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd) Hello, After having compiling in DEBUG RELEASE mode FlightGear under Windows, I get systematically an error while I'm trying to launch fgfs under Windows command DOS. Fatal error: Unrecognized flight model 'jsb', cannot init flight dynamics model. I've installed and compiled sources of FG from Gitorious. I'm using a NVIDIA Quadro FX 570, with Intel Core 2 Duo CPU, 2.80 GHz, 1.96 Go of RAM, Windows XP Prof Version 2002, SP3. Can you please help me because I don't understand why I get this error... ? Many thanks, Fatima KAJOUT-IERVOLINO RD Project Manager EADS Innovation Works 12 rue Pasteur - BP76 - 92152 Suresnes Cedex - FRANCE Phone + 33 (0)1 46 97 31 74 :fatima.iervol...@eads.net P Before printing, think about your responsibility and commitment towards the ENVIRONMENT! -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announce: AeonWave 2.1 for Linux available
Gene On Sat, 26 Nov 2011, Emilian Huminiuc wrote: On Friday 25 November 2011 22:44:47 Michael Sgier wrote: So AeonWave is a complete replacement for OpenAL? Must be...now could it do synthetic speech as used for X-Plane's ATC? Thanks Ever heard of festival? ever read the flightgear manual ? You've got everything needed already in place. Jeeze, a little consideration goes a long way there sparky. Go be a jerk someplace else. I've heard OF Festival, but I haven't HEARD it for years: it's broken with FG and Win XP. Works in its own right though. My bad - I should have made a bug report ... but hang on - no one else noticed? Ah well - sic transit gloria mundi. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problems with cmake
Make sure you have a valid path to wherever you put Simgear:
CMAKE_PREFIX_PATH D:/Cygwin/OpenSceneGraph-2.9.9;D:/Cygwin/simgear
SIMGEAR_INCLUDE_DIR D:/Cygwin/simgear/include
Try setting:
SIMGEAR_LIBRARIES SIMGEAR_LIBRARIES-NOTFOUND
HTH
Vivian
-Original Message-
From: Bjoern Duebler [mailto:bjoern_dueb...@web.de]
Sent: 25 November 2011 14:47
To: flightgear-devel@lists.sourceforge.net
Subject: [Flightgear-devel] problems with cmake
Hello,
I try to build fg by myself but failed to do so.
I've got this problem for about 1-2 weeks already.
I want to build the newest git-Version, simgear is doing fine, but I always
end up with a problem when configuring flightgear:
p, li { white-space: pre-wrap; }
Using explicit data-dir: /windows/E/Flightgear/fgdata
Git revision is ebcc6359b97a64321226a8ed37cf1fce9d1c14d9
apr-1-config not found, implement manual search for APR
/usr/include
/usr/local/games/FlightGear/include
looking for version: 2.5.0
Configuring done
WARNING: Target fgjs requests linking to directory /usr/lib64/. Targets
may link only to libraries. CMake is dropping the item.
WARNING: Target js_demo requests linking to directory /usr/lib64/.
Targets may link only to libraries. CMake is dropping the item.
WARNING: Target fgfs requests linking to directory
/usr/local/games/FlightGear/lib. Targets may link only to libraries. CMake
is dropping the item.
WARNING: Target fgfs requests linking to directory /usr/lib64/. Targets
may link only to libraries. CMake is dropping the item.
WARNING: Target metar requests linking to directory
/usr/local/games/FlightGear/lib. Targets may link only to libraries. CMake
is dropping the item.
WARNING: Target fgviewer requests linking to directory
/usr/local/games/FlightGear/lib. Targets may link only to libraries. CMake
is dropping the item.
WARNING: Target fgviewer requests linking to directory /usr/lib64/.
Targets may link only to libraries. CMake is dropping the item.
WARNING: Target fgadmin requests linking to directory
/usr/local/games/FlightGear/lib. Targets may link only to libraries. CMake
is dropping the item.
WARNING: Target fgadmin requests linking to directory /usr/lib64/.
Targets may link only to libraries. CMake is dropping the item.
Generating done
All I found about this problem here or anywhere else on the nt didn't help
me so far.
Can anyone with more knowledge please be so kind to try to help me.
What else on informations does anyone need?
Thanks
Bjoern.
P.S.: Building with the old system (autogen.sh, configure, ...) worked
always well. I installed the newest osg-version 3.x. OS Suse 11.3
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Initial AI model sound code committed
Erik I've committed the first AI model sound code now. At this time it's probably a bit annoying because there are too little properties (or too little are actually updated) to create a proper sound configuration so all 737 and 747 aircraft now just have the engines running at a constant rate. At least it's working properly now. See AI/Aircraft/737/737-main.xml which now includes Sounds/737-sound.xml which is located in AI/Sounds/737-sound.xml I've been trying the new sound stuff - not a peep. I can't find AI/Aircraft/737/737-main.xml in gitorious - is that the right path or is the file missing? Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
Gijs, This proposal doesn't seem to address the problem namely that 3d clouds and Random Vegetation (trees) require Material Shaders to be checked in the gui, and that doing so ran other, unrelated and unneeded shaders. This proposal is different to, rather than better than the existing. It actually breaks the water shader effect (I expect that can be fixed), and I don't know what else - I haven't time to go through everything. In one important aspect it is worse: the Shader options are not greyed out when the slider is at 0 (shaders OFF), thus it might be inferred that shaders are active when they aren't. I can't see any reason for the dependency between 3d clouds and Material Shaders, but Stuart might enlighten us. Nor can I see any thing wrong with the shaders controlled by the Material Shader checkbox. In any case, the 3 frame rate killers here are 3d Clouds, Trees, and AITraffic. Compared to these, the effect on frame rate by shaders is trivial. As an example using the B29 (with reflect shader) at KSFO I see a minimum of 50 fps with all shaders off and no 3D clouds. If I switch on all shaders, I get 40 fps. With all optional shaders off and 3D clouds on, I see 14 fps. If I switch optional shaders on that drops to 13. If I switch everything on, I get an unusable 9 or 10 fps. I'm using a nVidia GTX 260, not particularly powerful by today's standards. I monitor its performance: with all shaders on GPU usage never exceeds 40% and is more usually 30% or less. I would suppose that, at least here, the problem of frame rate is not in the GPU and shaders but within FG/SG/OSG I would oppose this change on the grounds that it ain't broke so it don't need fixing, and will introduce unknown problems. If you can assure me that all ramifications of this proposal are known and fixed, then I might change my mind. Meanwhile - I would like to uncouple 3D clouds and Trees from material shaders, which if possible would fix something. Vivian -Original Message- From: Gijs de Rooy [mailto:gijsr...@hotmail.com] Sent: 20 November 2011 19:06 To: FlightGear Development list Subject: [Flightgear-devel] Shader properties and dialog Following up on the framerate vs shaders discussion I made some changes to the rendering dialog and the way shaders are controlled. They are meant to make it easier for (new) users to get nice framerates, while still allowing the eye-candy that they find important. Some highlights: * The snow line slider is moved to the Environment Global Weather dialog. * All shaders can be individually en-/disabled via the View Shader Options dialog. * Setting the Quality vs Performance slider to 0 will disable all shaders, with the exception of the tree shader. * Trees can be toggled by a single checkbox click now. No need to fiddle around with shaders to get them appear. I did came across a bug http://code.google.com/p/flightgear-bugs/issues/detail?id=494 but that is not related to these shader/dialog changes. * Shader enable/disable properties and the quality-level are moved from sim/rendering to sim/rendering/shaders. Some notes: * I changed some property names (see above), which obviously brakes some stuff. For example, aircraft that use the PersistentContrail effect need a little edit in their .eff files. * Now that the notorious Material Shaders option/property is removed, effects should no longer refer to the /sim/rendering/shader-effects property. Instead, /sim/rendering/shaders/quality-level should be used instead. That will disable the effect when the quality-slider is set to 0. * The (old) 3D clouds appear to be hardcoded. Right now they still check the old property (/sim/rendering/shader-effects). Therefore, you will not see 3D clouds by enabling the checkbox like it used to be. Local weather clouds works fine though. Because it breaks some stuff I decided to create a merge-request, so anyone can test and share comments, ideas and patches. Here is the merge request: https://gitorious.org/fg/fgdata/merge_requests/122 Enjoy! Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New performance statistics GUI
ThorstenB I have added a new subsystem and dialog to monitor FG performance. It's replacing/improving the original code which was only capable of writing statistics data to the console (I guess few people ever used or were even aware of the old option). The new GUI dialog is available in the menu: Debug = Monitor system performance. Example: http://imageshack.us/photo/my-images/521/fgfsscreen031.png/ * Only statistics on our subsystems are shown. That's the FG modules running in our single-threaded main loop. Everything outside the main loop isn't shown, i.e. there are no statistics on the GPU or OSG rendering threads (use the OSG statistics screen for these). * Title bar shows average and worst case frame rate. In a perfect world, all frames should be spaced evenly, so both values should be almost identical. When frames are produced unevenly, then a larger difference between the worst and average frame rate is visible. Needless to say, we should try to get FG to deliver frames evenly, so movements look smooth. * Main table shows statistics on the individual subsystems. Helps to identify how much time certain systems currently consume, or which are responsible for jitters resulting in uneven frame rates. * A bit background on the FG subsystems may be necessary though to really judge what's going on. For example, you'll see the nasal subsystem consuming almost no time at all, so it looks great. However, almost all the nasal code runs in timers, and timers are driven by the events subsystem. So, to judge Nasal performance, you'll mainly need to look at events (and yes, you'll see time being consumed and jitters being produced there). * Statistics data is only collected while the dialog is open (or you manually set /sim/performance-monitor/enabled). Anyway, this alone isn't improving anything yet, but having a GUI to conveniently monitor performance will hopefully help us to see where exactly we're having issues - and help us to improve... Builds, and runs OK, but just says wait ... Do I need to do something else? Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] attitude indicator in fgdata aircraft
Anders wrote On Tue, 15 Nov 2011, syd adams wrote: thanks for the heads up ... Im currently updating the CitationX so i'll fix that and check my other aircraft. You said fgdata , does that mean aircraft are back in fgdata ?Is the separation idea abandoned for now? Just asking so i know how to proceed , since im updating mine in the FG-Aircraft repository. And so am I. As far as I'm concerned my aircraft now live in FG-Aircraft and will be developed there. An instrument question: is it common for directional gyros to be cageable too? The Sperry A-2 autopilot seems to have a separate toggle for caging the directional gyro but as far as I could see there is no property for that in FG (it was a while since I looked, though). No there isn't. But I could add one. Vivian -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash on exit (Windows)
Alan, Yup here too. Vivian -Original Message- From: Alan Teeder [mailto:ajtee...@v-twin.org.uk] Sent: 14 November 2011 11:46 To: Flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Crash on exit (Windows) The current Git crashes on exit. Here is the stack. It looks like a heap problem. ntdll.dll!777115ee() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!777115ee() ntdll.dll!7770015e() kernel32.dll!751014dd() msvcr90d.dll!_free_base(void * pBlock=0x5a2bd386) Line 109 + 0x13 bytesC 024ff754() msvcr90d.dll!_unlock(int locknum=4) Line 376C msvcr90d.dll!operator delete(void * pUserData=0x17f4f080) Line 57 + 0x7 bytesC++ msvcr90d.dll!operator delete(void * pUserData=0x17f4f080) Line 56 + 0xc bytesC++ fgfs.exe!FGPanel::`scalar deleting destructor'() + 0x27 bytesC++ fgfs.exe!FGGlobals::~FGGlobals() Line 187 + 0x28 bytesC++ fgfs.exe!FGGlobals::`scalar deleting destructor'() + 0x16 bytesC++ fgfs.exe!fgMainInit(int argc=1, char * * argv=0x02812fd8) Line 584 + 0x37 bytesC++ fgfs.exe!main(int argc=1, char * * argv=0x02812fd8) Line 259 + 0xd bytesC++ fgfs.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC fgfs.exe!mainCRTStartup() Line 403C kernel32.dll!7510339a() ntdll.dll!77729ed2() ntdll.dll!77729ea5() Alan -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] more cmake problems
syd Hi Ive been trying to build flightgear with ccmake , no luck yet. The first error was SIMGEAR_VERSION_OK not found , but with some help on irc, I managed to get past this by adding set(SIMGEAR_VERSION_OK 1) to the CMakeLists.txt. Now i get these error messages : WARNING: Target fgfs requests linking to directory /home/syd/FG/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target metar requests linking to directory /home/syd/FG/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target fgviewer requests linking to directory /home/syd/FG/lib. Targets may link only to libraries. CMake is dropping the item. As you can see , i keep FG in my home folder.Simgear built and installed without errors. Any suggestions You need ALL of the following: CMAKE_PREFIX_PATH - path/to/simgear e.g. D:/Cygwin/simgear SIMGEAR_INCLUDE_DIR - path/to/simgear/include e.g. D:/Cygwin/simgear/include SIMGEAR_LIBRARIES - SIMGEAR_LIBRARIES-NOTFOUND SIMGEAR_VERSION_OK - true Works here to solve exactly the problems you describe. I would have told you on IRC, but you seem to have left before I could do so. HTH Vivian -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] more cmake problems
Syd -Original Message- From: syd adams [mailto:adams@gmail.com] Sent: 09 November 2011 22:51 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] more cmake problems Oops , spoke too soon :) /home/syd/FG/flightgear/src/Scenery/tilemgr.cxx: In member function 'virtual osg::Node* FGTileMgr::loadTileModel(const std::string, bool)': /home/syd/FG/flightgear/src/Scenery/tilemgr.cxx:279:17: error: 'loadDeferedModel' is not a member of 'simgear::SGModelLib' make[2]: *** [src/Scenery/CMakeFiles/fgScenery.dir/tilemgr.cxx.o] Error 1 make[1]: *** [src/Scenery/CMakeFiles/fgScenery.dir/all] Error 2 Though it seems a different problem , more commits to go still i think i think I'll work on Citation X for awhile ;) Cheers Yeah - I got that first run - I'd forgotten to re-install SG. Check all the obvious things - up-to-date SG and FG, rerun cmake, rebuild and install SG then FG. You might need to update some of the dependencies too. V. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Skydome and Terrain shader with haze - some helprequired
Thorsten Im the last weeks, I've been working on integrating Lauri's skydome scattering shader in a seamless way with the rest of the environment. I have now a working version of the shaders available which could be committed. This is: * the original skydome shader, with an added simulation of a low altitude constant density haze layer and meaningful response to the parameters /rendering/scene/overcast, /rendering/scene/scattering and /rendering/scene/saturation. * a matching terrain shader which connects to the skydome in a (mostly) seamless way * this can render everything from rather heavy fog on the ground to a near space view at high altitude with (mostly) seamless transitions * some additional code getting the sunrise/sunset plausible by darkening the haze where needed. See http://www.flightgear.org/forums/viewtopic.php?f=47t=11274start=135#p140 031 for some recent pictures * a small change in 3dclouds.frag to let clouds fade into a matching horizon haze color. All this is conceptually independent of Local Weather - while it is supported and the relevant parameters are automatically set by Local Weather, they can be set from anywhere else. Now, I need some help. First, the combined effect of lots of 3d clouds and haze shading isn't fast. It isn't really slow either, with multiple layers of 6/8 clouds drawn to 45 km distance I still get ~20 fps out (36 without the haze and skydome shader for the same clouds), but I have the feeling it could go faster, there's too much redundant things happening. For instance, I get my altitude in model space by vec4 ep = gl_ModelViewMatrixInverse * vec4(0.0,0.0,0.0,1.0); alt = ep.z; in the vertex shader - but this could probably easily be passed as a uniform if I just would know how (lat, lon, alt) maps into model space. And so on. So if anyone with more experience in shader writing can look over it and smooth it a bit, that'd be very good. There is a writeup of the underlying ideas available, and I have tried to comment a lot, and I can also explain the underlying math. The second thing is - I can't get it into a distributable form myself. I don't understand the structure of effect files. In my current implementation, I have just overwritten the Flightgear defaults, used some really ugly hack at one point and distributing that in this form means either using my skydome/terrain or CPU rendering. I don't want to commit it in such a form, this should be optionally linked to the scattering shader on/off. Also, I run into other problems - I've tried to use the haze shader instead of object default, but they're not blended to the same final color when fully fogged, they come out too dark, and I don't know why. I suspect that something happens to objects later that doesn't happen to terrain... So, I'd need the help of someone who understands the effect file structure to create a structure which can be committed without wrecking everything else. If anyone is willing to help with either problem, please let me know and then we can take the bulk of the technical discussion off list (where I can use attachments). I have a pretty good idea what the issues are and in what direction one should probably go to address them - I'm just a bit out of my depth doing it myself. Looks like you are doing things the hard way. Emilian and I are busy rationalizing, and combining and improving shaders as appropriate right now: we would be happy to add your stuff to the pile. You could do a merger request to our sandbox here: https://gitorious.org/fgdata-textures-ng/fgdata-textures-ng Or post the files somewhere that we can get them, or email them as an attachment to me. I can't promise an instant solution, because we already have a heavy workload in FG and RL, but we can take a look. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
-Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 11 October 2011 17:48 To: 'Erik Hofman' Subject: RE: [Flightgear-devel] Skydome and Terrain shader with haze - some helprequired Erik On Tue, 2011-10-11 at 09:30 +0100, Vivian Meazza wrote: Thorsten Im the last weeks, I've been working on integrating Lauri's skydome scattering shader in a seamless way with the rest of the environment. I have now a working version of the shaders available which could be committed. Looks like you are doing things the hard way. Emilian and I are busy rationalizing, and combining and improving shaders as appropriate right now: we would be happy to add your stuff to the pile. You could do a merger request to our sandbox here: https://gitorious.org/fgdata-textures-ng/fgdata-textures-ng Or post the files somewhere that we can get them, or email them as an attachment to me. I can't promise an instant solution, because we already have a heavy workload in FG and RL, but we can take a look. Let me state that all of you are doing an excellent job! FlightGear keeps getting better by the day and I see leaps of progress just in a few months. Great work. Thank you for your kind remarks. We have some more eye-candy in the pipeline, nothing earth shattering. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear BasePackage branch, master, updated. 38b0d83b4eee2e581823a4a9f119b37caa9470a0
Fred, Hi Vivian, - Mail original - commit 7aac380e2f0b1d1657b7179054acfeb61993f7ff Author: Vivian Meazza Date: Mon Oct 10 10:51:25 2011 +0100 Add taxiway symbols in dds. ... materials-dds.xml| 27 BTW, I added the possibility to load alternate materials file to fgrun. It's in Advanced Rendering So I see - nice: I wouldn't have found it by accident, thanks for pointing it out. Now I can retire my property statement that I was using. Thanks for adding that, Regards, Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
-Original Message- From: Torsten Dreyer [mailto:tors...@t3r.de] Sent: 07 October 2011 10:49 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] A collection of issues Am 07.10.2011 08:55, schrieb thorsten.i.r...@jyu.fi: Hmm - after double-checking, it looks good to me. Checked with running --prop:/environment/terrain/area[0]/enabled=1 That seems to be the key, thanks. Works fine if I set the property on startup in the commandline, doesn't work if I don't. We used to have a state where it wasn't necessary to set it in the command line any more - so something there might have changed (?). In the initialization sequence of the environment subsystem, a terrainsample instance is created for each area node under /environment/terrain (you can have as many areas sampled as you like). However, these nodes have to be there during subsystem-init. Maybe you create it from Nasal which probably initializes later? If that worked before - I have no idea what might have changed to break it for you. The last nontrivial update on the terrainsampler was in August 2010. Well, thanks for all the help with tied properties etc. We've managed to work around most of the problems so far and Phase II of the improvements to the water shader are in git. The waves now align with the surface wind, and we try to adjust wave height with the wind speed. Here are some examples: http://imageshack.us/f/830/fgfsscreen070.jpg/ http://imageshack.us/f/571/fgfsscreen069.jpg/ We know the wake could now do with some improvement, and we have some ideas that we will work on before embarking on our planned Phase III, which will have improved integration with Global and Local weather. This only works with materials-dds.xml Vivian and Emilian -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Thorsten Some observations I've made in the last couple of days: * hardcoded terrain presampling: This seems to have died on me after the last pull (probably even earlier?) - currently all I get out is zero everywhere. Since geodinfo() is now 50 times faster than it used to be, falling back to the old system doesn't really make a huge difference in performance though. Whatever you think is best - fixing or going back to geodinfo() - just let me know please. * new water reflection shader - since it doesn't talk too much to Local Weather, I had completely missed it has plenty of features. Great work, Vivian and Emilian - the foam caps look gorgeous. I'd like to talk to the shader better from Local Weather as well. Thank you for your kind remarks. They look nice but in practice have a number of defects: an improved version is in the pipeline as Phase II. We had/have a great deal of trouble finding properties in the tree that actually worked with the shader at all - see Issue #445. From our side we picked what was a. surface wind, and b. worked. We had to use wind from N and E because direction and speed don't. We then need to construct both these values inside the shader. We have tried to accommodate Local Weather as best we can, but we would dearly like commonality between Local and Global Weather, using properties that the shader can read. Unfortunately, we don't know what causes some properties to work and others not, just that this is the case. I've had a look what parameters you're probing, and for example you use the wind from the global weather lowest boundary layer config. Now, I can write that from Local Weather, but that's not a clean way to do things and I'd like to avoid going back to writing into the global weather config to get things done, Torsten spent a lot of time on making it possible to avoid that workaround. Instead, we could maintain properties 'surface-wind-fps' and 'surface-wind-direction-deg' under Environment which are continuously updated by the weather system (global weather has also interpolation and continuous time dependence, so if I'm not mistaken the actual value doesn't have to be the one in config/). That set of properties could also be used by any other wind-dependent surface objects (smoke effects on the ground, windsocks,...) - which somebody else on the list wanted to have implemented a while ago anyway. Yes, surface wind is much needed. We don't mind if it's interpolated or not, we can handle either inside the shader. We expect other users would like an interpolated value. We just hope interpolation isn't what causes values not to be read. We would like surface-wind/speed-kt, /direction-from-deg, /velocity-from-east-fps, velocity-from-north-fps, (please not 'from heading' :-) ), but use whatever is easiest, we can handle the conversions easily enough. Likewise, with total cloud cover - currently the shader tries to deduce that from a number of sources. But for the weather systems, it'd be rather easy to add the coverage of the individual layers probabilistically to get a total coverage and simply provide that number to be used by the shader. (adding layers probabilistically: say I have a 5/8 and a 2/8 - the total coverage is then 5/8 * 6/8 (I'm hitting first layer but not second) + (3/8 * 2/8) (I'm hitting second but not first) + 5/8 * 2/8 (I'm hitting both); or simply 1 - 3/8*6/8 - which is 0.718 or a bit less than 6/8.) Does that sound like a reasonable way to transmit info from the weather system to shaders? That would be great - we thought perhaps this is what the property overcast was intended to do, but it's different in Global and Local weather. The math can be done out in the GPU - there's plenty of scope to offload tasks from the CPU. We already adjust the greyness of the sea to reflect the overcast value. (It would also be nice if the visible weather in Global matched the description a bit better: we make the sea grey when it's overcast, but the sky is still mostly blue). * visibility: Comparing X-plane and Flightgear screenshots for supposedly the same visibility, I've come to think about the definition. In nature, things fade exponential in distance, so the contrast goes away as exp(-distance/lambda) where lambda is the mean free path of photons in the medium. Any physicist would usually take lambda and say that this is the visibility. But after the distance lambda, of course 1/e ~ 36% of the contrast is still there and you can recognize objects. So what's the limit when we conclude we don't see anything any more? 1% of contrast? 0.1%? Dependent on that limit, the relation of lambda to visibility can be a factor 3 different. Flightgear currently seems to fade with exp(-(distance/visibility)^2) by default, which sort of lessens the question by a harder cutoff at the expense of being unphysical for small distances. X-Plane seems to cut visibility even sharper with some kind of
Re: [Flightgear-devel] A collection of issues
Frederic Unfortunately, we don't know what causes some properties to work and others not, just that this is the case. Maybe because some properties are directly tied to C++ variables and can't have a listener. That is a reasonable theory, and one which we have tried to test - but some tied variables seem to work while others don't: is this consistent with your analysis? Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
Thorsten -Original Message- From: thorsten.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] Sent: 01 October 2011 11:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Atmospheric haze modelling Hi Curt, thanks for your comments and explanations. We always recognized potential difficulties with blending the sky into the terrain. The original design used the fog color as the opengl clear color (the color that the display buffer is cleared to before starting to draw any of the frame). We blended the bottom of the skydome into the fog color. And then made sure we drew enough tiles to extend at least to the fully fogged range in all directions. This allowed us to hide the seam between the sky and the ground in the fog/haze at the horizon. Yes, as far as I can see, that's the only way this can be done and why the scattering skydome shader never worked with the default terrain shading. As a side note: I've observed that we're currently fading into fog with exp(-d^2/vis^2) where d is distance and vis is visibility where I believe the physically correct behaviour would be exp(-d/vis) Now, the only reason I can think of to do the square fading is that you really get a hard cutoff after d = vis and minimize the amount of terrain tiles you need for a seamless blending. On the other hand, the square fading brings less fog for d vis than there should be, and actually many optical integrals rely on the factorization transmission (layer a) * transmission (layer b) = transmission (layer a + layer b). So I would prefer linear exponential fading. If the hard cutoff is the only rational for square fading, then I'd propose to use exp(-d/vis - 0.1 (d/vis)^6) instead which for any distance d vis gives linear fading and then has a cutoff as efficient as square fading. Please let me know if there's any other reason why the current code is as it is! One problem: tall mountains in the distance would be fog colored and extend visually up into the blue part of the skydome and look weird -- so the original design worked pretty well, but wasn't perfect. I would guess it is visually acceptable to let mountaintops never blend into the horizon fog. In my current design it would be possible to do so, provided the visibility passed to the tile manager is a clever combination of ground and aloft visibility. Maybe that's actually the general solution - pass a function of different visibility properties used by the shader to the tile manager. The simplest solution is to pass the maximum of all visibilities, but that may load more than one ever needs, so probably an angular weighted version dependent on current altitude would be more useful. I can work the math out... as long as it's possible to go for a solution like that. Oh, and we also had some additional code that would change the fog color depending on your view angle relative to the sun ... so at sun set/rise the fog color would be oranger/redder looking at the sun versus looking away from it. I'm currently using gl_LightSource[0].diffuse as fog color - to the degree that sunlight light changes, my version inherits that (seems to be working fine so far). So definitely we should try to figure out how to make your sky model blend with the terrain some how. It *seems* to be doing fine now after I introduced the harder fogging cutoff - above the ground layer, it still uses /environment/visibility-m to keep track of this part of the optical integrals, so the amount of tiles loaded is actually sufficient - but at 50.000 ft or so I rountinely have visibility values of 100 km. For me, Flightgear renders that still stable and reasonably fast (I tried Custom France scenery, Hawaii as well as Pacific Northwest as test cases), and only above 140 km I get unstable behaviour (some of my Blackbird Screenshots were rather difficult). But on slow machines, this'd probably be a show-stopper. But that's not a shader problem but related to the weather code - that can be instructed to provide a cutoff for visibility that is never exceeded. One more thought while I'm writing. The current scattering effect skydome has a glitch/seam at the azimuth. Depending on the time of day it is more or less visible. It can be really ugly, I'd love to get this fixed if you happen to stumble on what's causing it as you play with all this code. I know... I'm really not a shader person, I have just one idea as to what the cause might be (?). I've often observed that the edges of scenery tiles with the water reflection shader have different colors. I have also on occasion seen fog artefacts at just the same position. My theory as to what happens is that the vertices in this case (= the tile edges) are rather far apart, so when the vertex shader is asked to compute an angle for reflection or light scattering or fogging, it must
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Not convenient we chose Vinson because the deck is indeed identical to Nimitz. Vivian -Original Message- From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 22 September 2011 23:21 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands? I went with the Vinson because it is spiffier. Everything should (theoretically) work the same and just as well from the Nimitz. I believe the deck geometries are identical in FlightGear (conveniently.) ;-) Curt. On Thu, Sep 22, 2011 at 5:02 PM, Arnt Karlsen a...@c2i.net wrote: On Thu, 22 Sep 2011 22:36:45 +0200, Citronnier wrote in message 4e7b9c5d.6080...@gmail.com: Le 22/09/2011 22:04, Arnt Karlsen a écrit : On Thu, 22 Sep 2011 14:00:49 -0500, Curtis wrote in message CAHtsj_crOGWDX43J5oKw7F6g12AWsRePoceNGW=a1b0txod...@mail.gmail.com: On Thu, Sep 22, 2011 at 1:25 PM, Geoff McLane wrote: You seem to be deliberately holding its speed down around 150 - I see air-brakes come up when greater than this, and throttle back - and although flaps (I think full flap?) are still applied, 150 must be quite 'low' for this sleek bird... Normal landing approach in the real aircraft I believe is about 120 kts? I fly 135 kt approaches in the simulator. It should be able to hold 150 kts with the flaps down pretty easily. ..the Navy guys fly approaches using AOA, not speeds, AFAIK. And a max 6000 lbs fuel in the tanks. FG's f-14b is quite tricky to fly with what is *supposed* to be the right AoA for approach. Side departure happen easily if your aren't smooth enough in your final turn. ..and it does not like to T/O and climb on idle power, all Launch!!! button action I see is wild pre-crash oscillations, the Reset button tosses me into the cockpit rather than in the camera. ..Curtis, any reason your demo needs the USS Vinson, rather than a renamed USS Nimitz copy? ..Alexis, any changes to the f-14b since FG-1.9.1? Curt, I didn't test yet, sorry, lake of time, but the last mods on properties in engines.nas and instrument.nas should be comited soon. Happy to see you all playing with the beast :-) Alexis -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Direct Draw Surface Scenery Textures
Durk wrote: Hi Vivian, Emilian, I am currently testing your new texture and I observed two things: First, I recently committed two additional textures for my ground network visualizations code, and these don't seem to work any more when using the dds materials files. I'm getting a simple black line not. Secondly, I noticed that the ground friction (which seems to be materials related), appears to be extremely high when using the new textures. I'm currently trying out the 777 at KLAX, and need to apply almost full throttle to in order to keep moving. Apparently only yasim aircraft are affected by this, but I could be wrong. I have to say that I haven't systematically tested this with and without the new textures, so there could be another explanation. I'm just reporting this, and would be happy to test this further is needed. All in all, I do like the fresh new look though. :-) We have been unable to reproduce this problem on Linux or Windows with a variety of YASim ac at KLAX. We have checked materials-dds.xml against materials.xml and there is no change in the runway friction-factor, rolling-friction, or bumpiness tags. It seems unlikely that a change of texture format of itself would cause the symptoms that you report. Perhaps you could be kind enough to carry out some more testing and if the trouble remains could you please file a bug report here: http://code.google.com/p/flightgear-bugs/issues/list In closing, we would remark that these new textures have been in Gitorious a little while now and that there have been no reports of similar issues to date. Thank you for your kind remarks. Development of new textures continues, albeit at a slower pace. Emilian Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Direct Draw Surface Scenery Textures
Durk -Original Message- From: Durk Talsma [mailto:durkt...@gmail.com] Sent: 22 September 2011 20:27 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Direct Draw Surface Scenery Textures Hi Vivian, Emilian, I am currently testing your new texture and I observed two things: First, I recently committed two additional textures for my ground network visualizations code, and these don't seem to work any more when using the dds materials files. I'm getting a simple black line not. Secondly, I noticed that the ground friction (which seems to be materials related), appears to be extremely high when using the new textures. I'm currently trying out the 777 at KLAX, and need to apply almost full throttle to in order to keep moving. Apparently only yasim aircraft are affected by this, but I could be wrong. I have to say that I haven't systematically tested this with and without the new textures, so there could be another explanation. I'm just reporting this, and would be happy to test this further is needed. All in all, I do like the fresh new look though. :-) Erm - you did release the parking brake? Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
Cedric wrote I hope this is the last time we will have to discuss this topic, since over the last months it seemed that everyone agreed with that FGDATA - has to be split sometime - should be split a.s.a.p. We agreed that after the current release of 2.4 would be a good point to get the project on the way. As I offered and it still stands, I will take care of writing the bash script which splits the current FGDATA repository into multiple repositories and leaves an FGDATA repository which holds merely the bare essentials which supplement the core binary of fgfs. One could classify the contents of the new FGDATA by saying that it's data which provides the technical backbone - the common denominator everything is based upon. I'd like to cease this opportunity to give everyone the chance to utter their possible disagreement with the project or their respective opinions and discuss the very details of the split, which have not yet been determined. The general boundary conditions of the splitting process are the following: - FGDATA shall consist of everything which is essential for the binary to run and shall not hold any data which is specific to certain airports or airplanes. Those should be provided in separate repositories the structure of which is not of current interest and might possibly be chosen by the respective authors. - The change shall not require restructuring of the architecture, including the directory structure. Solely the repositories in which the data is contained shall change. Informatively, I'd like to supply a sensible suggestion for how a final structure might look and how, either as a developer or user might use it. Particularily, because some of you might wonder how we can strip FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a bad decision? Definitly not. One has to distinguish between a proper, dedicated development structure which is aligned to and substructred into independent development units and a way of deployment. As a developer, you will clone the base fgfs SC repository and you will clone the FGDATA repository. Then, depending on your field of interest you will clone the aircrafts, airports etc. you are planning to work on. You can do so with the git submodule, which will integrate the specific aircraft/airport/etc repository into the existing FGDATA repository, while keeping the commits separate. For deployment, you either manually or programatically git-submodule all data required for shipping into a branch for deployment. This includes, for instance, the KSFO tile and the c172p. It's apparent that one, among many advantages of that approach is, that the confusing redundancy between the default KSFO and the scenery KSFO, as it currently exists, will go. While the planes are the primary concern of the splitting and will bring a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and rectify a lot of redundancies and confusion, other things might also be considered, say, ./Traffic (just a lucky guess). Practically everything which is orthogonal to the core and without which FG (assuming a plane and a tile) can properly run, should migrate. I think this is an offer we can't refuse. I think these proposals are as good as any, and are in line with what Tim Moore was doing. Perhaps we should go for a phased approach. In the fist phase, we could split out the aircraft, then further restructuring could form subsequent phases. Cedric might like to start work on his script as soon as possible. Vivian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default Takeoff Runway
Alasdair wrote: Hi all, It always used to be that if no runway or parking ID is specified, a runway facing into the wind will be chosen for takeoff. This no longer happening. Tonight, with METAR KSFO 140056Z 29010KT 10SM FEW006 18/12 A2997 RMK AO2 SLP149 T01830122, I am always started on rwy 10L. And yes, I have --enable-real-weather-fetch in .fgfsrc and git pull of simgear, flightgear and fgdata at Wed 14 Sep 2011 01:41:42 UTC, followed by new build. What is occurring? I'm seeing the same thing with a build of am 12 Sep. Looks as something has been broken. Please file a bug report here: http://code.google.com/p/flightgear-bugs/issues/list Vivian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] substantial base package size increase
Curt, We could retire the old .png textures where these have been replaced by .dds. That would more or less restore the old package size. However, unless the issue is really pressing I would recommend waiting a while until it's all thoroughly bedded in. I also see that new aircraft have been added to fgdata. Tim requested a while back that new aircraft should be placed in their own repo. Doing this should prevent the data from growing significantly. We could move existing aircraft to their own repos bit by bit which will significantly reduce the size of fgdata. Vivian -Original Message- From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 10 September 2011 15:39 To: FlightGear developers discussions Subject: [Flightgear-devel] substantial base package size increase I just noticed when I pushed out the latest developer snapshot build that our setup.exe size has grown from about 410 Mb to 500+ Mb. I think (?) this may be the new dds textures? I'm not making a judgement, or calling for a particular action here, but it might be worth thinking/discussing if there is a way to push the size back down, or are we ok with 500Mb+ (1/2 a Gb) on our setup.exe size? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
