Re: [Flightgear-devel] Disappearing scenery

[ThorstenB]

Hi Tim, Curt, et al,

I've prepared a patch and did a number of test flights tonight - and
had no more scenery issues. I'll still do a bit more testing, but
maybe someone else seeing these problems regularly could already
check, if this fixed their problems, too. The patch is attached to the
bug issue (matching latest GIT):
http://code.google.com/p/flightgear-bugs/issues/detail?id=122

> The cull callback is called from OSG's culling traversal. If OSG determines
> that an object's bounding sphere intersects the viewing frustum, it calls
> the cull callback -- if there is one -- to traverse that object and perform
> finer grain culling. If there is no cull callback, OSG does the traversal
> itself. Anyway, it's a good way to perform an action when an object is in
> view.
> The timestamp used by the cull callback comes right from OSG's "frame
> stamp" and should be consistent with the tile code. there could be a logic
> error in the tile cache.
> It is possible for the tile cache code, which runs in the update traversal,
> and the cull callback to run in different threads. However, they should
> never run at the same time: the cull traversal starts when the the update
> traversal has finished, and the next update traversal blocks on the cull and
> draw traversals. Now, the code that actually loads the tiles -- the database
> pager -- does run asynchronously. I'll need to check if any of the tile
> cache code runs in the database pager thread, but don't think any does.

I've checked the timestamp issue again. It was not a threading
problem. The current time of the tile cache was simply updated *after*
scheduling the next tiles. So, cache's time was one frame behind -
which could cause problems. This is easily changed. But in fact, the
cache's time has to be even greater than the timestamps of all tiles
in the cache, otherwise it's not guaranteed that newly scheduled tiles
can be loaded. I therefore also changed the timestamp update for
existing tiles to prevent this from happening. My patch does this
without using the osg callbacks now, I'm not sure if we really still
need these. The problem with the osg callbacks is, that these already
updated tiles with the latest frame time - so the cache's time
couldn't be really newer. But I guess someone (Tim?) with a better
insight to the cache modules should have a closer look...

Ok, I hope this patch is usable (or at least useful :-) ) to finally
fix this issue.

cheers,
Thorsten

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Disappearing scenery

[Tim Moore]

On Sun, Sep 19, 2010 at 4:40 PM, ThorstenB  wrote:

> Hi,
>
> good news - I've done more debugging in the tile cache module and
> think I already found something...
>
> I'm seeing two issues with the tile cache, sometimes causing active
> scenery to be kicked when the cache is full - and this results in the
> missing patches. I'm also seeing cases where all active scenery tiles
> are dropped. This can also happen when cycling through the tower view
> - so this doesn't always help. Both issues are timestamp related
> (maybe depend on frame rate, system load, slow USB disks :-) or
> so...).
>
> * First problem is that the tiles' timestamps are only updated when
> the tiles are freshly loaded from disk or they are actively displayed
> (some magic osg "CullCallback" does that - haven't fully understood
> this yet). So when a tile belonging to the current position was not
>
The cull callback is called from OSG's culling traversal. If OSG determines
that an object's bounding sphere intersects the viewing frustum, it calls
the cull callback -- if there is one -- to traverse that object and perform
finer grain culling. If there is no cull callback, OSG does the traversal
itself. Anyway, it's a good way to perform an action when an object is in
view.

> displayed for a while, its timestamp is old. When the view then moves
> or teleports into a new position, and then back to the original
> position, the same tiles get scheduled again - but are still found in
> the cache. Since their timestamps remain old, they are kicked from the
> cache soon afterwards, when more tiles are loaded. This is what causes
> the "random scenery tiles disappear" effect...
> => I'm testing a fix now, which updates a tile's timestamp whenever it
> is scheduled to be loaded, but then found in the cache.
>
That sounds correct.

>
> * The second issue is about the timestamps updated through this magic
> osg "CullCallback". These timestamps can be newer than the current
> time used by the cache module for loading new tiles (seems to be a
> frame ahead or so). When a new set of tiles is scheduled to be loaded,
> and the cache is already filled with many "future timestamp tiles",
> then the new tiles immediately kick each other from the cache (are
> never really loaded). When this happens, all scenery for a new
> position is lost (complete whiteout)...
>
> The timestamp used by the cull callback comes right from OSG's "frame
stamp" and should be consistent with the tile code. there could be a logic
error in the tile cache.

