I’ve got different behaviour on ATI and NVIDIA hardware with the following code sample :
glEnable(GL_CLIP_PLANE0);
glRasterPos2i(0,0);
glBitmap(0, 0, 0, 0, x, y, NULL); // x,y in range [-1,1]x[-1,1]
glListBase(listbase);
glCallLists(strlen(textline), GL_UNSIGNED_BYTE, textline);
The last two lines consist in rendering some text using bitmaps, just as described in NeHe’s tutorial.
Imagine the clip plane splits the screen vertically so that left half lie in the half-space allowed, and right half is clipped.
If the raster position is defined in the left part of the screen, the text is rendered.
If the raster position is defined in the right part, the text is rendered with ATI graphics card and not with NVIDIA graphics card. I guess that NVIDIA’s implementation clears the valid bit of the raster position whereas ATI’s implementation sets the valid bit.
Which is the good one ?
Indeed, in OpenGL1.4 specifications (p42, ch2.12 Current Raster Position) there is written :
“The transformed coordinates are passed to clipping as if they represented a point.”
What kind of ‘clipping’ is discussed here ? Only the view volume, or should client-defined clipping planes be taken in account too ?
TIA,
[This message has been edited by vincoof (edited 01-07-2003).]
I have another question which answer may also resolve the above problem :
Since user-defined clipping planes are specified in eye-space coordinates, and since the view volume is specified in window-space coordinates, how can both clipping (user-defined and view volume) interact ?
I mean, when rendering a line with an extremity inside the clipping “space” and the other extremity outside the clipping space, OpenGL has to compute the point where the line intersects the clipping “limits”. Is that point computed differently for view volume’s clipping and for user-defined clipping ?
The view volume is, as it sounds, the volume defined by the viewing frustum (be it orthographic or perspective).
From OpenGL1.4 specifications, ch2.11 Clipping :
“Primitives are clipped to the clip volume. In clip coordinates, the view volume is defined by
-wc <= xc <= wc
-wc <= yc <= wc
-wc <= zc <= wc”
So it’s defined in clip-space coordinates (sorry I’ve written window-space coordinates in my previous post).
And then client-defined clipping planes work in eye-space because it is specified that :
“All points with eye coordinates (xe ye ze we)T that satisfy
(p’1 p’2 p’3 p’4) (xe ye ze we)T >= 0
lie in the half-space defined by the plane; points that do not satisfy this condition do not lie in the half-space.”
where (p’1 p’2 p’3 p’4) are defined in this text btw :
“A client-defined clipping plane is specified with
void ClipPlane( enum p, double eqn[4] );
(…) eqn is an array of four double-precision floating-point values. These are the coefficients of a plane equation in oject-coordinates: p1, p2, p3 and p4 (in that order). The inverse of the current model-view matrix is applied to these coefficients, at the time they are specified, yielding
(p’1 p’2 p’3 p’4) = (p1 p2 p3 p4) M^-1
to obtain the plane equation coefficients in eye coordinates.”
The point on the wrong side of an enabled user clip plane would be culled, and so would the raster position. So the raster position would not be valid. This means that any subsequent pixel primitives would not be drawn.
OpenGL has to compute the point where the line intersects the clipping “limits”. Is that point computed differently for view volume’s clipping and for user-defined clipping ?[/b]
Hmm, maybe this just adds to the confusion.
I remember reading in nvidias old opengl performance faq that user-defined clip planes are hw accelerated when you have a texture unit to spare. One plane for each unit, I think. Otherwise, clipping is done in software. I am assuming eye-space for software and clip-space for hardware.
OpenGL has to compute the point where the line intersects the clipping “limits”. Is that point computed differently for view volume’s clipping and for user-defined clipping ?[/b]
Hmm, maybe this just adds to the confusion.
I remember reading in nvidias old opengl performance faq that user-defined clip planes are hw accelerated when you have a texture unit to spare. One plane for each unit, I think. Otherwise, clipping is done in software. I am assuming eye-space for software and clip-space for hardware.
“OpenGL has to compute the point where the line intersects the clipping “limits”. Is that point computed differently for view volume’s clipping and for user-defined clipping ?”
Hmm, maybe this just adds to the confusion.
I remember reading in nvidias old opengl performance faq that user-defined clip planes are hw accelerated when you have a texture unit to spare. One plane for each unit, I think. Otherwise, clipping is done in software. I am assuming eye-space for software and clip-space for hardware.
Thanks pat, I also think you’re right since I’ve then seen that other hardware (MATROX) behaves like NVIDIA.
I’ve contacted the ATI developer relations team so it should be fixed sooner or later in ATI drivers.
roffe: yes I’ve heard many times on the board that NVIDIA cards prior to GF3 use texture units to emulate clipping in hw. If only they could implement the EXT_clip_volume_hint extension, every NVIDIA card would logically benefit 6 new texture units
