Andy Ross <[EMAIL PROTECTED]> said: > Jim Wilson wrote: > > Oooh, but they're not! Take a really close look at the two position > vectors (the last row): > > > 5064.624023 590.030945 -1211.297729 1.000000 > > 5064.621582 590.031433 -1211.296509 1.000000 >
Those are from two different iterations. I was just proving that the viewer and model were running on the same data, as it had been suggested they were not earlier. The pairs within a single iteration match (this is the same data I posted earlier): POS Aircraft 5064.624023 590.030945 -1211.297729 1.000000 VIEW From 5064.624023 590.030945 -1211.297729 1.000000 POS Aircraft 5064.621582 590.031433 -1211.296509 1.000000 VIEW From 5064.621582 590.031433 -1211.296509 1.000000 > These are the same up to 6 significant figures, but they differ in the > next. If I'm correct that the units are meters, this corresponds to a > difference in millimeters. In this case, my figuring gives a > distance bewteen these two points of 2.77mm. Yes, the aircraft moved (or the coordinates changed) that much. > In the A-4 cockpit, the panel is about 1m away. So 2.77mm subtends an > arc of .00277 radians, or 0.16 degrees. There are 1024 pixels across > the 55 degree FOV, so the error between those positions is 2.9 pixels. > Bingo! There's our jitter. > That's right. > Basically, Curt was right that this is a plain old precision problem. > We're right at the limit of a float here. A float has 23 bits of > mantissa, so the minimum error for the vector magnitudes above is > 5000*2^-23 = 0.6mm. Every calculation you do on the number will > increase the error bounds by a third of a millimeter. Do ten FPU ops > on a given number (i.e. two matrix multiplications), and you get the > 3mm error above. That sounds high for that. Besides you are looking at two values that were generated independantly (2 seperate cycles/frames) when citing the difference of 3mm. I'm not saying you and Curt aren't on the right track though. A little number has a big effect with those world coordinates. What happens to the position coordinates during this same time period? That's the source for these numbers. IIRC those numbers were taken with the model standing still. So how could we have that much movement in one frame? [Throwing ball back in the fdm court ;-)] > > I can see there options to fix this: > > + Rework the viewing/model code such that the final matrices in the > two scene graph branches are not merely generated by the same code, > but are in fact *exactly* the same values. That is, synchronize the > error so the two agree. (rather hard) They are, actually. Look at the code. The view matrix is retrieved from the model. > + Do all the position computations in double precision. Only the > position is a problem -- if you separate out the orientation into a > float matrix separate from the double-valued position vector and > combine them at the end, that should be fine. Doing all the math in > double precision would probably be easier still, although the > conversion to/from the float-value OpenGL matrices is likely to be > clumsy. I think the position computations are in double. I'd have check this and can't right now. Look at the update() in location.cxx Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
