FlightGear - Flight Simulator

On Thursday 28 July 2011 18:54:21 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
>
> and not lat/lon formats like we use it for runways and it is used in
> apt.dat and other data files ?
>
> Thanks, Yves

Because parking.xml/groundnet.xml predates everthing else, but decimal degrees 
are much nicer to work in. 

Ron

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

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

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

>  > TreeBin* treebin;
>
>  > SGTreeBinList::iterator j;
>
>  > bool found = false;
>
>  >
>
>  > for (j = randomForest.begin(); (j != randomForest.end()) && (!found);
>
>  > j++) {
>
>  > if (((*j)->texture == mat->get_tree_texture() ) &&
>
>  > ((*j)->texture_varieties == mat->get_tree_varieties()) &&
>
>  > ((*j)->range == mat->get_tree_range() ) &&
>
>  > ((*j)->width == mat->get_tree_width() ) &&
>
>  > ((*j)->height == mat->get_tree_height() ) ) {
>
>  > treebin = *j;
>
>  > found = true;
>
>  > }
>
>  > }
>
>
> It appears that SGTreeBinList is a list of pointers to some structure.
> If that is the case then you need to dereference two pointers to get
> stuff from the structure since the iterator, j, is a pointer. Thus you
> get *j->texture - *j dereferences j and -> dereferences the pointer
> pointed to by j. I don't think that you gain anything by writing this as
> (*j)->texture since this is basically the same thing as *j->texture. IMO
> *j->texture is easier to read.

But doesn't work. -> has higher precedence than *.
*j->texture is interpreted as *(j->texture) resulting in a compiler 
error because j has no member named texture. You have to dereference j 
before accessing the members,  hence (*j)->texture.

To get rid of that (*j), you can assign a local variable:
for (j = randomForest.begin(); (j != randomForest.end()) && (!found); ++j) {
    TreeBin * treeBin = *j;
    if( treeBin->texture == mat->get_tree_texture() etc. etc.

You have to decide for yourself is this is an improvement ;-)

You can also make it worse: (*(*j)j).texture should also work ;-)

Torsten

Torsten

On Thu, 28 Jul 2011, Stefan Seifert wrote:

> On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote:
>
>> But there is one minor and very common issue with the code that should be
>> fixed.  In the for loop
>>
>> for (..; ..;  j++)
>>
>> should be
>>
>> for (..; ..; ++j)
>>
>> if you use j++ the compiler has to make a copy of j with each iteration of
>> the loop but if you use ++j it does not have to make a copy.  This will
>> make the loop more efficient although only by a small amount.
>
> Are you sure about that? I just tried it with a little example and at least
> gcc compiles both variants to the exact same assembly code. Tried it with and
> without -O2.
>
That would freak me out.  Doesn't "++j" mean "increment j, then test" 
whereas "j++" means "test j, then increment"?

g.

-- 
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!

Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.

On 2011-07-28 14.33, Gene Buckle wrote:
> On Thu, 28 Jul 2011, Stefan Seifert wrote:
>
>> On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote:
>>
>>> But there is one minor and very common issue with the code that should be
>>> fixed.  In the for loop
>>>
>>> for (..; ..;  j++)
>>>
>>> should be
>>>
>>> for (..; ..; ++j)
>>>
>>> if you use j++ the compiler has to make a copy of j with each iteration of
>>> the loop but if you use ++j it does not have to make a copy.  This will
>>> make the loop more efficient although only by a small amount.
>>
>> Are you sure about that? I just tried it with a little example and at least
>> gcc compiles both variants to the exact same assembly code. Tried it with and
>> without -O2.
>>
> That would freak me out.  Doesn't "++j" mean "increment j, then test"
> whereas "j++" means "test j, then increment"?

No, for a for loop

for ( [1]; [2]; [3] )

where [3] is ++j will increment j before use. However, in an 
if-statement the complete statement [3] is evaluated before the test [2] 
is done. If the compiler is smart it will produce the fastest binary 
code regardless ++j or j++. However, if the [3] is more complicated like 
a hypothetical i = ++j + k the compiler will most probably generate 
different binary code (compared to i = ++j + k).


