- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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, ....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page