> Is all the tile cache and osg code single-threaded? If these osg
> callbacks, the cache management and tile loading were not in the same
> thread, it would explain where future timestamps could come from
> (maybe on slow machines only). If it's all single-threaded then I'll
> have another look to locate this.

It is possible for the tile cache code, which runs in the update traversal,
and the cull callback to run in different threads. However, they should
never run at the same time: the cull traversal starts when the the update
traversal has finished, and the next update traversal blocks on the cull and
draw traversals. Now, the code that actually loads the tiles -- the database
pager -- does run asynchronously. I'll need to check if any of the tile
cache code runs in the database pager thread, but don't think any does.

Tim

>
> Another option I'm already testing is introducing a flag to lock all
> tiles belonging to the current view position in the cache. The primary
> condition checked by the cache would then be to never kick tiles
> belonging to the current position (i.e. current inner or outer ring).
> Timestamps remain a secondary condition to pick from tiles not
> belonging to the current position. This would make things a lot more
> robust than relying on whacky timestamps alone.
>
> FG only supports one view position at a time, right? Multiple view
> positions (e.g. one screen for the tower view and a second screen for
> the plane) would complicate a "locked to cache" flag quite a lot...
>
Yes, and that's not really supported by the current architecture, neither by
the tile cache nor by osgViewer::Viewer. We would need to move to a
CompositeViewer model, which supports several scene graphs, and rely
completely on the osg database paging machinery.

Tim

>
> Maybe someone could comment on the threading issue. I'll do some more
> testing, and then hope to propose a patch...
>
> cheers,
> Thorsten
>
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
---

Re: [Flightgear-devel] Disappearing scenery

[James Turner]

On 19 Sep 2010, at 15:40, ThorstenB wrote:

> FG only supports one view position at a time, right? Multiple view
> positions (e.g. one screen for the tower view and a second screen for
> the plane) would complicate a "locked to cache" flag quite a lot...
> 
> Maybe someone could comment on the threading issue. I'll do some more
> testing, and then hope to propose a patch...

Tim really needs to comment on these :)

But in general, your analysis sounds pretty correct to me, so far - thanks for 
investigating this.

James


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Disappearing scenery

[ThorstenB]

Hi,

good news - I've done more debugging in the tile cache module and
think I already found something...

I'm seeing two issues with the tile cache, sometimes causing active
scenery to be kicked when the cache is full - and this results in the
missing patches. I'm also seeing cases where all active scenery tiles
are dropped. This can also happen when cycling through the tower view
- so this doesn't always help. Both issues are timestamp related
(maybe depend on frame rate, system load, slow USB disks :-) or
so...).

* First problem is that the tiles' timestamps are only updated when
the tiles are freshly loaded from disk or they are actively displayed
(some magic osg "CullCallback" does that - haven't fully understood
this yet). So when a tile belonging to the current position was not
displayed for a while, its timestamp is old. When the view then moves
or teleports into a new position, and then back to the original
position, the same tiles get scheduled again - but are still found in
the cache. Since their timestamps remain old, they are kicked from the
cache soon afterwards, when more tiles are loaded. This is what causes
the "random scenery tiles disappear" effect...
=> I'm testing a fix now, which updates a tile's timestamp whenever it
is scheduled to be loaded, but then found in the cache.

* The second issue is about the timestamps updated through this magic
osg "CullCallback". These timestamps can be newer than the current
time used by the cache module for loading new tiles (seems to be a
frame ahead or so). When a new set of tiles is scheduled to be loaded,
and the cache is already filled with many "future timestamp tiles",
then the new tiles immediately kick each other from the cache (are
never really loaded). When this happens, all scenery for a new
position is lost (complete whiteout)...

Is all the tile cache and osg code single-threaded? If these osg
callbacks, the cache management and tile loading were not in the same
thread, it would explain where future timestamps could come from
(maybe on slow machines only). If it's all single-threaded then I'll
have another look to locate this.

Another option I'm already testing is introducing a flag to lock all
tiles belonging to the current view position in the cache. The primary
condition checked by the cache would then be to never kick tiles
belonging to the current position (i.e. current inner or outer ring).
Timestamps remain a secondary condition to pick from tiles not
belonging to the current position. This would make things a lot more
robust than relying on whacky timestamps alone.