Jari

On Thu, 28 Jul 2011, Jari Häkkinen wrote:

>>> Are you sure about that? I just tried it with a little example and at least
>>> gcc compiles both variants to the exact same assembly code. Tried it with and
>>> without -O2.
>>>
>> That would freak me out.  Doesn't "++j" mean "increment j, then test"
>> whereas "j++" means "test j, then increment"?
>
> No, for a for loop
>
> for ( [1]; [2]; [3] )
>
> where [3] is ++j will increment j before use. However, in an
> if-statement the complete statement [3] is evaluated before the test [2]
> is done. If the compiler is smart it will produce the fastest binary
> code regardless ++j or j++. However, if the [3] is more complicated like
> a hypothetical i = ++j + k the compiler will most probably generate
> different binary code (compared to i = ++j + k).

Right, but j++ will increment _after_ it's used, correct?  So how could 
++j vs j++ generate the same assembly code and be correct?

g.

-- 
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!

Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.

On 2011-07-28 15.22, Gene Buckle wrote:
> On Thu, 28 Jul 2011, Jari Häkkinen wrote:
>
>>>> Are you sure about that? I just tried it with a little example and
>>>> at least
>>>> gcc compiles both variants to the exact same assembly code. Tried it
>>>> with and
>>>> without -O2.
>>>>
>>> That would freak me out. Doesn't "++j" mean "increment j, then test"
>>> whereas "j++" means "test j, then increment"?
>>
>> No, for a for loop
>>
>> for ( [1]; [2]; [3] )
>>
>> where [3] is ++j will increment j before use. However, in an
>> if-statement the complete statement [3] is evaluated before the test [2]
>> is done. If the compiler is smart it will produce the fastest binary
>> code regardless ++j or j++. However, if the [3] is more complicated like
>> a hypothetical i = ++j + k the compiler will most probably generate
>> different binary code (compared to i = ++j + k).
>
> Right, but j++ will increment _after_ it's used, correct? So how could
> ++j vs j++ generate the same assembly code and be correct?


Yes, j++ will increment j after use. The same assembly code in this case 
is probably because gcc makes optimizations for simple statements like 
j++; or ++j; These are straight forward for the compiler to perform 
optimizations for (at least for standard types like doubles, integers, 
chars etc).

For general classes it is probably not legal for the compiler to make 
similar assumptions when optimizing since the operators ++C and C++ can 
in principle behave completely differently/unexpectedly ... we are in 
the mercy of the programmer here.


Jari

On Thursday 28 July 2011 06:22:10 Gene Buckle wrote:
> On Thu, 28 Jul 2011, Jari Häkkinen wrote:
> >>> Are you sure about that? I just tried it with a little example and
> >>> at least gcc compiles both variants to the exact same assembly
> >>> code. Tried it with and without -O2.
> >> 
> >> That would freak me out.  Doesn't "++j" mean "increment j, then test"
> >> whereas "j++" means "test j, then increment"?
> > 
> > No, for a for loop
> > 
> > for ( [1]; [2]; [3] )
> > 
> > where [3] is ++j will increment j before use. However, in an
> > if-statement the complete statement [3] is evaluated before the test [2]
> > is done. If the compiler is smart it will produce the fastest binary
> > code regardless ++j or j++. However, if the [3] is more complicated like
> > a hypothetical i = ++j + k the compiler will most probably generate
> > different binary code (compared to i = ++j + k).
> 
> Right, but j++ will increment _after_ it's used, correct?  So how could
> ++j vs j++ generate the same assembly code and be correct?

Because the for loop is a case where it simply doesn't matter. Translate the 
for to a while:

int i = 0;
while (i < 10)
    i++;

is just the same as:
int i = 0;
while (i < 10)
    ++i;

because the value of the incrementing expression is not used anywhere.
The compiler recognizes this as one of the simplest cases of optimization.

Stefan

