
1. Re: OpenGL points and lines
nic Jan 8, 2013 3:28 PM (in response to rapademic)Hi rapademic,
What happens if you put line 04 to
for (int r = 1; r <= 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

2. Re: OpenGL points and lines
rapademic Jan 9, 2013 8:21 AM (in response to nic)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.

3. Re: OpenGL points and lines
nic Jan 9, 2013 11:14 AM (in response to rapademic)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

4. Re: OpenGL points and lines
nic Jan 10, 2013 2:50 PM (in response to nic)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

5. Re: OpenGL points and lines
rapademic Jan 11, 2013 1:33 PM (in response to nic)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 offbyone 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, ....

6. Re: OpenGL points and lines
messerli_mike Jan 15, 2013 11:58 AM (in response to rapademic)1 of 1 people found this helpfulLet 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
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 “halfopen,” 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.

7. Re: OpenGL points and lines
rapademic Jan 28, 2013 5:19 PM (in response to rapademic)Thank you Mike. That was good advice on looking closely at the spec. Thanks for the link. This does not explain the offbyone error when drawing vertical lines.
Paul