Re: [Flightgear-devel] Future Weather System
Thorsten, You mentioned earlier that a lot of the performance issues would disappear if we could probe the terrain 100 times faster. I've been thinking about this for a while for ai traffic, skyop's moving map instrument, and weather. I'm thinking of storing some resolution of altitude data in the tile itself, making altitude queries very fast at the expense of a larger tile (in memory and disk). I'm just starting the work, but I would like any feedback on the idea. It may require some lod implementation if the base tile size gets too big. I've been thinking about trying to get osg paged lod working with a new sg bucket. Obviously, this is a huge undertaking, but I hope to get a proof of concept up and running in the next 6 months or so. On Jul 12, 2011 6:24 PM, "Vivian Meazza" wrote: > ThorstenB wrote > >> -Original Message- >> From: ThorstenB [mailto:bre...@gmail.com] >> Sent: 12 July 2011 22:40 >> To: FlightGear developers discussions >> Subject: Re: [Flightgear-devel] Future Weather System >> >> On 12.07.2011 23:11, Vivian Meazza wrote: >> > I would even sacrifice a few more fps for the sake of smoothness. >> > For me the main issue is not so much the framerate, as the way the >> framerate >> > is being delivered. >> >> Indeed. Frame rate is misleading - the number only has a meaning if all >> frames were guaranteed to be evenly spaced (like on a TV/display). But >> that's not guaranteed for FG, so ignore this number. >> >> In order to judge and compare visual quality, look at the worst-case >> delay in between two frames instead. If a single delay in between two >> frames is too high, the human eye immediately spots a "stutter". Doesn't >> help if all the other frames were produced at high rate. And if that >> stutter happens repeatedly (say every second), it's what limits visual >> quality. >> >> You can enable a better property to compare performance using "View" => >> "Show worst-case frame delay". It shows the longest delay in between two >> frames within the last second of simulation (lower left corner). The >> lower the number, the better. In order to maintain an acceptable 25Hz >> simulation, the frame delay must never exceed 40ms. >> Is anyone capable of running FlightGear with either global or local >> weather enabled with a frame spacing not exceeding 40ms? >> > > Local 60 - 120ms and anything in between ~ 40 fps indicated > Global 17 - 37ms ~ 75 fps indicated > > Both showed occasional excursions well outside these values. > > Using the Hurricane at EGMH and current METAR > > Vivian > > > > -- > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
ThorstenB wrote > -Original Message- > From: ThorstenB [mailto:bre...@gmail.com] > Sent: 12 July 2011 22:40 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Future Weather System > > On 12.07.2011 23:11, Vivian Meazza wrote: > > I would even sacrifice a few more fps for the sake of smoothness. > > For me the main issue is not so much the framerate, as the way the > framerate > > is being delivered. > > Indeed. Frame rate is misleading - the number only has a meaning if all > frames were guaranteed to be evenly spaced (like on a TV/display). But > that's not guaranteed for FG, so ignore this number. > > In order to judge and compare visual quality, look at the worst-case > delay in between two frames instead. If a single delay in between two > frames is too high, the human eye immediately spots a "stutter". Doesn't > help if all the other frames were produced at high rate. And if that > stutter happens repeatedly (say every second), it's what limits visual > quality. > > You can enable a better property to compare performance using "View" => > "Show worst-case frame delay". It shows the longest delay in between two > frames within the last second of simulation (lower left corner). The > lower the number, the better. In order to maintain an acceptable 25Hz > simulation, the frame delay must never exceed 40ms. > Is anyone capable of running FlightGear with either global or local > weather enabled with a frame spacing not exceeding 40ms? > Local 60 - 120ms and anything in between ~ 40 fps indicated Global 17 - 37ms ~ 75 fps indicated Both showed occasional excursions well outside these values. Using the Hurricane at EGMH and current METAR Vivian -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
On 12.07.2011 23:11, Vivian Meazza wrote: > I would even sacrifice a few more fps for the sake of smoothness. > For me the main issue is not so much the framerate, as the way the framerate > is being delivered. Indeed. Frame rate is misleading - the number only has a meaning if all frames were guaranteed to be evenly spaced (like on a TV/display). But that's not guaranteed for FG, so ignore this number. In order to judge and compare visual quality, look at the worst-case delay in between two frames instead. If a single delay in between two frames is too high, the human eye immediately spots a "stutter". Doesn't help if all the other frames were produced at high rate. And if that stutter happens repeatedly (say every second), it's what limits visual quality. You can enable a better property to compare performance using "View" => "Show worst-case frame delay". It shows the longest delay in between two frames within the last second of simulation (lower left corner). The lower the number, the better. In order to maintain an acceptable 25Hz simulation, the frame delay must never exceed 40ms. Is anyone capable of running FlightGear with either global or local weather enabled with a frame spacing not exceeding 40ms? cheers, Thorsten -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
> -Original Message- > From: thorsten.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] > Sent: 12 July 2011 09:18 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Future Weather System > > > What I'd really love to see in the mid-to-long-term range is some kind > > of unified weather system. It does not really make sense for an average > > user to have two systems to choose from. > > Well, there's also a reason - the different design philosophy - and at > some point you may want to consider that before you merge. > > If you compare a system that tries to understand atmospheric conditions > and terrain interaction with one that draws what you specify, then there > are pros and cons to each: > > * currently Global Weather guarantees (I think) that winds at a station > position are exactly as reported in the METAR string. Local Weather > computes the boundary layer wind slowdown locally dependent on terrain and > can't guarantee that the winds will work out - by the time a METAR is > received, the terrain at the station usually isn't even loaded and can't > be probed, so the system has to make a guess what the boundary effect at > the station location will be, and the wind at destination is only good up > to that guess (that could in principle be addressed by correcting the > guess once the terrain is loaded - it's just a nasty question of timing > and subtly changing interpolation points...). > > * same with cloud cover - if a system computes cloud placement dependent > on terrain type and altitude, you can't guarantee that the end result will > really be a 4/8 - it could come out 3/8 or 5/8 - again, it depends on > guessing a factor before doing the placement > > * on the other hand, if you place and drift clouds without terrain > interaction, they'll just go through a mountain and emerge on the other > side - isn't quite right either. If you compute winds without local > boundary layer effect, the boundary layer will be as effective on a > mountaintop as down in the valley - isn't correct either. > > Maybe I am lost in seemingly irrelevant detail - but I think there's a > good reason to have two systems dependent on what you need - either > accuracy with respect to weather reports, or some physics model of the > atmosphere interacting with the terrain. > > (There is of course a proper solution, which is a proper physics model of > atmosphere/terrain interaction - it's just computationally too heavy...). > > >> Do you see this as a problem with the 3D clouds generated by the Local > >> Weather system specifically, or 3D clouds in general? > > It's 3d clouds in general but the local weather has the biggest impact > > on frame rate. I think (better: guess) it's because Local Weather draws > > more cloudlets. It's getting worse btw. the closer one gets to a cloud > > and the more space on the monitor is occupied by a cloud. > > I'm not sure about what's different in multiple monitors, but: > > http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&start=345#p12442 > 0 > > (visual comparison with closed layers in METAR mode - Local Weather gets > almost 25% better framerate) > > In a single monitor setup, it's just not true that Global Weather is > generically faster. In equal Cumulus conditions, I observe about the same > performance hit (when slecting the same visual range to display clouds - > when I compare 55 km visibility with 20 km, naturally 20 km are better). > In overcast layers, I observe that Local Weather is sigificantly better - > sometimes twice as fast. > > I think cloudlets go the other way round - Stuart uses many (20-30 per > cloud) small cloudlets, whereas I use few large ones (typically 4-8) with > asymmetric rescaling to get the layering right. > > If the problem gets worse when a single cloud is in view, it could be down > to texture resolution - a single cloudlet texture used by Stuart is > probably 120x120 whereas some of my large Cu cloud lets are ~1024x512 - > that should give you a different performance footprint... Some people had > issues with GPU memory, in which case dds textures helped (didn't help for > me). > > Apart from that, I can't really guess what makes it worse with more > screens. > > So - future plans: > > Stuart has written a very nice interface from Nasal, which I plan to use. > Since that requires newly arranged texture sheets, I will ask some people > who have more experience with graphics software to help me re-extract > textures from my cloud photographs - at that stage, we can also > systematically test with dds vs. rgb and optimal resolution. > > My current understanding is (I haven't tested too much) that Stuart's > interface doesn't address issues which are related to number of cloudlets > or texture size - once a model is in the scene, these should be the only > difference. I can of course use the same clouds and textures as currently > in global weather, but then you run into the same performance and vi
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
On Tuesday, July 12, 2011 12:02:04 AM Emilian Huminiuc wrote:
> On Tuesday 12 July 2011 04:18:33 Hal V. Engel wrote:
> > On Monday, July 11, 2011 10:05:07 AM BARANGER Emmanuel wrote:
> > > have you tested the script of Pierre NEGRE ? :
> > > http://rene16.dyndns.org/run/ (import/export .AC for Blender 2.58)
> >
> > Where can this be found? The web page is in French (I think) and I don't
> > find any links to the AC3D plug-in. I thought that perhaps the plug-in
> > was availble as a native part of 2.58 but I just built blender svn and it
> > does not have any AC3D import/export support.
> >
> > Blender 2.5 has a better UI than 2.4 and I would like to be able to use
> > it for work on my models but the lack of AC3D support makes this
> > impossible.
> >
> > Hal
>
> Hal, try here
> http://rene16.dyndns.org/run/index.php?option=com_content&view=article&id=5
> 3&Itemid=61
>
> and then click io_scene_ac.
Found it and installed it. After I got it activated I tried importing some
simpler models. The import blows up with a bunch of python errors. So it
looks like we will need to wait for something that actually works.
>
> Btw. I've noticed you have gentoo, and that you upgraded to osg3. Have you
> got an ebuild for that?
> I've tried by modifying the existing 2.9.10 one, but it seems i've been
> missing some things, since most models were looking wrong :(.
I just copied the 2.9.10 ebuild from the gamerlay overlay to my local overlay
and renamed it. The only change I made was to comment out the cmake.patch
lines.
IE.
# src_prepare() {
# epatch "${FILESDIR}"/${PN}-cmake.patch
# }
My models look OK with this setup.
There is also a version bump request in the Gentoo bug tracker (365143) but it
has not been responded to other than it being assigned to the group that
handles gaming stuff. I bumped it for 3.0 about a week ago. It might actually
be faster to contact the person who does the gamerlay overlay since the most
recent version in portage is 2.8.3 which is rather old at this point. You
should consider voting for the bug.
By the way my current FG setup is crashing occationally. I am not sure of the
source of the crashes at this point. That is I don't know if the crashes are
related to the aggressive optimization or if they are OSG3 related or
something in the recent GIT versions of FG or simgear. I will try to sort it
out over the next few days.
Hal
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ac import/export for Blender 2.58 WAS: Re: Flightgear-devel Digest, Vol 63, Issue 5
Hi Alessandro, From what i have read, René is aware of the Blender procedure. Atm it goes this way because the script is still under development. Trying to find out all bugs and such before it get pushed to Blender. Little things needs to be fixed first ... :) It's his first Python script he made, but amazing work i think :) Regards, Itchi On Tue, 12 Jul 2011 12:24:01 +, TDO_Brandano - wrote: > Perhaps someone should mention to Renè the standard procedures to get a > script included in dthe official ones distributed along with Blender. The > page with the details is http://wiki.blender.org/index.php/Dev:Py/Sharing , > but I'd prefer if someone could translate this in a meaningful French and > contact him. > > Alessandro > [...] -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
Am 12.07.2011 10:18, schrieb thorsten.i.r...@jyu.fi: > > Well, there's also a reason - the different design philosophy - and at > some point you may want to consider that before you merge. Rest assured, there won't be any merge of the weather system without you ;-) > > If you compare a system that tries to understand atmospheric conditions > and terrain interaction with one that draws what you specify, then there > are pros and cons to each: I have to postpone this discussion to after the release which completely consumes all my time I am currently able to dedicate to fg. >>> Do you see this as a problem with the 3D clouds generated by the Local >>> [..] >> It's 3d clouds in general but the local weather has the biggest impact >> [..] > In a single monitor setup, it's just not true that Global Weather is > [..] The issue is with 3d-clouds. It's not a question of global/local weather. Because local weather relies on 3d clouds, it appears to be much slower than global weather with 3d clouds disabled. My conclusion is, that our current 3d cloud implementation does not scale very well with screen size. > > If the problem gets worse when a single cloud is in view, it could be down > to texture resolution - a single cloudlet texture used by Stuart is > probably 120x120 whereas some of my large Cu cloud lets are ~1024x512 - > that should give you a different performance footprint... Some people had > issues with GPU memory, in which case dds textures helped (didn't help for > me). Our four GTX460 have 2GB GPU memory, each. That's probably not the bottleneck. I hope I have some more time for discussing this in a just a few weeks. Thanks, Torsten -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ac import/export for Blender 2.58 WAS: Re: Flightgear-devel Digest, Vol 63, Issue 5
Perhaps someone should mention to Renè the standard procedures to get a script included in dthe official ones distributed along with Blender. The page with the details is http://wiki.blender.org/index.php/Dev:Py/Sharing , but I'd prefer if someone could translate this in a meaningful French and contact him. Alessandro > To: flightgear-devel@lists.sourceforge.net > Date: Tue, 12 Jul 2011 13:46:16 +0200 > From: david.van.mosselb...@telenet.be > Subject: [Flightgear-devel] ac import/export for Blender 2.58 WAS: Re: > Flightgear-devel Digest, Vol 63, Issue 5 > > > On Mon, 11 Jul 2011 22:15:18 -0400, Rob Dosogne > wrote: > > http://rene16.dyndns.org/blender/io_scene_ac.tar.gz > > > > On Mon, Jul 11, 2011 at 21:18, Hal V. Engel wrote: > >> On Monday, July 11, 2011 10:05:07 AM BARANGER Emmanuel wrote: > >> > >>> have you tested the script of Pierre NEGRE ? : > >> > >>> http://rene16.dyndns.org/run/ (import/export .AC for Blender 2.58) > >> > >> Where can this be found? The web page is in French (I think) and I > don't > >> find any links to the AC3D plug-in. > > Fyi, > There is also some French development topic about this [1]. > Which could be really of some interest. The website of René (author of the > script for 2.58), is meant to be a trackback website, to log progress, > download link etc. So it's also the place to watch :) > > [1] > http://equipe-flightgear.forumactif.com/t533-importer-exporter-des-ac-dans-blender-25-cela-vous-tente > > Regards, > Itchi > > > > -- > 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-d2d-c2 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ac import/export for Blender 2.58 WAS: Re: Flightgear-devel Digest, Vol 63, Issue 5
On Mon, 11 Jul 2011 22:15:18 -0400, Rob Dosogne wrote: > http://rene16.dyndns.org/blender/io_scene_ac.tar.gz > > On Mon, Jul 11, 2011 at 21:18, Hal V. Engel wrote: >> On Monday, July 11, 2011 10:05:07 AM BARANGER Emmanuel wrote: >> >>> have you tested the script of Pierre NEGRE ? : >> >>> http://rene16.dyndns.org/run/ (import/export .AC for Blender 2.58) >> >> Where can this be found? The web page is in French (I think) and I don't >> find any links to the AC3D plug-in. Fyi, There is also some French development topic about this [1]. Which could be really of some interest. The website of René (author of the script for 2.58), is meant to be a trackback website, to log progress, download link etc. So it's also the place to watch :) [1] http://equipe-flightgear.forumactif.com/t533-importer-exporter-des-ac-dans-blender-25-cela-vous-tente Regards, Itchi -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
http://rene16.dyndns.org/blender/io_scene_ac.tar.gz On Mon, Jul 11, 2011 at 21:18, Hal V. Engel wrote: > On Monday, July 11, 2011 10:05:07 AM BARANGER Emmanuel wrote: > >> have you tested the script of Pierre NEGRE ? : > >> http://rene16.dyndns.org/run/ (import/export .AC for Blender 2.58) > > Where can this be found? The web page is in French (I think) and I don't > find any links to the AC3D plug-in. -- Rob -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
> What I'd really love to see in the mid-to-long-term range is some kind > of unified weather system. It does not really make sense for an average > user to have two systems to choose from. Well, there's also a reason - the different design philosophy - and at some point you may want to consider that before you merge. If you compare a system that tries to understand atmospheric conditions and terrain interaction with one that draws what you specify, then there are pros and cons to each: * currently Global Weather guarantees (I think) that winds at a station position are exactly as reported in the METAR string. Local Weather computes the boundary layer wind slowdown locally dependent on terrain and can't guarantee that the winds will work out - by the time a METAR is received, the terrain at the station usually isn't even loaded and can't be probed, so the system has to make a guess what the boundary effect at the station location will be, and the wind at destination is only good up to that guess (that could in principle be addressed by correcting the guess once the terrain is loaded - it's just a nasty question of timing and subtly changing interpolation points...). * same with cloud cover - if a system computes cloud placement dependent on terrain type and altitude, you can't guarantee that the end result will really be a 4/8 - it could come out 3/8 or 5/8 - again, it depends on guessing a factor before doing the placement * on the other hand, if you place and drift clouds without terrain interaction, they'll just go through a mountain and emerge on the other side - isn't quite right either. If you compute winds without local boundary layer effect, the boundary layer will be as effective on a mountaintop as down in the valley - isn't correct either. Maybe I am lost in seemingly irrelevant detail - but I think there's a good reason to have two systems dependent on what you need - either accuracy with respect to weather reports, or some physics model of the atmosphere interacting with the terrain. (There is of course a proper solution, which is a proper physics model of atmosphere/terrain interaction - it's just computationally too heavy...). >> Do you see this as a problem with the 3D clouds generated by the Local >> Weather system specifically, or 3D clouds in general? > It's 3d clouds in general but the local weather has the biggest impact > on frame rate. I think (better: guess) it's because Local Weather draws > more cloudlets. It's getting worse btw. the closer one gets to a cloud > and the more space on the monitor is occupied by a cloud. I'm not sure about what's different in multiple monitors, but: http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&start=345#p124420 (visual comparison with closed layers in METAR mode - Local Weather gets almost 25% better framerate) In a single monitor setup, it's just not true that Global Weather is generically faster. In equal Cumulus conditions, I observe about the same performance hit (when slecting the same visual range to display clouds - when I compare 55 km visibility with 20 km, naturally 20 km are better). In overcast layers, I observe that Local Weather is sigificantly better - sometimes twice as fast. I think cloudlets go the other way round - Stuart uses many (20-30 per cloud) small cloudlets, whereas I use few large ones (typically 4-8) with asymmetric rescaling to get the layering right. If the problem gets worse when a single cloud is in view, it could be down to texture resolution - a single cloudlet texture used by Stuart is probably 120x120 whereas some of my large Cu cloud lets are ~1024x512 - that should give you a different performance footprint... Some people had issues with GPU memory, in which case dds textures helped (didn't help for me). Apart from that, I can't really guess what makes it worse with more screens. So - future plans: Stuart has written a very nice interface from Nasal, which I plan to use. Since that requires newly arranged texture sheets, I will ask some people who have more experience with graphics software to help me re-extract textures from my cloud photographs - at that stage, we can also systematically test with dds vs. rgb and optimal resolution. My current understanding is (I haven't tested too much) that Stuart's interface doesn't address issues which are related to number of cloudlets or texture size - once a model is in the scene, these should be the only difference. I can of course use the same clouds and textures as currently in global weather, but then you run into the same performance and visual issues (i.e. cloudlets are too small to effectively form layers, no developed Cu or Cb clouds, ...). What the system will most likely do is * improve loading times * provide a conceptually clean interface * move clouds in the wind almost for free In principle, one could try to code terrain interaction into here as well - but as I said, moving clouds interacting with the terrain opens a can
Re: [Flightgear-devel] AI Aircraft or Airship WAIT command
Chelley, The 'WAIT' token is only implemented for ships and ground vehicles. Vivian -Original Message- From: Chelley [mailto:chel...@mypostoffice.co.uk] Sent: 11 July 2011 18:45 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] AI Aircraft or Airship WAIT command I have seen the WAIT function working for trains in AI models and have had partial success in some scenarios but it is not working at the start of an AI scenario. Could someone advise me on this please ? Here is my PASTEBIN below using: WAIT 3600 Is their another way of doing this for example in the top level AI script before the flightplan is launched ? http://pastebin.com/SCr2Xi2z All the best Aerotro _ This email has been scanned by Netintelligence http://www.netintelligence.com/email _ -- 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-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI layout improvements
> I also wonder if the terms "global" and "local" are really applicable. > Would > "static weather modeling" and "dynamic weather modeling be better terms, > or how about simple/complex? I guess the key differences in philosophy are: * terrain interaction: clouds in Local Weather 'know' terrain type and elevation underneath and react to it, clouds in global weather don't * locality: weather phenomena in Local Weather are genuine local things - you can see rain underneath a cloud from the outside, fly there across a visible border and get wet and fly out again. Can't do using global weather. Also true for e.g. pressure which is interpolated - wasn't so in global weather a while ago, but is now, and the systems have become more similar here * (some overlap with the first point) physics: Local Weather tries to implement an (admittedly crude) model of atmospheric physics and dynamics, Global Weather renders what you specify without trying to make too much sense of it I don't think 'static' vs. 'dynamic' are good labels, I would apply these to how much things change in time, and as compared to the last release, Global Weather has now the interpolation of METAR as well as moving 3d clouds, i.e. a fair share of dynamics. 'simple' and 'complex' would work for me, although it's a bit of an injustice to the 'global' system as it isn't really that simple either. I'm not particularly attached to the current labels, but whatever we choose should capture the essentials. > I think this "launcher" aspect is something that we want to hide from the > end-user. Most people just want to be able to change the weather > system and then press Apply or OK. Having to press "Stop" first is very > different from the rest of the UI. > > I think we'll want to make this implicit, so the user can press (say) > Apply, and > the underlying weather system stops and then is started under the covers > with the new parameters. You can do this, but there'll be a price to pay: The user also expects that he can 'just' change the wind, press okay and it's done without waiting half a minute - but that's not true. The reason is that with terrain interaction you open a can of worms, and especially with moving clouds over time it gets worse an order of magnitude - you need tons of computations in the background - which is no problem as they can be split over many frames, the system just doesn't start or change in a hurry. Take my current project - 3rd generation cloud/terrain interaction http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&start=375#p129648 Each cloud placement takes into account terrain gradient at kilometer scale, terrain elevation, terrain type, wind direction, windspeed and time of the day. If you change the wind, the whole picture changes. You just spent ~1500 frames getting to what you see (which by the way I think is acceptable at startup, as you'd usually start your engines and go through your procedures anyway, so you don't need full framerates). If you change 'just' the wind and press okay, you can implicitly restart the system - it's just going to delete everything and recompute for 1500 frames - there's no way to hide that unless you make probing the terrain a factor 100 faster. So if you can't hide the fact that you have to restart everything, in my view the user is going to be less disappointed if he realizes that he has to restart everything than if the system pretends you can just change parameters and be done with it. > Apart from the stop/start time (which could be handled by a "please wait" > message), is there any reason we couldn't do this? Psychology. In my view it's bad to give the user a false impression. Not realizing it's a full restart, a user will be disappointed that it takes that long to change the wind. Having the info that it's a full restart, he's more likely to accept it. (I see myself waiting at the gate at an airport. Being told that I have to wait foran unspecified amout of time just makes me angry. Being told that there is a severe storm at my destination and we can't land, but if we wait for 2 more hours so that it can be expected to have passed by the time we arrive, I'm fine.) > I think 90% of users are going to struggle to understand what most of > these settings mean. Well, it's a complex system, so its configuration reflects some of the complexity, an it comes with a manual... If some user tells you 'I have trouble to understand what all these gauges in the cockpit of the c172 mean' - do you simplify the cockpit, or do you ask him to read the manual where it is explained? I'd be happy with a limited number of options - but many users can't run the system well with the set of options I like - and that was the point when I started exposing properties so that the system can be customized individually. I took the time to document every option and most algorithms in 42 pages of manual (out of which you are free to read what you need - the description of what a particular
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
Melchior, there have been very, very few cases where I applied bug fixes to an aircraft directly, when I thought the fix was absolutely trivial - and was absolutely sure, that the author could impossibly disapprove the fix in general, neither disapprove the particular way of fixing the issue. Like this example: http://www.gitorious.org/fg/fgdata/commit/20f4ea93e9bcb2a2d10cec47165541f378cab118 In this case, the author didn't feel disrespected, welcomed the trivial change (as can be seen from the gitorious reply). Few days later, same aircraft/author, I noticed another, almost equally simple issue - but since it wasn't clear whether a single XML line was to be commented out, or a file (known to originate from another a/c) was forgotten to be copied, I even created a bug report: http://code.google.com/p/flightgear-bugs/issues/detail?id=363 So, I don't think I'm "messing" with other people's aircraft. Neither do I place "trojans" or the like. I have always contacted aircraft authors before any substantial change. Also, I generally document commits well - making it easy to track, knowing that particular authors/developers monitor change logs closely. This was another reason why I hadn't sent Gijs an email for the first issue, since I knew he'd see the commit anyway - so I spared extra mail for an incredibly simple change. Events and similar circumstances like the above may have caused me to believe, that the commit in question, which I thought to be almost equally trivial, making the bo105 usable after a sim reset, would be highly appreciated as a constructive contribution by the author - especially being close to the release. I had not thought it possible, that this could lead anyone to feel disrespected. I was all wrong here. Melchior, I apologize for touching your aircraft. I had not intended to question your author-/ownership over the helicopter. Of course, you're welcome to revert the patch, especially if you think this is in any way contradicting your original intentions or schedule. With that, and a link to the actual commit that caused the outrage, I'd like to conclude this topic from my part. http://www.gitorious.org/fg/fgdata/commit/0b8dee0f4611f0e90478f48d58951995fbe87069 cheers, Thorsten -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
On Tuesday 12 July 2011 04:18:33 Hal V. Engel wrote: > On Monday, July 11, 2011 10:05:07 AM BARANGER Emmanuel wrote: > > have you tested the script of Pierre NEGRE ? : > > http://rene16.dyndns.org/run/ (import/export .AC for Blender 2.58) > > Where can this be found? The web page is in French (I think) and I don't > find any links to the AC3D plug-in. I thought that perhaps the plug-in > was availble as a native part of 2.58 but I just built blender svn and it > does not have any AC3D import/export support. > > Blender 2.5 has a better UI than 2.4 and I would like to be able to use it > for work on my models but the lack of AC3D support makes this impossible. > > Hal Hal, try here http://rene16.dyndns.org/run/index.php?option=com_content&view=article&id=53&Itemid=61 and then click io_scene_ac. Btw. I've noticed you have gentoo, and that you upgraded to osg3. Have you got an ebuild for that? I've tried by modifying the existing 2.9.10 one, but it seems i've been missing some things, since most models were looking wrong :(. -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
