"Jim Wilson" writes: > David Luff said: > > > "Curtis L. Olson" writes: > > > > > I have also seen > > > some wierdness in the tile scheduling/caching lately too. I'm not sure > > > what's going on there. I started to investigate, but ran out of time the > > > day I was looking at it. It seems like at times we get into a situation > > > where the tile cache isn't big enough for the set of local tiles and it > > > thrashes. That shouldn't happen, but there are some wierd view manager > > > dependencies in there that I'm not even close to understanding. > > > > > > > That could be my fault. The new AI traffic determines ground elevation in > the same manner as the fdm, and can probably significantly pollute the tile > cache since much of the traffic still exists out of visual, but within radio, > range. I've been testing a patch whereby the AI traffic simply uses the > airport elev when out of visual range, and switches to 'proper' elevation if > it comes within visual range, which should significantly alleviate this problem. > > > > That would help a lot. I'm trying to recall the ground level test, but I'm > wondering if it would just make sense to have a variation of the function that > simply returned the ground elevation from the primary FDM whenever the tile > below was missing. > > We should be able to have a query will never trigger a tile load. Maybe two > or three options for default responses when the tile isn't there (e.g. FDM > ground elevation, starting airport elevation, or invalid value like -999999.99) >
A ground elevation api for subsystems developers to use would be excellent. As you say, it shouldn't need to trigger tile loading at all, since by definiation, if a tile is not in the cache, it shouldn't be visible, and thus the exact elevation is not important. I simply copied my current elevation determination scheme from how the FDM does it, and had no idea that I was polluting the tile manager until I completely independently became interested in the workings of the tile manager. Even if I only use my current elevation scheme when planes are visible, which should help a lot, I think it is probably still possible to pollute the tile manager. Consider the low visibility case where only 9 tiles get loaded around the viewer/fdm: A B C D E F G H I with the viewer/fdm in tile E. It's quite reasonable for an AI plane over tile A to require a proper elevation, since it could be very close to the viewer over tile E, but currently I'm pretty sure that determining the elevation causes extra tiles to be loaded adjacent to A, B and D, which isn't really necessary. Still, at least not doing elevation determainations outside of A - I, as may currently be done by the AI traffic, should reduce tile thrashing considerably. Unfortunately, I still don't really understand what is going on with all the hitlist stuff in actually determining the elevation, so I'm not volunteering to write such an api :-( Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
