Re: [Flightgear-devel] Lat Lon vs. Deg Min
Am 29.07.11 15:18, schrieb HB-GRAL: > Am 29.07.11 12:15, schrieb Durk Talsma: >> Hi, >> >> On 29 Jul 2011, at 02:54, HB-GRAL wrote: >> >>> Hi Geos >>> >>> Can someone explain me why we use >>> >>> lat="N37 42.807" >>> lon="W122 12.963" >>> >>> in parking.xml and groundnet.xml >>> >> >> This is mainly for historic reasons. I started out using an example ground >> network file that was made using an editing tool that was originally created >> to MSFS, if I recall correctly. FlightGear groundnet support was developed >> from that example file, and the taxidraw export functions were in turn >> developed from this as well. >> >> If you have a need to change that, please let me what and how you would like >> this to be changed. We do need to keep some compatibility with the current >> format, but I don't think that it's would be too hard to make flightgear >> distinguish a two number format containing (NEWS keywords, vs a single >> decimal floating point number). I would be open to changing that. >> >> cheers, > > Hi Durk and Ron > > Thanks for replying here. My problem is the precision when I convert > this values to lat-lon. How does fgfs convert this values to lat lon and > what is the precision you should get with this values ? > > Thanks, Yves Hi again, I got more precision now by changing the calculation a bit. But when you decide once to have the same lat/lon values (degrees decimal) everywhere (tower, threshold, parking), would be very nice. Cheers, Yves Thanks, Yves -- 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
> However, I don't think my change will have affected this. > > While the number of trees displayed is increased, the total number > of trees in the scenery is unaffected, it's just that more of those > trees are visible at any given time. > > I'm also not sure if the tree model is shared in this way. It's not > really a model > in the .ac sense anyway. I just merged it into next. Let's give it a try before the leaves begin to fall ;-) 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] Flightgear-devel Digest, Vol 63, Issue 14
Le 29/07/2011 09:26, flightgear-devel-requ...@lists.sourceforge.net a écrit : > -- > > Message: 13 > Date: Thu, 28 Jul 2011 19:20:06 +0400 > From: Slavutinsky Victor > Subject: Re: [Flightgear-devel] The state of things in Flight Gear > To: flightgear-devel@lists.sourceforge.net > Message-ID: <1311866406.6611.69.camel@ubunted> > Content-Type: text/plain; charset="UTF-8" > You do not get the point entirely and completely. > > I had said what on my deepest thoughts current chaos in Flight Gear > project will lead everybody to problems what I had experienced with > Vostok project pretty soon. > > Occasional dropouts and slowing to 1fps and things as that. More and > more bugs with every change what's harder and harder to eliminate, not > linearly, squarely harder. Dramatical lowering of common development > rate, coming to "very outdated" state and loosing of new developers and > users inflow, then final stopping. That's what, I suppose, awaits > everybody on current FG path. > > I am sure what only way to avoid that drama is bringing everything in FG > in order. The sooner we start to bring it in order the better. I am > leaving because no one wants to do it, I can not do it alone, and I > suppose when it'll come to serious problems it will be too late for > anyone. So I do not want to make things what no one will really use bit > later than two years after now. > > Look. Working hard on falling plane it's may be heroic, but if it is not > work what pointed on stop of falling then it's very foolish too. I do > not blame no one. I only tell, guys, I feel that plane starts to fall, > no one on yoke, You do not want me to take control and do not want to > take control Yourself, so I balling out, I have chute as things what I > can make instead of FG. > > You may count me crazy but check number of errors and time of its > solution time changing please. You had received idea how You may do it. > > Or You can do nothing about that, treat me as some offended guy who > leaving because no one wants to act as he want. Ok, it's You right to do > so, and of course it would be easier for most of guys here if it was > that way, and for me it does not matter, I had ejected already anyway. > But do not blame me when it'll come to state I had talked You about in > time I had named. I do not want and do not press that way of events > developing, I only foresee it as ejected pilot foresee trajectory of > falling plane. I did all I could. You had been warned. Bye bye. Hi all, Here is a tiresome and uninteresting discussion. Victor, you confuse a particular problem (which affects you personally) and the general interest of FG. Speaking of delays in FG, for example, your Vostok is absolutely not a good example. Your model is gorgeous. But absolutely not optimized. It is a 3D has nothing to do in a real time 3D engine such as FG. So, before you give lessons to people of good will and all friendly, it might be good to review your copy. Humility is also very useful in open source projects. Your model may be divided by 3 or 4 in size, number of points, number of facets, without losing its quality first. And you will discover, magically, the FPS back in FG. To criticize others as you did, you must first be beyond reproach. And it's not the case ! Martin, Stuart, Tim and others know what they do and do it with their hearts. If only one person is unhappy, then the problem is with this person. This is unstoppable. -- BARANGER Emmanuel http://helijah.free.fr -- 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
On Fri, Jul 29, 2011 at 6:21 PM, ThorstenB wrote: > On 28.07.2011 00:30, Stuart Buchanan wrote: >> On my machine I don't see any performance impact, despite the fact >> that more trees are displayed. I'd appreciate it if those with more >> graphics-constrained systems than my own would test this and let me >> know if they think the frame-rate hit is acceptable given the >> improvements in apparent tree coverage. > > Not sure if trees were also affected, but I remember a very ugly issue > from last year. OSG is quick in sharing a single object multiple times > into the a scenery ( O(1) ), but removing such a shared object is very > expensive. OSG uses a single thread for loading and removing. Dropping a > scenery area with an object shared a few thousand times only took a > fraction of a second. But when the number of shares increased even > further, then suddenly the OSG "database" thread blocked for minutes - > while no new scenery could be loaded. O(n^2) bites you eventually. > That's why we reduced or got rid of cattle, horse, ... objects scattered > across the scenery. > I'm not sure if increasing the tree count could trigger the same > problem. And no idea if OSG3 has improved on this issue. > > The problem is only observed after the tile cache is full, so scenery > tiles need to be dropped from memory for the first time. > A good way for testing is to take the UFO and race at maximum speed > across the scenery. Make sure scenery tiles keep continually loading and > appearing at the same speed - so that even after a few minutes of > flying, loading doesn't get blocked and you're flying into the void. Good to know. However, I don't think my change will have affected this. While the number of trees displayed is increased, the total number of trees in the scenery is unaffected, it's just that more of those trees are visible at any given time. I'm also not sure if the tree model is shared in this way. It's not really a model in the .ac sense anyway. -Stuart -- 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
On 28.07.2011 00:30, Stuart Buchanan wrote: > On my machine I don't see any performance impact, despite the fact > that more trees are displayed. I'd appreciate it if those with more > graphics-constrained systems than my own would test this and let me > know if they think the frame-rate hit is acceptable given the > improvements in apparent tree coverage. Not sure if trees were also affected, but I remember a very ugly issue from last year. OSG is quick in sharing a single object multiple times into the a scenery ( O(1) ), but removing such a shared object is very expensive. OSG uses a single thread for loading and removing. Dropping a scenery area with an object shared a few thousand times only took a fraction of a second. But when the number of shares increased even further, then suddenly the OSG "database" thread blocked for minutes - while no new scenery could be loaded. O(n^2) bites you eventually. That's why we reduced or got rid of cattle, horse, ... objects scattered across the scenery. I'm not sure if increasing the tree count could trigger the same problem. And no idea if OSG3 has improved on this issue. The problem is only observed after the tile cache is full, so scenery tiles need to be dropped from memory for the first time. A good way for testing is to take the UFO and race at maximum speed across the scenery. Make sure scenery tiles keep continually loading and appearing at the same speed - so that even after a few minutes of flying, loading doesn't get blocked and you're flying into the void. 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] Future Weather System
2011/7/14 Mathias Fröhlich wrote: > While being able to do a croase ground query on such a kind of regular grid > might be beneficial for the weather module. I would prefer the ai module just > using the already available bounding volume tree that is used for the main > aircrafts elevation queries. This is already really fast. > Also, may be making use of these bounding volume hierarchies for the weather > module as an intermediate step might be a good idea? Hi Mathias, 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? -Stuart -- 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] Lat Lon vs. Deg Min
Am 29.07.11 12:15, schrieb Durk Talsma: > Hi, > > On 29 Jul 2011, at 02:54, HB-GRAL wrote: > >> Hi Geos >> >> Can someone explain me why we use >> >> lat="N37 42.807" >> lon="W122 12.963" >> >> in parking.xml and groundnet.xml >> > > This is mainly for historic reasons. I started out using an example ground > network file that was made using an editing tool that was originally created > to MSFS, if I recall correctly. FlightGear groundnet support was developed > from that example file, and the taxidraw export functions were in turn > developed from this as well. > > If you have a need to change that, please let me what and how you would like > this to be changed. We do need to keep some compatibility with the current > format, but I don't think that it's would be too hard to make flightgear > distinguish a two number format containing (NEWS keywords, vs a single > decimal floating point number). I would be open to changing that. > > cheers, Hi Durk and Ron Thanks for replying here. My problem is the precision when I convert this values to lat-lon. How does fgfs convert this values to lat lon and what is the precision you should get with this values ? Thanks, Yves -- 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 [mailto:] > > 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. > ... > > I still think that is a correct statement (up to the part that JSBSim > seems adequately equipped to get ascent and descent right, although we > don't know about long-term orbital stability - which wasn't clear to me > when I wrote it)- so from where I am standing, you are claiming that > Flightgear development is failing based on the observation that people > could not write a spaceflight simulation in 6 months or tell you how to > do that. > > Just my two cents. > > * Thorsten Given the criticisms of our high-altitude atmosphere model from previous discussions, I went ahead and revamped our atmosphere model. It's still a work-in-progress, but the atmosphere model should eventually be much more realistic at higher altitudes, and be useful for some limited spaceflight use. I have no idea how well a re-entering spacecraft will track along the expected trajectory, though. That remains to be seen. Personally, I would like to see FlightGear to be made usable for orbital flight, but I can imagine that would be a lot of work. 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] Lat Lon vs. Deg Min
Hi, On 29 Jul 2011, at 02:54, HB-GRAL wrote: > Hi Geos > > Can someone explain me why we use > > lat="N37 42.807" > lon="W122 12.963" > > in parking.xml and groundnet.xml > This is mainly for historic reasons. I started out using an example ground network file that was made using an editing tool that was originally created to MSFS, if I recall correctly. FlightGear groundnet support was developed from that example file, and the taxidraw export functions were in turn developed from this as well. If you have a need to change that, please let me what and how you would like this to be changed. We do need to keep some compatibility with the current format, but I don't think that it's would be too hard to make flightgear distinguish a two number format containing (NEWS keywords, vs a single decimal floating point number). I would be open to changing that. 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] The state of things in Flight Gear
> It's a dead end time when someone who had asked for changes leaves > before that changes comes because it not comes too long and that makes > some issue area related development impossible. (...) > If that dead end will come seventy years after now then for sure I had > missed the point. If not then not and some quick reaction is needed > immediately right now before it will get too far. (...) > I had said what on my deepest thoughts current chaos in Flight Gear > project will lead everybody to problems what I had experienced with > Vostok project pretty soon. (...) > Occasional dropouts and slowing to 1fps and things as that. More and > more bugs with every change what's harder and harder to eliminate, not > linearly, squarely harder. Dramatical lowering of common development > rate, coming to "very outdated" state and loosing of new developers and > users inflow, then final stopping. That's what, I suppose, awaits > everybody on current FG path. If I understand you correctly, the reason you are leaving is that you worry that the future state of the project will be such that it can't be fixed, because the time to fix errors grows quadratically (in what? lines of code?time?), and you want to leave before that happens. I remember when discussing a terrain rendering engine capable of spaceflight in the forum, a user named vitos wrote the following: "Boris Elyseyevitch Chertok, who had and have essential role in real Russian Space Program, and particularly in Vostok program, had said many times: 'If today someone would put before us Vostok and ask us for permission to let it fly then no one of us would vote for that. That day we all had vote for it without a doubt.' We would never get somewhere in case we would though about distant future problems. Those problems does not matter because it unexisted until we not solve current." It strikes me that worrying about things like what happens if 500+ users go on a multiplayer server of if the time to fix a bug grows to several months is very much worrying about distant future problems. What happened to that user named vitos - did he change his views? But the whole argument is misleading when based on Vostok-1 - with Vostok-1, you are observing issues which are not bugs in the current system to be addressed or issues to be fixed - you are using an existing system outside its design specification. Flightgear makes a lot of assumptions which are entirely reasonable for aircraft (i.e. you move with a finite speed, at altitudes below 120.000 ft, the gravitational field of the moon doesn't matter,...) - e.g. the loading of terrain (or of weather in my case) assumes that you move with the speed of an aircraft - at arbitrary velocities, you can outrun both systems (as easily tested with the ufo). There is nothing to 'fix' here to use Vostok as you intend - you have to scrap and redesign systems, and that takes way longer than to fix an existing system while leaving its structure largely intact (I have been saying that all along in the forum) - even provided you find the volunteers to do it here. There's no evidence to me that other aircraft will ever create similar problematic issues, while other spacecraft will always create them. Vostok is a special case, because it demands things from the system which no aircraft will ever even in principle demand - for that reason it's not a reasonable litmus test. A singularly complex problem doesn't reflect the general state of affairs. As for growing complexity - it's generically true that the time to fix an issue grows non-linear with the number of code lines. But as Microsoft is all too happy to demonstrate, that doesn't really correlate with the structure of project management. On the other hand, the code seems pretty modular. I observe in debugging my 10.000 lines of Local Weather that there are large parts which are simply stable - they have been checked to the degree that they work free of bugs, so the actual amount of lines I have to consider to address an issue is usually much smaller than 10.000. At least that project does not seem to run into longer and longer debugging times. 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." I still think that is a correct statement (up to the part that JSBSim seems adequately equipped to get ascent and descent right, although we don't know about long-term orbital stability - which wasn't clear to me when I wrote it)- so from where I am standing, you are claiming that Flightgear development is failing based on the observation that people could not write a spacef
