Jim Wilson wrote: > Setting all the view offsets to 0 I was able to prove that the > position/rotation matrices generated on the model and the camera are > numerically identical. Here's a sample from the dump:
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 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. 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. 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. I can see there options to fix this: + Rescale the tiles such that they cover a smaller area that can be represented by a float (very hard). + 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) + 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. Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