On 2011-07-28 14.52, Jari Häkkinen wrote:
>> That would freak me out.  Doesn't "++j" mean "increment j, then test"
>> whereas "j++" means "test j, then increment"?
>
> No, for a for loop
>
> for ( [1]; [2]; [3] )
>
> where [3] is ++j will increment j before use. However, in an
> if-statement the complete statement [3] is evaluated before the test [2]
> is done. If the compiler is smart it will produce the fastest binary
> code regardless ++j or j++. However, if the [3] is more complicated like
> a hypothetical i = ++j + k the compiler will most probably generate
> different binary code (compared to i = ++j + k).

The last line should say
... different binary code (compared to i = j++ + k).

Sorry for the typo.

Jari

On Thu, Jul 28, 2011 at 8:33 AM, Gene Buckle <geneb@...> wrote:
> On Thu, 28 Jul 2011, Stefan Seifert wrote:
>
>> On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote:
>>
>>> But there is one minor and very common issue with the code that should be
>>> fixed.  In the for loop
>>>
>>> for (..; ..;  j++)
>>>
>>> should be
>>>
>>> for (..; ..; ++j)
>>>
>>> if you use j++ the compiler has to make a copy of j with each iteration of
>>> the loop but if you use ++j it does not have to make a copy.  This will
>>> make the loop more efficient although only by a small amount.
>>
>> Are you sure about that? I just tried it with a little example and at least
>> gcc compiles both variants to the exact same assembly code. Tried it with and
>> without -O2.
>>
> That would freak me out.  Doesn't "++j" mean "increment j, then test"
> whereas "j++" means "test j, then increment"?
No, in both cases the test is done before the increment. The
difference between these cases is that in the post-increment case the
initial value of the variable must be saved and returned as the value
of the operation. In a typical for-loop that value won't be used, so
in simple cases -- such as just incrementing an index or pointer --
the compiler might very well generate the same code. The difference is
seen when the variable is an iterator with hairy overloaded functions
for the increment operations.

Tim

>
> g.
>
> --
> Proud owner of F-15C 80-0007
> http://www.f15sim.com - The only one of its kind.
> http://www.simpits.org/geneb - The Me-109F/X Project
> Some people collect things for a hobby.  Geeks collect hobbies.
>
> ScarletDME - The red hot Data Management Environment
> A Multi-Value database for the masses, not the classes.
> http://www.scarletdme.org - Get it _today_!
>
> Political correctness is a doctrine, fostered by a delusional, illogical
> minority, and rabidly promoted by an unscrupulous mainstream media, which
> holds forth the proposition that it is entirely possible to pick up a turd
> by the clean end.
>
> ------------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

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

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

> 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

> From: thorsten.i.renk@... [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

> People have left the FlightGear project for various reasons I'm not
> going to explain here and now. _But_ leaving the project entirely just
> for the simple reason that _other_ project members don't perform at the
> rate as _you_ expect them to do is certainly not one of the most
> honourable reasons.
> I'm pretty certain that everybody here - including those whose style I
> dislike - is spending as much effort to the favour of FlightGear as
> their respective private and work lives permit. It's up to you to
> decide if that's "enough" for you or not ....  but don't blame people
> for not working hard enough !!
> 
> Cheers,
> 	Martin.

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.

On Thu, Jul 28, 2011 at 4:20 PM, Slavutinsky Victor  wrote:
>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.

<snip>

> 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.

If, as you say there is a "dramatical lowering of common development rate"
then we would expect the rate at which changes are committed to the
repository to be declining. Correct?

OK. Here's some raw data.

I've used "git log --no-notes --date=short" to generate a list of all
the commits
in simgear, flightgear and fgdata since the project began in 1997.

I've drawn some graphs of
- the number of commits per month,
- 6 month moving averages,
- the number of commits per year.

An OpenOffice spreadsheet of the data and graphs is available here:

http://www.nanjika.co.uk/flightgear/git.ods

The 6 month moving average is available here:

http://www.nanjika.co.uk/flightgear/6month.png

As you can see, FG development has been quite variable over time (generally
a lot of development in the northern hemisphere winter), but core development
has been fairly constant since the start of the project. There is absolutely no
evidence whatsoever to back your theory that development is in decline and the
project is in trouble.

-Stuart