FG only supports one view position at a time, right? Multiple view
positions (e.g. one screen for the tower view and a second screen for
the plane) would complicate a "locked to cache" flag quite a lot...

Maybe someone could comment on the threading issue. I'll do some more
testing, and then hope to propose a patch...

cheers,
Thorsten

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Disappearing scenery

[Jörg Emmerich]

Just to second that:

As ATC in EDDF I had several people experience that "totally white
scenery" - especially 1 guy coming regularly from EETN to EDDF - he
experienced that about 1 out of 3. And it usually happens just during
final.

In the meantime that guy experiences lots of FGFS-crashes already over
northern Germany when coming from EETN - so not sure if that prevents
him from getting the "white scenery" at EDDF!

So I tried it several times myself and got the "white scenery" too. I
got it even when just going from EDDP to EDDF. Moving my "total,
worldwide scenery" from an external USB-disk to a local (fast) one and
downgrading several Rendering Options and making sure I fly without
TerraSync "seemed" to fix it.

So I thought it is a slow PC in addition to the EDDF problem being just
at a corner-point of tiles and populated very heavily with buildings
etc.

But then I got it twice (out of 5) by going EDDF to KBOS with Concorde!
Once I tried to land anyhow (just on AutoLand) and scenery appeared
again just at TouchDown!

By the way: I use a UBUNTU 10.04 with AMD 64 X2 Dual 6000 with video
"GeForce 7600 GT" and 4 GB mem.

It really would be great if somebody finds a reason for it - of course
next time I will try that tip "cycling the views" - thanks for the hint!
joe


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Disappearing scenery

[Curtis Olson]

Hi Thorsten,

I think you are on the right track by looking at the tile cache.  The
original design used a distance based metric for removing the tiles that are
the furthest away, but somewhere along the way we got talked into switching
this to a time stamp based approach.

Along the way we added some code that could query the ground height at
arbitrary locations, not just the current aircraft location, so this
complicates the whole tile caching scheme because a variety of locations and
tiles could be referenced.  I wonder if we somehow get into a situation
where the cache isn't big enough for all the tiles we are trying to
reference?  Or some combination with how we reference tiles as stopped
playing nice with the tile cache management scheme?

But I'm pretty sure the tile caching system is the proper place to be
hunting.

Regards,

Curt.


On Sat, Sep 18, 2010 at 5:11 PM, ThorstenB  wrote:

