OpenGL points and lines

[idata]

Here is the version of OpenGL I am using.

OpenGL version: 3.1.0 - Build 9.17.10.2875

OpenGL vendor: Intel

OpenGL renderer: Intel(R) HD Graphics 3000

Here is the code that displays some points along a vertical and horizontal lines and the corresponding OpenGL lines

// white points

glColor3f(1.0f, 1.0f, 1.0f);

glBegin(GL_POINTS)

for (int r = 1; r < 10; ++r) {

// vertical points

glVertex2i(2, r);

// horizontal points

glVertex2i(r, 20);

}

glEnd();

// red line

glColor3f(1.0f, 0.0f, 0.0f);

glBegin(GL_LINES);

// vertical line

glVertex2i(2, 1);

glVertex2i(2, 9);

// horizontal line

glVertex2i(1, 20);

glVertex2i(9, 20);

glEnd();

The magnification of the resulting image is:

My question is: why doesn't the red line cover the white line? It appears that GL_POINTS and GL_LINES made with the same coordinates map to different window coordinates. Why is there an offset?

Thanks

[NICHOLAS_F_Intel]

Hi rapademic,

What happens if you put line 04 to

for (int r = 1; r <= </span>9; ++r) {

OR

for (int r = 1; r < 9; ++r) {

I would think if r = 1, and you kept incrementing by 1 until it reached < 10, it would say "r = 9, and that's still less than 10, so let's increment again", resulting in the +1 overshot, skewing the results for both your white horizontal/vertical points, no?

-Nic

[idata]

Thanks for the response Nic. The problem is not one of inconsistent indices. There appears to be something different in the way Intel OpenGL interprets points and lines. In the specific example I give above, the vertical points that get plotted are: (2, 1), (2, 2), (2, 3), (2, 4), (2, 5), (2, 6), (2, 7), (2 8), and (2,9). The vertical line is plotted from (2, 1) and goes to (2, 9). In other words, the points and line I give to OpenGL are the same and yet both the points and line are visible on the screen. Evidently, there is a one off error between the glBegin(GL_POINTS) and glBegin(GL_LINES) for the Intel implementation of OpenGL. I do not have access to another manufactures version of OpenGL to prove my hypothesis, but I will at some point in time.

Thanks again.

[NICHOLAS_F_Intel]

In the first case with the horizontal line, the white point is still showing because your red line is only set to go to (9,20), whereas your white point stops at (10,20). This is also why your vertical white points are larger than your vertical red line.

As for the vertical lines not overlapping each other, I'm not sure. I'll see if I can get an answer on that.

-Nic

[NICHOLAS_F_Intel]

Okay, here is the answer I have been given by our OpenGL expert;

"This kind of behavior is expected in OpenGL. The vertex location described in floats must be in some way translated to the pixel location (which is integer) and the way that the translation and rounding is done is not strictly described in the OpenGL specification. It is really implementation dependent."

Thanks,

-Nic

[idata]

Dear Nic,

Thank you for your time and effort with this issue.

The loops plotting the points begin and end at the same exact screen coordinate location. There is not an off-by-one error.

I used integer coordinate locations in the code, glVertex2i to avoid rounding and approximation issues in OpenGL. I understand OpenGL internally stores its data in floating point format, but my hope was that the floating point error would have the same biases converting integers into floats and back to integers again for both GL_POINTS and GL_LINES. Evidently this is not true in the Intel implementation.

Yes, I agree it is implementation issue. To me the next question is, does Intel want its implementation to map the same vertices specified as GL_POINTS and GL_LINES to different screen coordinates? Another question would be, which other parts of the OpenGL implementation give erroneous results? Should I anticipate texture mapping errors, MIPMAP errors, ....

[idata]

Let me add my two cents here:

You seem to assume that drawing a line from, say (1,20) to (9,20), actually includes all fragments

within [1,9] at y = 20. But this is not the case, as soon as those coordinates map to fragment centers.

To understand this, take a look at the OpenGL - specification:

http://www.opengl.org/documentation/specs/version2.1/glspec21.pdf http://www.opengl.org/documentation/specs/version2.1/glspec21.pdf

From Page 102 (I hope I don´t infringe on any copyrights here):

3.4.1 Basic Line Segment Rasterization

...

"When pa and pb lie on fragment centers, this characterization of fragments

reduces to Bresenham's algorithm with one modification: lines produced in this

description are "half-open," meaning that the final fragment (corresponding to

pb) is not drawn."

...

The specification refers to OpenGL 2.1, but since you are using immediate mode,

it should be valid here. Aside from that, I doubt, line rasterization has been changed

in higher OpenGL versions.

Try applying a small displacement, perhaps glTranslatef(0.3, 0.3, 0.),

to your current GL_MODELVIEW transformation and see what you get.

[idata]

Thank you Mike. That was good advice on looking closely at the spec. Thanks for the link. This does not explain the off-by-one error when drawing vertical lines.

Paul