Re: [Flightgear-devel] Future Weather System
Stuart, On Monday, August 01, 2011 21:51:16 Stuart Buchanan wrote: > I'm looking to see whether we should just have a single way to query > the ground elevation using the groundcache, and use that everywhere. See the lenghty explanation in the response to the weather system. > However, the AI call you quote specifically excludes the model itself, > and I need to determine how to do that using the groundcache. That is more or less simple: You need to traverse the scenegraph group nodes anyway. If you would just know the pointer to the own aircrafts top level group node, you can skip the own aircrafts subtree ... This holds for building a AI local ground cache for each AI model as well as for a single ground query using the bv-tree leafs. Greetings Mathias -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
Durk,
On Monday, August 01, 2011 11:18:02 Durk Talsma wrote:
> On 30 Jul 2011, at 21:31, Stuart Buchanan wrote:
> > So, I quickly wrote an alternative to the current Nasal system
> > geodinfo(), using the groundcache instead of the current scenery
> > method.
>
> This sounds very interesting: As far as I can tell, the AI system still
> makes use of scenery.get_elevation_m(), as shown in AIBase.cxx (line 516):
>
> 516 bool FGAIBase::getGroundElevationM(const SGGeod& pos, double& elev,
> 517const SGMaterial** material) const {
> 518 return globals->get_scenery()->get_elevation_m(pos, elev, material,
> 519model.get());
> 520 }
>
> I always thought that get_elevation_m would be using the ground cache
> itself, but apparently that is not the case? If so, it seems to me that
> changing the AI system to actually use the ground cache could yield
> another performance increase.
>
> If you have any pointers on how this could be changed in an efficient way,
> I'd be happy to hear about it. :-)
Ok, the lengthy explanation hof the ground cache works in the previous mail
might help to understand what you can do.
I think that using the bv-trees and the whole scenegraph would make sense for
the AI module. That is basically the same than what I would suggest as a
simple solution for the weather module.
Alternatively I can imagine to have each AI model have its own groundcache. In
this case somehow bigger than the very short time groundcache of the aircraft.
May be big enough to cover the movement of one AI model for some seconds. Then
during these few seconds - or as long as the aircraft is just sufficiently
inside the cache - make queries into the local cache.
Also, I hope to get that improoved with a seperate AI component in a HLA
federation.
Greetings
Mathias
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
Hi, On Saturday, July 30, 2011 21:31:37 Stuart Buchanan wrote: > > Hi Mathias, Sorry not to anser in time ... > > Presumably this is using the ground_cache rather code rather than the > > scenery.get_elevation_m() code that the Nasal system uses to to get > > geodinfo() > > > > If so, I'll see if there's a sensible way to expose this over the > > Nasal interface > > as an alternative to the current geodinfo() routine. > > > > Is there any reason not to simply use the ground_cache for the Nasal > > geodinfo() routine? They both seem to make elevation and material > > information available? Do not use the groundcache as such, as it is only valid near the aircraft. But you can use the the bv-trees in the userdata nodes for queries. This should be perfectly ok. > Comments? I have not checked the git source tree. But what are you doing at the c++ level? Mathias -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
Hi, On Thursday, July 14, 2011 11:04:50 thorsten.i.r...@jyu.fi wrote: > I can maybe tell you what I need. Currently, Local Weather uses terrain > info in three ways: > 1) a presampling routine gets gross features in the vicinity of the > aircraft, i.e. mean altitude, median altitude, max. altitude,... That's > now implemented by Torsten as C++ routine running in the background - I > don't know details and don't know if it would benefit > > > 2) convective clouds are placed based on both terrain type and elevation. > For convective (not any other) clouds, there is extra work running for > 2-30 seconds (dependent on number, terrain detail,...) in the background > at the rate of ~12 geodinfo() calls per frame (geodinfo is a rather > expensive operation - more than 25 per frame are simply out of the > question). > > 3) for the 3rd generation cloud-terrain model currently under development, > there's an additional need to probe elevation (but not terrain type) for > many cloud types - curently using geodinfo() as well > > 2) and 3) are among the most computationally intensive processes Local > Weather runs, simply because geodinfo() is expensive (though perhaps not > the most garbage-collection triggering ones). If that could be made much > faster, tile setup could be accelerated dramatically. > > I wouldn't actually need the exact altitude/terrain type at a given > location for weather - an approximation which gets me some elevation and > terrain type within, say, 100 m of the specified coordinates would be just > as good, especially if it comes faster. If it really accelerates by a > large margin, then it allows the setup of tiles to be essentially in a > single frame, so one can really restart the system without the user > noticing. Thanks for explaining. I will tell you what the ground cache is and how this relates to the scene graph: We have currently all our environment in the scene graph. For fast rendering it is required to have huge leaf nodes containing the actual geometry in the scene graph. Then there are these intersection tests with that special case ground elevation lookup. For this purpose you would like to have also a graph/tree like structure but with leaf nodes containing exactly one geometry primitive. One of these fast intersection structures is a bounding volume tree. Such a tree has usually leaf nodes containing just one geometry primitive. Which is just the opposite of what the gpu needs for rendering. So I decoupled these two structures somehow. I have put bv-trees of geometry into the userdata field of the scenegraph. So for the high level operations like tile loading, the scenery paging is used to load and get rid of the bv- trees. The whole intersectable scenery should be there in this form. Using this, you could already speed up ground queries by using these bv-tree leafs for intersection test leaf traversal. But for the actual aircraft I wanted to be able to do up to the order of 100-1000 intersection tests per timestep. To get that sufficiently fast, I built that ground cache: That is just a bv-tree of the near environment of the aircraft. This is computed by traversing the scenegraph, and collecting hose subparts of the leaf bv-trees that are within a few 10 to 100 meters away from the aircraft. Just as much to cover the whole possible travel distance given the current speed and position. Queries into this structure are extremely fast (~1e-6s - 1e-5s) on my development notebook. Building this substructure is usually about 1e-3s depending on its size. If there is no geometry in the groundcache, since we are flying too high, there is one single elevation query into the whole scenegraph that give the agl to give reasonable values. Special care must be taken for moving geometries like the Aircraft carrier. Ground type information is stored in the scenegraph and referenced by the bv- tree. So, no matter how you query, if you do not have the ground type information, there is an implementation just not fetching it. This means using the ground cache is only valid near the actual aircraft, where near means a few 10 meters. And no, please do not increase this ground cache radius of the aircraft for the weather. What you can do for the weather is to traverse the bv-tree nodes instead of the GPU optimized scenery nodes for ground queries. I guess this is the fastest (implementation wise fastest) approach to get something you need. I still like the idea - only for the weather module - to have a cartesian grid as a 'weather ground cache'. To me this sounds like something which provides a litte more croase, but sufficieltly good approximations to scenery altitude. You could also average ground type information for your needs at the grid nodes - whereas you would just get singular ground types for traditional scene queries. Sure, this is much more work to set this up. In the future, I hope to have a completely independent weather module using th
Re: [Flightgear-devel] Future Weather System
On 02.08.2011 00:30, James Turner wrote: > Yes - I have wondered about separately loading the BTG files, but > that seems like a world of pain. In the first instance, simply having > the tiles loaded in the cache would be a reasonable start. The tile manager is capable of satisfying multiple requests. Anyone can give it a position, range and a timeout. It will then try to load all tiles in the range specified. And it will stop loading them after the timeout - unless you have updated the request with a new timeout. So you could tell it every 5 seconds that you're interested in a certain area around the aircraft, and use a timeout of 5,01 seconds. A matter of memory and loading speed though ;-). cheers, Thorsten -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
On 1 Aug 2011, at 22:35, Stuart Buchanan wrote: > In both cases, are you not going to be limited by what tiles have been loaded? Yes - I have wondered about separately loading the BTG files, but that seems like a world of pain. In the first instance, simply having the tiles loaded in the cache would be a reasonable start. James -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
On Mon, Aug 1, 2011 at 9:48 AM, James Turner wrote: > > On 30 Jul 2011, at 20:31, Stuart Buchanan wrote: > >> So, I quickly wrote an alternative to the current Nasal system geodinfo(), >> using the groundcache instead of the current scenery method. > > I'm working on a new (C++) navigation display instrument, which I hope to add > a proper EGPWS terrain display layer too - replacing Skyop's Nasal version, > with his full and happy consent :) > > I already reviewed the ground cache code, but I wan't sure how performant it > would be, to scan the ND range (eg, 80, 160 or 320nm) at, say, 10 or 50m > intervals. The problem is the EGPWS needs relative altitude to the aircraft, > but in real-life the update isn't instantaneous, especially at longer ranges, > so I expect to perform the scan incrementally over a few seconds. In both cases, are you not going to be limited by what tiles have been loaded? I did a further test just going in a straight line for 4 degrees in 0.001 degree increments, but only picked up some 400 points before both methods just start returning 0 elevation due to there being no tile loaded. FTR, I was seeing around 0.8s to make the 4000 queries using the old method, 0.045s with the new, so it's significantly faster in that case as well. -Stuart -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
On Mon, Aug 1, 2011 at 10:18 AM, Durk Talsma wrote:
> Hi Stuart,
> On 30 Jul 2011, at 21:31, Stuart Buchanan wrote:
>
>>
>> So, I quickly wrote an alternative to the current Nasal system geodinfo(),
>> using the groundcache instead of the current scenery method.
>>
>
> This sounds very interesting: As far as I can tell, the AI system still makes
> use of scenery.get_elevation_m(), as shown in AIBase.cxx (line 516):
>
> 516 bool FGAIBase::getGroundElevationM(const SGGeod& pos, double& elev,
> 517 const SGMaterial** material) const {
> 518 return globals->get_scenery()->get_elevation_m(pos, elev, material,
> 519 model.get());
> 520 }
>
> I always thought that get_elevation_m would be using the ground cache itself,
> but apparently that is not the case? If so, it seems to me that changing the
> AI system to actually use the ground cache could yield another performance
> increase.
>
> If you have any pointers on how this could be changed in an efficient way,
> I'd be happy to hear about it. :-)
I'm looking to see whether we should just have a single way to query
the ground elevation using the groundcache, and use that everywhere.
However, the AI call you quote specifically excludes the model itself,
and I need to determine how to do that using the groundcache.
-Stuart
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Newsletter - July 2011
Hi All, The July 2011 edition of the FlightGear Newsletter is now available: http://wiki.flightgear.org/FlightGear_Newsletter_July_2011 As always, we are looking for contributions to the next newsletter, available here: http://wiki.flightgear.org/FlightGear_Newsletter_August_2011 -Stuart -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear 2.4.0 data package
Am 01.08.2011 20:18, schrieb ThorstenB: > Hi, > > I checked the FG base package contents. It seems our build rule hasn't > been updated in a while. The following directories / files aren't > packed, though it would seem reasonable to include these: > > data/MP > data/HLA > data/runfgfs.bat > > Not sure about the latter - anyone still using this or is it really > obsolete (we have FGRun, I guess). But the MP directory should be packed > - and, Mathias, what about HLA? HLA is not enabled in our release because of the missing RTI. Let's keep the HLA subdir out of the base package for this time. Torsten -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.4.0: call for help in PR
NOTAM -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear 2.4.0 data package
Hi, I checked the FG base package contents. It seems our build rule hasn't been updated in a while. The following directories / files aren't packed, though it would seem reasonable to include these: data/MP data/HLA data/runfgfs.bat Not sure about the latter - anyone still using this or is it really obsolete (we have FGRun, I guess). But the MP directory should be packed - and, Mathias, what about HLA? cheers, Thorsten -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.4.0: call for help in PR
for pilots: A new FG plane is coming with an updated flight deck, more real weather, more fog and RVR, more realistic in dynamics.. U can still fly however u want wherever u want.. and do it better.. for city: The FG development is gonna kill the market, its basically a drop in replacement for M$ sim who we licenced all out liveries and data and everything to. This is a step change like android is to apple.. companing a u cumber to a turnip. oranges and pears.. same game a market changer.. recoomend Buy++ FG Sell-- Xbox for competitors: How did they do that.. ohh thats how they did it.. for Slashdot: Please do not click this linkbut its basically a new flighrgear2.4 with osg and its foss, pilot is a penguin, an apple or a ball head. - Announcement - Hello this is the FG captain speaking. I'm just informing you that on the return flight we might be delayed. The reason for the delay is that we need to install a new aircraft whcih is better that the one your on now.. The new aircraft will have more features for passengers such as more clouds and urban landscape.. For us pilots up front, we'll have a more realistic cockpit, better emulation of dodgy radio signals and less RVR with cloud density.. and other tounge in cheek.. -- <-- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On 01.08.2011 14:24, James Turner wrote: > > On 1 Aug 2011, at 12:30, Csaba Halász wrote: > >> Indeed, I have been unable to run FG with particles enabled since a >> long time due to random crashes in the particle code. Call stack >> frequently included functions your description mentions, so I hope >> this patch will fix that issue. > > Can anyone think of a reason particles are fine for some (many?) people > without this patch? Of course the patch should be applied, I'm just wondering > what would affect the ref-counting logic to hide the problem in some machines > / environments. The issue only shows when particles are enabled and an aircraft is actually using them - which already reduces the number of users ;-). I actually had it disabled for a long time. After enabling it recently, I also started having memory issues - on shutdown though. So that patch comes handy. The particular code has been there since the beginning of the module. Another, similar issue was fixed a while ago (http://www.gitorious.org/fg/simgear/commit/29aad066f0e57a04649b92083c4be7c6d490de31) but the property reference issue was overlooked. My guess is that there's usually no problem since the referenced property would still be part of the main property tree (?) - and have a reference there. Only when the property is dropped from the tree, should an issue occur (which would well explain my shutdown issues - but not necessarily the startup issues...). cheers, Thorsten -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On Mon, Aug 1, 2011 at 2:24 PM, James Turner wrote: > > Can anyone think of a reason particles are fine for some (many?) people > without this patch? Of course the patch should be applied, I'm just wondering > what would affect the ref-counting logic to hide the problem in some machines > / environments. Deleted memory is not immediately overwritten, so maybe for lucky people the contents stay there longer. There are ways to force freed memory to be overwritten by some marker (such as 0xdf using dmalloc), could be worth a try. -- Csaba/Jester -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Release 2.4.0: call for help in PR
FlightGear 2.4.0 will be released in a bit more than two weeks from now. To reach a broad audience, I am looking for someone to write an announcement, initially in English. Also, very welcome are people able to translate this into their native language and distribute it to their local press/flightsim forum/newsletter/whatever. The writing should be finished not later than Sunday, 14th. The actual distribution of the announcement is scheduled for Monday, 15th and Tuesday, 16th. The new files will be made available at Wednesday, 17th. Having volunteers here is absolutely necessary. Without having anybody writing something, there will be no official announcement. Thank you Torsten -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
James wrote: > On 1 Aug 2011, at 12:30, Csaba Halász wrote: > > > Indeed, I have been unable to run FG with particles enabled since a > > long time due to random crashes in the particle code. Call stack > > frequently included functions your description mentions, so I hope > > this patch will fix that issue. > > Can anyone think of a reason particles are fine for some (many?) people > without this patch? Of course the patch should be applied, I'm just > wondering what would affect the ref-counting logic to hide the problem in > some machines / environments. > Particles work fine here - Windows/MSVC9 Vivian -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On 1 Aug 2011, at 12:30, Csaba Halász wrote: > Indeed, I have been unable to run FG with particles enabled since a > long time due to random crashes in the particle code. Call stack > frequently included functions your description mentions, so I hope > this patch will fix that issue. Can anyone think of a reason particles are fine for some (many?) people without this patch? Of course the patch should be applied, I'm just wondering what would affect the ref-counting logic to hide the problem in some machines / environments. James -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On Mon, Aug 1, 2011 at 5:41 AM, Ove Kåven wrote: > > If there are no other references, the prop_root is automatically > destroyed when sgLoad3DModel_internal returns, causing the memory to be > freed. So, later on, when OSG wants to do something with these > particles, the freed memory is referenced and causes a crash. Indeed, I have been unable to run FG with particles enabled since a long time due to random crashes in the particle code. Call stack frequently included functions your description mentions, so I hope this patch will fix that issue. Thank you. -- Csaba/Jester -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The state of things in Flight Gear
> From: thorsten.i.r...@jyu.fi > To provide the context: I wrote the above in response to pictures of Mars > (from Celestia) being posted and talk about Apollo missions, i.e. having > interplanetary missions in mind. (Jon actually knows that, because I > explained it later in the thread :-) ) - something which my wording > 'orbital flight' actually doesn't reflect. Yes - I wanted it to be understood that *Earth* orbital flight is possible. :-) > I will be convinced that stability is not an issue here if someone > demonstrates to me that a 4 month fast-forward running the simulation > at a factor 1.000.000 time acceleration gets you a few 100.000.000 km later > precisely where you're supposed to be. Gravitational slingshots require > an incredible precision - you can't be 100 km off at target. > > Cheers, > > * Thorsten Yes. Jon -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The state of things in Flight Gear
>> I think it's grossly unfair to mix these issues: Spaceflight requires >> to essentially write a space simulator. One of my first statements in >> the >> forum was: >> >> "Orbital flights opens a whole new can of worms besides the need for >> different rendering - completely different physics, completely different >> numerical stability issues,... basically you want to write a new orbital >> simulator, because the amount of stuff you can really use from a flight >> simulator is pretty small." > > At one time I thought this to be true, but it is not necessarily. We have > been working on JSBSim very hard over the past years (thanks to the > efforts > of Fröhlich, Coconnier, myself, and others) to make sure that JSBSim can > handle orbital dynamics properly - because if orbital dynamic are handled > properly, it's a good indicator that aircraft dynamics are, as well. We > can > now do a high altitude, high inclination, high-eccentricity, orbit (with > the > spacecraft rotating) and after one simulated day end up a few hundred > feet > from the spot in space where a well-regarded software tool (AGI's "STK" > product) says we should be. The dynamics of flight are not really > different > at all. Stability is not a problem. I would disagree with your statements > above and in fact my experience has been almost the opposite, except for > the > rendering problem, which I have no experience with. I have been > approached > to help with testing JSBSim with Outerra, however, and obviously they are > doing rendering very well from space to ground. To provide the context: I wrote the above in response to pictures of Mars (from Celestia) being posted and talk about Apollo missions, i.e. having interplanetary missions in mind. (Jon actually knows that, because I explained it later in the thread :-) ) - something which my wording 'orbital flight' actually doesn't reflect. I will be convinced that stability is not an issue here if someone demonstrates to me that a 4 month fast-forward running the simulation at a factor 1.000.000 time acceleration gets you a few 100.000.000 km later precisely where you're supposed to be. Gravitational slingshots require an incredible precision - you can't be 100 km off at target. Cheers, * Thorsten -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
> I'm not sure if increasing the tree count could trigger the same > problem. I've been flying with 8 times the default tree density for the last half year (I edited materials.xml) - apart from the (expected) general overall impact on framerate, I haven't seen any issues like second-long lags when (un)-loading terrain. I don't think there's a critical issue at the moment. Best, * Thorsten -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
Hi Stuart,
On 30 Jul 2011, at 21:31, Stuart Buchanan wrote:
>
> So, I quickly wrote an alternative to the current Nasal system geodinfo(),
> using the groundcache instead of the current scenery method.
>
This sounds very interesting: As far as I can tell, the AI system still makes
use of scenery.get_elevation_m(), as shown in AIBase.cxx (line 516):
516 bool FGAIBase::getGroundElevationM(const SGGeod& pos, double& elev,
517const SGMaterial** material) const {
518 return globals->get_scenery()->get_elevation_m(pos, elev, material,
519model.get());
520 }
I always thought that get_elevation_m would be using the ground cache itself,
but apparently that is not the case? If so, it seems to me that changing the AI
system to actually use the ground cache could yield another performance
increase.
If you have any pointers on how this could be changed in an efficient way, I'd
be happy to hear about it. :-)
Cheers,
Durk
--
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
On 30 Jul 2011, at 20:31, Stuart Buchanan wrote: > So, I quickly wrote an alternative to the current Nasal system geodinfo(), > using the groundcache instead of the current scenery method. I'm working on a new (C++) navigation display instrument, which I hope to add a proper EGPWS terrain display layer too - replacing Skyop's Nasal version, with his full and happy consent :) I already reviewed the ground cache code, but I wan't sure how performant it would be, to scan the ND range (eg, 80, 160 or 320nm) at, say, 10 or 50m intervals. The problem is the EGPWS needs relative altitude to the aircraft, but in real-life the update isn't instantaneous, especially at longer ranges, so I expect to perform the scan incrementally over a few seconds. James -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
> So, I quickly wrote an alternative to the current Nasal system > geodinfo(), > using the groundcache instead of the current scenery method. (...) > Comments? You just made me a rather happy person :-) That seems like a sizeable improvement in performance! One question - do the two methods have the same range? I might call the function for a spot 50 km away - dependent on visibility range, the terrain there may already be loaded or not, and my code deals with both possibilities - but if, say, the fast method would only work in a 10 km radius around the aircraft, that might be a problem. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
