Andy Ross writes: > 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
Ahh, good catch ... > 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). If you mean make the tiles smaller, but more of them, then you are simply reducing the effects of the jitter and not eliminating the problem. If you mean use a different units than meters, then you are just moving the decimal point around and the actual problem doesn't change. > + 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) I think this is what should be done. The view point positioning code and the model positioning code should be identical. However, if we are translating the model by some amount to get it positioned correctly relative to the ground (i.e. the model reference point != the view point) then we may always suffer from this sort of precision problem. Another alternative would be to make the view point always be (0,0,0) and continually transform the scenery around us. This would give us much better floating point precision for stuff that is close to the eye point. > + 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. It would be interesting to see if the current differences in the values amount to a single bit difference or something larger. If they are just a "bit" (literally) different from each other, then doing the math in double precision might not help ... if the double precision results are a "bit" different, then when they are rounded to float, they could each go a different direction respectively and we could still see jitter. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