> On Saturday, September 18, 2010 18:32 Durk Talsma wrote:
> > Given, my observation that cycling through all the viewpoints, will
> restore
> > the visibility of tiles that have gone lost, and flag tiles that were
> visible
> > during the previous view cycle invisible, makes me suspect that something
> in
> > the code that determines tile visibility may go astray after a prolonged
> > number of tile crossings.
>
> Thanks Durk, in fact your observations are very helpful!
> I also noticed that tiles sometimes reappeared - i.e. when I paused
> the sim. But it's not the pausing that helped, but indeed the view
> cycling - specifically cycling through the tower view helps. The tower
> of the home airport is far away when the problems start. The tile
> cache isn't big enough to hold all tiles of two different locations -
> so switching to the home airport and then back causes a reload of
> all/most tiles.
>
> And it's indeed connected to the number of scenery tiles covered by
> the flight as you mentioned - not the distance in the first place. I
> found that I'm not seeing any problems unless the tile cache is filled
> to its maximum. And when I circle in my regular home airport area, the
> cache is not completly filled - and I have no issues.
>
> I'm currently monitoring what's going on in the FG Tile Manager and SG
> tile cache module. The tile cache makes its decision to kick a tile
> from the cache purely based on a timestamp (oldest tile get's kicked).
> This strategy works nicely when flying in a straight line (oldest
> timestamp => tile is furthest away). But not so great when you fly
> sharp turns (oldest tile may still/again be right in front). I suspect
> there is some kind of connection to the problem, e.g bad strategy
> kicks tile in front of plane from the cache, and then this tile does
> not get reloaded. It would explain why I often see issues with a
> disappearing destination airport: you fly (almost) straight from A to
> B - and then, at some VOR, you make a sharp left or right turn to
> line-up for the approach - and soon afterwards I start seeing most
> issues (on short final :-(...).
> Well, just a theory so far. I'll do a bit more digging. Any hints still
> welcome.
>
> cheers,
> Thorsten
>
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Disappearing scenery

[ThorstenB]

On Saturday, September 18, 2010 18:32 Durk Talsma wrote:
> Given, my observation that cycling through all the viewpoints, will restore
> the visibility of tiles that have gone lost, and flag tiles that were visible
> during the previous view cycle invisible, makes me suspect that something in
> the code that determines tile visibility may go astray after a prolonged
> number of tile crossings.

Thanks Durk, in fact your observations are very helpful!
I also noticed that tiles sometimes reappeared - i.e. when I paused
the sim. But it's not the pausing that helped, but indeed the view
cycling - specifically cycling through the tower view helps. The tower
of the home airport is far away when the problems start. The tile
cache isn't big enough to hold all tiles of two different locations -
so switching to the home airport and then back causes a reload of
all/most tiles.

And it's indeed connected to the number of scenery tiles covered by
the flight as you mentioned - not the distance in the first place. I
found that I'm not seeing any problems unless the tile cache is filled
to its maximum. And when I circle in my regular home airport area, the
cache is not completly filled - and I have no issues.

I'm currently monitoring what's going on in the FG Tile Manager and SG
tile cache module. The tile cache makes its decision to kick a tile
from the cache purely based on a timestamp (oldest tile get's kicked).
This strategy works nicely when flying in a straight line (oldest
timestamp => tile is furthest away). But not so great when you fly
sharp turns (oldest tile may still/again be right in front). I suspect
there is some kind of connection to the problem, e.g bad strategy
kicks tile in front of plane from the cache, and then this tile does
not get reloaded. It would explain why I often see issues with a
disappearing destination airport: you fly (almost) straight from A to
B - and then, at some VOR, you make a sharp left or right turn to
line-up for the approach - and soon afterwards I start seeing most
issues (on short final :-(...).
Well, just a theory so far. I'll do a bit more digging. Any hints still welcome.

cheers,
Thorsten

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Disappearing scenery

[ThorstenB]

On Sat, 18 Sep 2010 16:57:11 +0200, Arnt wrote in message
<20100918165711.24d2d...@a45.fmb.no>:

> ..can happen in RL too, this is when you swear a wee bit, pick up
> your flight plan and pick our best alternate destination from it
> just like the RL guys does.
Knock knock, Neo. The effect here is not so much as in RL, but more as
in the Matrix. You can't just go to an alternate because the glitch
follows. Tiles keep disappearing, and sometimes reappearing. Wherever
you go. The Matrix has you. Once there is a glitch in the Matrix,
everything starts to break...

> > You can still try to land in the void - but it's certainly not much
> > fun.
> ..depends, some of us likes to play these silly naughty rule torturous
> Counter Strike wild ass Doom kinda crazy games that in RL will earn
> you nice clean white cozy long sleeve shirt like it did Mathias
> Rust. ;o)
Some probably do! :-)
Too bad, I don't... :-(

> .._which_ EDDC scenery tile?  There are several, AFAIUI.
Any, AFAICS. EDDC or EDDE was s.o. else reporting. But I can reproduce
it with any airport I've been testing so far, doesn't seem to matter
which. And it can affect all tiles - randomly.

> ..first, play with your FG command line to reliably,
> reproduce the bug you see, and then post it here.
Hmm, tricky concept, reproduce a random effect reliably... :-)
Still, I can reproduce it easily (well, and *that* is the very
problem...), so I can provide data/logs and debug info on my machine
to help tracking the issue.

Well, and anyone else interested in helping - follow the rabbit...
eh.. bug tracker... :-)

cheers,
Thorsten

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Disappearing scenery

[Durk Talsma]

H Thorsten,

On Saturday, September 18, 2010 01:47:38 pm ThorstenB wrote:
> Hi,
> 

> So, please, any help on this bug, any hints on what I could check,
> which FlightGear modules could be related, any ideas on how to locate
> this issue are welcome.
> 

To the best of my knowledge, this is a (more or less) known problem. I've 
experienced it as well on a number of longer flights. IIRC, Curt mentioned 
observing this on a number of occasions as well. As far as I know, nobody has 
yet stepped forward to get to the bottom of it, but I did find something that 
serves as a stopgap when the problem does occur. Just cycle through all the 
views once, and you will find the missing tile appear once again.

