In My App I draw a bezier and have the cntrl points etc drawn on top using glpoint so the user can drag them about. This is fine, but if I translate the whole lot then the points and bezier drift by about1/2 pixels. This wouldn’t be a problem but we are doing this in stereo so the points move in/out from the bezier loop? I would assume this is a pixel rounding type error? Anyone shed any light? I just thought would using glint instead of float help
cheers
Hi,
Are you already using antialiasing? That might help.
-Ilkka
No, on that note I could just make the line a few more pixels wide I suppose
Using GLint for the point coordinates will not help because you render on the pixel’s corner instead of the pixel center. Specify points at fragment centers.
And it won’t work when applying translations wich are not multiples of pixels.
If your stereo setup doesn’t use the parallax shift instead of a rotate or look-at method, you will get these errors anyway, due to the perspective shortening on the opposite sides of the model.
The easiest solution is probably to use GL_POINT_SMOOTH to render antialiased points and increase the size a little. These may not drift that much, or at least you won’t notice it.
(I think that’s what JustHanging meant. If not, be careful with full scene antialiasing and assumptions of pixel centers. Pixels != fragments.)
[This message has been edited by Relic (edited 04-01-2003).]
Its done in ortho so perspective shortening!?
translatef
begin
draw bezier
draw bezier points
end
the translate is used for the disparity if translatef is 0’s the points all align up ok
as soon as the l/r eye images are translated -x/x this drift occurs.
I can think why this happens. The GLInt theory was because would opengl truncate floats when going to raster coords or will it round? This shouldn’t be an issue just can’t think of anything else.
After checking my code I will summarise the problem a little clearer.
glPushMatrix
gltranslatef(x, 0, 0);
for n=0 to 10
draw_point(i[n], j[n]);
pass_points_to_gl_bezier_func_map1(i, j);
glPopMatrix
translatef, when x != 0, translates the glbezier and the glpoints inconsistently.
I don’t have stereo on this card so can’t check this so am not sure if the ‘drift’ increases as the x in translatef does.
Aliasing/increasing line width won’t help. The translatef translates -x/+x in the l/r eye. The width of the lines is irellevant as to the disparity. The disparity is the distance (x) between the same point in corresponding images.
The rasterization rules for line endpoints and points are not identical. Refer to the OpenGL specs.
OpenGL coordinates after transformation are always floating point.
As I said, rendering the points at pixel’s corner coordinates has a greater chance to fall into another pixel due to floating point rounding errors than points which are rendered at fragment center coordinates. All that implies that your ortho setup is pixel aligned and you only translate in integer steps.
If not, you just have to live with a 1/2 pixel rounding error.
It may be a horrific bodge but would drawing a 2px x 2px poly/quas sort rhis out i.e. make my own Gavs_glPoint func… There is never more than a hundred points (or so) at one time.