Durk Talsma wrote: > On Friday 15 May 2009 20:31:17 Durk Talsma wrote: > >> I'm not sure about this, but my estimate is that the trouble doesnt arise > >> when the mag-compass is part of the user aircraft, but only when it's part > >> of the exterior world, i.e. when part of an AI aircraft. Also, it's > >> possible that the instrument by itself may be okay, but triggers an error > >> in interaction with other scene elements. > >> > > I've been checking a little more today, and it looks like there's more > than meets the eye. In retrospect, the cessna / mag-compass models > themselves are probably okay. It's probably only that the mag compass > showed up because it was the first object to be subjected to a test > containing bad preconditions already. > > I'm still not fully understanding the finer details of the ground cache, > but in essence, if works by trying to shoot a line through every > triangle in the scene graph. Then it returns the distance of the closest > intersecting point. To make the process efficient, the scenegraph is > traversed node by node, and triangles obviously not relevant are quickly > discarded, quite similar to the way the culling algorithm works. > > Since the scene graph is composed of models that may each have their > local coordinate systems, it is necessary that the line that is shot > through the scene graph is also transformed accordingly, so for each > level of the scenegrahp, a new transformation matrix is created, using a > popMatrix function. > > While trying to trap bad data in this the popMatrix function, I just > noticed that a bad transformation matrix is already set up relatively > early in the process, only a few levels deep at the stack. I haven't > been able to relate this to any meaningful object yet. (All that came up > was the name "Scene"). > > So, it looks like a transformation error early on blows up the intersect > line vector(s) already. and scenegraph is traversed further down, OSG > keeps happily multiplying already corrupted data with valid > transformation data further down the line, restuling in an intersect > line, composed of NaNs. This goes unnoticed, until the error is finally > picked up at the first possible occasion where there's a nan error > check. That is, in trialintersect. > > I hope to continue this investigation later, and hope to be able to > traverse the bad data to their true source. It may be helpful to dump the scene graph to a file (from the debug menu) once you're getting the NaN error. Hopefully the offending matrix will be printed with NaNs instead of valid coordinates.
Tim ------------------------------------------------------------------------------ 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
