[Flightgear-devel] Jitter found?
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.00 5064.621582 590.031433 -1211.296509 1.00 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. RossNextBus 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
Re: [Flightgear-devel] Jitter found?
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.00 5064.621582 590.031433 -1211.296509 1.00 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
Re: [Flightgear-devel] Jitter found?
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.00 5064.621582 590.031433 -1211.296509 1.00 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.00 VIEW From 5064.624023 590.030945 -1211.297729 1.00 POS Aircraft 5064.621582 590.031433 -1211.296509 1.00 VIEW From 5064.621582 590.031433 -1211.296509 1.00 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
Re: [Flightgear-devel] Jitter found?
Jim Wilson wrote: 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): Yes, but even between iterations, the FPU error introduces a random 3mm value to the positions you are using. It doesn't matter whether the FDM is right or wrong -- even the tiniest different in input values will result in a 3mm jitter. If the FDM says that the position is different by 4.44E-16 meters (the minimum delta value in a double for a position value of 1m), the output will randomly get moved up to 3mm. Also, not offense intended, but you still seem to be missing the core point: the cockpit is locked down to the aircraft position by definition. No change in position, of any magnitude whatsoever, should produce any detectable change in the cockpit pixels on the screen. Consider a FGLyingBastard FDM that gives you random values: if it moves to the left by 3mm, the cockpit will still be in front of the viewer. If it moves to the right by 7m, the cockpit will still be in front of the viewer. If it warps to Kuala Lampur, ditto. The moon? Yup. Anywhere in the representable universe you try to put the aircraft, the cockpit should still be in front of the viewer. But it's not (quite), it's jittering around. Andy -- Andrew J. RossNextBus 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
Re: [Flightgear-devel] Jitter found?
Curtis L. Olson wrote: 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. Are you all sure the internals of OpenGL are all floats? When I do man glVertex I get: void glVertex2d( GLdouble x, GLdouble y ) void glVertex2f( GLfloat x, GLfloat y ) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitter found?
Erik Hofman writes: Curtis L. Olson wrote: 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. Are you all sure the internals of OpenGL are all floats? When I do man glVertex I get: void glVertex2d( GLdouble x, GLdouble y ) void glVertex2f( GLfloat x, GLfloat y ) Yes, everything internally is floats. OpenGL provides variants glVertex2d, glVertex2f, glVertex2i, glVertex2fv, etc. but these are only for convenience and internally everything gets converted to float. 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
