Here is a quick thought (not having thought this all the way through.)
Originally we only queried the altitude of a single point beneath out
aircraft. As we've move forward, we now have created a cache of local
triangles and can query the altitude of each wheel and contact point. But
also we have added nasal and C++ interfaces to query the altitude of any
arbitrary point.
I wonder though, if there is no scenery tile loaded for the requesting query
location, what happens? Are these tiles somehow scheduled for loading? But
the cache size is fixed so if we have too many far ranging altitude queries,
could we be running into a situation where the requested tiles are flushed
to make room for something else?
I did a long haul flight recently from Boston to NY to MSP in the alphajet
(current CVS version) and not far out of Boston started dropping tiles right
and left ... it was a mess. I got to the point where I had no visible tiles
loaded, just flying over empty space as far as the eye could see.
Then later I tried another long cross country to verify the problem, and I
didn't see one dropped tile.
So there is some random goofiness somewhere in our tile caching scheme, and
I don't personally have a good understanding of how these arbitrary position
queries play with our tile caching/scheduling/loading scheme ... I suspect
there could be some contention there.
Best regards,
Curt.
On Fri, May 15, 2009 at 12:21 PM, Durk Talsma wrote:
> Hi All,
>
> Thanks to a report by regular Forum poster MD-TERP (a.k.a. Rob), we found a
> way to trigger the infamous NaN warning in a rather reliable manner.
> Following up on this lead, I modified OpenSceneGraph so that it deliberately
> segfaults when the warning message is triggered (I know, I could have set a
> break point there in GDB, but I was lazy).
>
> Although I don't have a fix yet, I've collected quite a bit of
> information about the problem, and have a pretty good insight as to what's
> going on.
>
> Rob suggested trying a Flight from KMTN to KSKY, using the Citation-Bravo,
> cruising at FL240, enabling AI Traffic, Traffic Manager, ATC, and
> Multiplayer. The com1 radio was tuned to KMTN tower (121.3), but this is
> probably not relevant. The actual aircraft also probably doesn't matter.
> Using this setup, a NaN error is triggered rather reliably while crossing
> the Pittsburgh area. OpenSceneGraph was modified to include a deliberately
> malicious piece of code designed to trigger a segmentation fault upon
> printing the error message.
>
> Two stack traces were obtained, and a third one was examined in more detail
> using GDB, and saved as a core file.
>
> Stack Trace #1 showed that the warning was triggered inside the AI Traffic
> subsystem, in particular in a call to
>
> globals->get_scenery()->get_elevation_m()
>
> Stack Trace #2 showed that the warning was triggered in
> src/Environment/ridge_lift.cxx again in a call to get_elevation_m()
>
> So, in conclusion, it looks like the get_elevation_m() is the culprit.
> However, it also seemed that the NaN warning was only triggered when AI
> Traffic was activated, which seemed to be at odds with it being triggered by
> ridge_list as well.
>
> At this point, Mathias Froelich pointed out to me that 3D model objects
> included in the scene graph are involved in the ground elevation scanning
> process. Mathias also suggested to me that it should be possible to
> determine the offending model, by printing out the this->_name variable at
> various levels of the stack. Traversing the stack, I found that at least one
> possible source of the problem can be found in
>
> Aircraft/c172p/Models/c172p.xml,
>
> more particularly so in the included model
>
> Aircraft/Instruments-3d/mag-compass.xml,
>
> in particular in the the object with the name "Interior". I'm not a 3d
> modeling expert enough to determine what could possible wrong in this
> object. Mathias suggested that a triangle with a zero sized surface or
> something like that could blow the math. If anybody with more expertise than
> me could have a look at it, please be my guest.
>
> The fact that an included component of the c172 causes the math of the
> ground elevation code to blow perfectly explains why a host of subsystems
> (at least in AI Traffic itself, and in ridge_lift) are vulnerable to this
> error, while disabling AI Traffic does not affect these other system. By
> placing a c172 model in the scene, AI Traffic creates a vulnerability, not
> only for itself, but also for other systems. Although I haven't seen an
> error triggered by traffic generated by the traffic manager (which is, I
> stress once again, an entirely separate system), this is probably
> coincidental, and due to the fact that we currently don't have much Traffic
> Manager related activity in the test area, and therefore the probability of
> seeing an error generated by the traffic manager is, in this particular
> case, low.. Had traffic schedules involving the c172 model existed, the
> traffic manager would likely have caused a similar error/vulnerability
> itself.
>
> So, to conclude, the mag-compass.ac instrument should be checked for
> possible modeling errors.. Also, I would suggest that a meaningful message
> could be printed by the ground elevation code in case of an error, so that
> future errors could be avoided. This probably can't be done in FlightGear,
> because it would require some modification of the OSG code.
>
> Until a full fix is in place, a special purpose AI c172 model could be
> created, which doesn't contain the interior. Users not regularly flying the
> c172 could remove the 3d compass, so that it becomes usable again as an AI
> aircraft.
>
> Obviously, I can't rule out that there aren't more possible causes for the
> NaN warning, however. given that it's occurrence seems to be strongly
> related to activating AI Traffic, I suspect they are caused by a relatively
> narrow set of circumstances.
>
> Cheers,
>
> Durk
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