FWIW, FlightGear's scenery is loaded in tiles. The loading and unloading 
mechanism used to be such that scenery tiles surrounding the user's aircraft 
were loaded as it was flying into new areas, and existing tiles were unloaded 
as the aircraft was getting more and more distant from that tile's location. 

Currently, the tile loading mechanism is a lot more complicated, because other 
factors are also involved in the loading and unloading mechanism. These 
factors include, among others, the current viewpoint, and also height above 
terrain calculations. As a consequence, FlightGear's tile loading and 
unloading mechanism uses a highly complicated priority system that determines 
which tiles need to remain in memory, and which ones can go. 

In addition, is suspect (and I'm not 100% sure about this) that loaded tiles 
can either be flagged as visible, or invisible (the latter being case when 
loaded tiles are beyond the current visibility limit). 

Given, my observation that cycling through all the viewpoints, will restore 
the visibility of tiles that have gone lost, and flag tiles that were visible 
during the previous view cycle invisible, makes me suspect that something in 
the code that determines tile visibility may go astray after a prolonged 
number of tile crossings. 

Unfortunately, I'm not too familiar with the tile loading code to be more 
specific, but I hope that my observations / suggestions may be helpful in 
resolving this bug.

Cheers,
Durk

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Disappearing scenery

[Arnt Karlsen]

On Sat, 18 Sep 2010 16:57:11 +0200, Arnt wrote in message 
<20100918165711.24d2d...@a45.fmb.no>:

> On Sat, 18 Sep 2010 13:47:38 +0200, ThorstenB wrote in message 
> :
> 
> > Hi,
> > 
> > maybe I can raise some more attention to a specific bug, which keeps
> > me from using FG properly. I have also heard a number of other
> > people complaining. If I could vote, I'd like to vote for this
> > issue to be the currently most annoying FlightGear bug:
> 
> ..I take the black box approach along the lines: _Is_ it a bug, 
> or a feature of aircrew management etc traffic simulation, or a 
> feature of the developing simulator, as in somebody is working 
> on the destination scenery tiles during these long flights.
> 
> > Scenery tiles keep disappearing (when flying a longer distances),
> > http://code.google.com/p/flightgear-bugs/issues/detail?id=122
> > 
> > It's very disappointing when you approach your destination airport,
> > have the runway in sight, and then when you get too close, *whoosh*
> > it just disappears into a patch of blue sky. 
> 
> ..can happen in RL too, this is when you swear a wee bit, pick up 
> your flight plan and pick our best alternate destination from it 
> just like the RL guys does. 
> 
> > You can still try to land in the void - but it's certainly not much
> > fun.
> 
> ..depends, some of us likes to play these silly naughty rule torturous
> Counter Strike wild ass Doom kinda crazy games that in RL will earn
> you nice clean white cozy long sleeve shirt like it did Mathias
> Rust. ;o)
> 
> > You can keep flying - and then the scenery tiles sometimes reappear
> > in the distance...
> 
> ..maybe reload rebuilt-during-long-flights scenery tiles before 
> we approach them?  Takes a We-Have-The-Latest-Tile? check.
> 
> > To me this happens *very* often, feels like > 50% of all longer
> > distance flights. I'm not sure about the minimum distance it takes
> > to trigger, maybe about more than 60miles from the original
> > airport. So this keeps me from flying longer navigation routes. I
> > can stay within a limited area around my departure airport to avoid
> > this. But circling in one area gets boring soon...
> > It applies to all platforms: tracker issue was raised for mac, I see
> > it on Linux, and during the Frankfurt ATC sessions I've heard
> > several people complaining with Windows systems. The tracker
> > mentions FG 1.9.1 and 2.0.0 - and I also see it with the latest
> > GIT. Maybe not everyone sees this issues - or not with the same
> > high probability.
> 
> .._which_ EDDC scenery tile?  There are several, AFAIUI.

..I of course meant EDDE. ;o)

> > I'm willing to help with testing and also debugging. But I don't
> > know much about the FG scenery and graphics system - and don't want
> > to start from scratch on my own.
> > 
> > So, please, any help on this bug, any hints on what I could check,
> > which FlightGear modules could be related, any ideas on how to
> > locate this issue are welcome.
> 
> ..first, play with your FG command line to reliably, 
> reproduce the bug you see, and then post it here.


