Vertex Clipping problem

Hi All,
I have a dumb question here but just can’t seem to figure it out. I have my matrices setup as follows

GL.glViewport(x, y, width, height);
GL.glMatrixMode(GL.GL_PROJECTION); GL.glLoadIdentity();

this is using JOGL (Java) by the way any way I am submitting a series of vertices and they get clipped when I think they should not (I’ve been using the feedback buffer to check this). I use the following to submit the vertices


where ptaa - ptdd are generated. If I submit them in the following form with out dividing across by H as follows
ptaa [-261.3766 -261.37653 -2624.2202 -5.2275305]
ptbb [-3201.8552 -271.3437 -2724.2903 -5.426873]
ptcc [-239.51077 -2059.7922 -2404.688 -4.790215]
ptdd [-2924.6704 -2131.539 -2488.448 -4.957068]
They are culled (not displayed). However, if I divide across by H and submit them then as follows
ptaa [50.00001 50.0 501.99997 1.0]
ptbb [590.0 50.000004 502.0 1.0]
ptcc [50.000004 429.99994 502.0 1.0]
ptdd [590.00006 429.99997 501.99997 1.0]
then they are displayed fine. So my question is when does the clipping occur it seems it happens before the divide by H? So how do I alter the clip volume to allow these kind of vertices through. Ideally I want to submit my points in the following for and have a matrix perform the projection. In this case the points will be submitted as follows
pta [0.7680671 0.52067035 5.2275305 1.0]
ptb [6.625495 0.54052526 5.426873 1.0]
ptc [0.7247276 4.103172 4.790215 1.0]
ptd [6.073568 4.2460938 4.957068 1.0]
and the transformation matrix is given by

[-502.0 -0.0 -0.25 125.5]
[-0.0 -502.0 -0.0 0.0]
[-0.0 -0.0 -502.0 0.0]
[-0.0 -0.0 -1.0 0.0]

which project a point throught a center of projection unto a plane to produce the point ptaa-ptdd used before. But if I use this as my model view matrix the points are clipped just like the first set. This matrix is produced by the followin routine

* Projects a point unto a plane via a ray starting at the center of projection
* @param COP center of projection
* @param plane plane coefficients ax + by + cz + d = 0
* @param M resulting matrix to perform projection
public static void MProjectToPlane4x4(float[] COP,float[] plane,float[] M)
float NCOP = DotProduct3D(plane,COP);

	M[0] = NCOP + plane[3] - COP[0]*plane[0];	M[4] = -COP[0]*plane[1];					M[ 8] = -COP[0]*plane[2];					M[12] = -COP[0]*plane[3];	
	M[1] = -COP[1]*plane[0];					M[5] = NCOP + plane[3] - COP[1]*plane[1];	M[ 9] = -COP[1]*plane[2];					M[13] = -COP[1]*plane[3];
	M[2] = -COP[2]*plane[0];					M[6] = -COP[2]*plane[1];					M[10] = NCOP + plane[3] - COP[2]*plane[2];	M[14] = -COP[2]*plane[3];
	M[3] = -plane[0];							M[7] = -plane[1];							M[11] = -plane[2];							M[15] = NCOP;

Does anyone have a idea as to how to get around this?

William Leeson

i think your call


is the problem. the last two parameters of glOrtho define the near and far clipping plane distance. in your example, the far distance is smaller than the near distance, which could cause trouble. anyway, it doesn’t make sense to me to have a negative value, because this means that the plane is behind the viewer.

if you try


you will see all objects which are between 1 and 1000000 units away from the viewer.

furthermore, you should not use a value of zero for the near distance; the far distance value should not be too big, because it affects z-buffer precision.

hey guys, near plane values <= 0 are perfectly acceptable in ortho projections.

Hi All,
It doesn’t matter which way I put the near and far clipping planes (tried it both ways and it made no difference). I have had a scan over the OpenGL reference manual and it seems to imply that the divide by W or H happens after the view volume clipping. Is that correct? In which case my point would be outside. However, when the divide by W or H happen the point is now within the view volume. So since this divide happens after the view vol. clip my data is ignored. Are there any ways to get by this?

William Leeson


don’t want to minimize you, but i think you have some basic problems. you say you divide coordinates by W and H- the window width and height?- seems strange to me, usually you don’t divide vertex coordinates by whatever.

if you are just trying to get into opengl, start with a simple example. draw a quad:

glOrtho(-1., 1., -1., 1., 1., 100.);

gluLookAt(0., 0., 10., 0., 0., 0., 0., 1., 0.);

glViewport(0, 0, W, H);

glColor3f(1., 0., 0.);
glVertex3f(-.75, -.75, 0.);
glColor3f(0., 1., 0.);
glVertex3f( .75, -.75, 0.);
glColor3f(0., 0., 1.);
glVertex3f( .75, .75, 0.);
glColor3f(1., 1., 0.);
glVertex3f(-.75, .75, 0.);


by the way, bonehead- near/far/whatever=0 may be working in the red book, but in reality you do not know what happens if you pass it to your library, unless you have programmed your libGL by yourself. as i took a look at the manual pages for glOrtho on a SGI today, it said that near MUST not be zero. but that’s SGI- maybe the programmers at NVIDIA catch the case that you pass zero for near. but you can never be sure…

hey GreetingsFromMunich, i couldn’t find the reference you mentioned. do you have a link? all the references i know of say that near and far can be either positive or negative, and that the only concern is to ensure that (far - near) is never zero, as this would introduce a division by 0 in the projection matrix. same goes for (right - left), and (top - bottom).

anyways, heres’s a link to ortho:…html#id5511492

and here’s the official spec:
have a peek at page 46.

you might be thinking of the perspective stuff (glFrustum). in that case, you’re right, near and far must be strictly > 0.

By W or H I am refering to the 4 element of the vertex (not the width or height of the viewport).ie
[x y z w]
[x y z h]
which is specified for example using
during the viewport transformation stage the value is converted to
[x/w y/w z/w]
but unfortunately for me clipping is performed before this, according to the diagram in the blue book (reference manual) if I understand it correctly. What I am looking for is to confirm this or a way of getting around this. So there is a divide by w before the clipping for instance.

William Leeson

jup, bonehead…you’re right.