-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Disappearing scenery

[Arnt Karlsen]

On Sat, 18 Sep 2010 13:47:38 +0200, ThorstenB wrote in message 
:

> Hi,
> 
> maybe I can raise some more attention to a specific bug, which keeps
> me from using FG properly. I have also heard a number of other people
> complaining. If I could vote, I'd like to vote for this issue to be
> the currently most annoying FlightGear bug:

..I take the black box approach along the lines: _Is_ it a bug, 
or a feature of aircrew management etc traffic simulation, or a 
feature of the developing simulator, as in somebody is working 
on the destination scenery tiles during these long flights.

> Scenery tiles keep disappearing (when flying a longer distances),
> http://code.google.com/p/flightgear-bugs/issues/detail?id=122
> 
> It's very disappointing when you approach your destination airport,
> have the runway in sight, and then when you get too close, *whoosh* it
> just disappears into a patch of blue sky. 

..can happen in RL too, this is when you swear a wee bit, pick up 
your flight plan and pick our best alternate destination from it 
just like the RL guys does. 

> You can still try to land in the void - but it's certainly not much
> fun.

..depends, some of us likes to play these silly naughty rule torturous
Counter Strike wild ass Doom kinda crazy games that in RL will earn you
nice clean white cozy long sleeve shirt like it did Mathias Rust. ;o)

> You can keep flying - and then the scenery tiles sometimes reappear
> in the distance...

..maybe reload rebuilt-during-long-flights scenery tiles before 
we approach them?  Takes a We-Have-The-Latest-Tile? check.

> To me this happens *very* often, feels like > 50% of all longer
> distance flights. I'm not sure about the minimum distance it takes to
> trigger, maybe about more than 60miles from the original airport. So
> this keeps me from flying longer navigation routes. I can stay within
> a limited area around my departure airport to avoid this. But circling
> in one area gets boring soon...
> It applies to all platforms: tracker issue was raised for mac, I see
> it on Linux, and during the Frankfurt ATC sessions I've heard several
> people complaining with Windows systems. The tracker mentions FG 1.9.1
> and 2.0.0 - and I also see it with the latest GIT. Maybe not everyone
> sees this issues - or not with the same high probability.

.._which_ EDDC scenery tile?  There are several, AFAIUI.

> I'm willing to help with testing and also debugging. But I don't know
> much about the FG scenery and graphics system - and don't want to
> start from scratch on my own.
> 
> So, please, any help on this bug, any hints on what I could check,
> which FlightGear modules could be related, any ideas on how to locate
> this issue are welcome.

..first, play with your FG command line to reliably, 
reproduce the bug you see, and then post it here.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Disappearing scenery

[ThorstenB]

Hi,

maybe I can raise some more attention to a specific bug, which keeps
me from using FG properly. I have also heard a number of other people
complaining. If I could vote, I'd like to vote for this issue to be
the currently most annoying FlightGear bug:
Scenery tiles keep disappearing (when flying a longer distances),
http://code.google.com/p/flightgear-bugs/issues/detail?id=122

It's very disappointing when you approach your destination airport,
have the runway in sight, and then when you get too close, *whoosh* it
just disappears into a patch of blue sky. You can still try to land in
the void - but it's certainly not much fun. You can keep flying - and
then the scenery tiles sometimes reappear in the distance...
To me this happens *very* often, feels like > 50% of all longer
distance flights. I'm not sure about the minimum distance it takes to
trigger, maybe about more than 60miles from the original airport. So
this keeps me from flying longer navigation routes. I can stay within
a limited area around my departure airport to avoid this. But circling
in one area gets boring soon...
It applies to all platforms: tracker issue was raised for mac, I see
it on Linux, and during the Frankfurt ATC sessions I've heard several
people complaining with Windows systems. The tracker mentions FG 1.9.1
and 2.0.0 - and I also see it with the latest GIT. Maybe not everyone
sees this issues - or not with the same high probability.

I'm willing to help with testing and also debugging. But I don't know
much about the FG scenery and graphics system - and don't want to
start from scratch on my own.

So, please, any help on this bug, any hints on what I could check,
which FlightGear modules could be related, any ideas on how to locate
this issue are welcome.

cheers,
Thorsten

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel