strange projection results

Hi,

Since the projection pipeline is performed in homogeneous coordinates, shouldn’t a negation of the projection matrix have no effect on the projection?

Here is the code I use:

glClearColor(0.0,0.0,0.0,0.0);
glClear(GL_COLOR_BUFFER_BIT);
	
glDisable(GL_BLEND);
glDisable(GL_DEPTH_TEST);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glFrustum(-1.0,1.0,-1.0,1.0,1.0,10.0);

//negation
GLfloat p[16];
glGetFloatv(GL_PROJECTION_MATRIX,p);
for (int i=0;i<16;++i)
    p[i]=-p[i];

glLoadMatrixf(p);

glColor3f(1.0,1.0,1.0);
glPointSize(5.0);
glBegin(GL_POINTS);
glVertex4f(0.0,0.0,-2.0,1.0);
glEnd();

glutSwapBuffers();

checkErrors();

It displays the point if I skip the negation, otherwise it doesn’t. Could this be a bug in the 66.0 forceware driver I use or have I overlooked something?

Greetz,

Nico

I think your problem is that fragments with negative W are not rendered. This is not a bug, the spec allows for this behaviour. If implementations were required to handle both cases, a line segment where one vertex has W < 0 and the other has W > 0 would require more than one clipping operation.

– Tom

Thanks Tom, this solves my clipping problem.
I’m still getting strange resulst from the projection in my fragment program though.

When I set the modelview matrix to the identity matrix and the projection matrix to an identity matrix with the 3rd and 4th row exchanged, I get strange values for the fragment.position.z value when drawing a vertex (0 ,0 , 2, 1)

I used the following code:

        glClearColor(0.0,0.0,0.0,0.0);
	glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	
	glDisable(GL_BLEND);
	glDisable(GL_DEPTH_TEST);

	glMatrixMode(GL_MODELVIEW);
	glLoadIdentity();

	glMatrixMode(GL_PROJECTION);
	
	GLfloat modelprojection[]={ 1.0,0.0,0.0,0.0,
								0.0,1.0,0.0,0.0,
								0.0,0.0,0.0,1.0,
								0.0,0.0,1.0,0.0};
    
	cerr << modelprojection << endl;
	
	glLoadTransposeMatrixfARB(modelprojection);
	
	glEnable(GL_FRAGMENT_PROGRAM_ARB);
	glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, ModelView);
		
	glPointSize(5.0);
	glBegin(GL_POINTS);
	glVertex4f(0.0,0.0,2.0,1.0);
	glEnd();

	glutSwapBuffers();

	checkErrors();

ModelView is a program with source:

string modelview = 
"!!ARBfp1.0
"
"MOV result.color,fragment.position.z;
"
"END";

PMvertex results in (0,0,1,2)

Because the 4th component of fragment.position is defined as 1/w, its value is 0.5. A point is drawn with rgba values of 128, which is correct.

If I write out fragment.position.z however, it draws a point with rgba color 191, shouldn’t this one also be 0.5 (128 rgba)?

Thanks in advance,

Nico

No, fragment.position stores the window coordinates of the fragment, and those already include the viewport and depth range transformations. Hence, z has already been mapped to the [0, 1] range (coming from [-1, 1]). The value of 191 you’re seeing equates to 0.75, which is correct.

– Tom

Thanks again for clearing up the mystery.

Because depth values are floating point, unlike framebuffer colors which are stored in unsigned bytes, I assumed they had a sign.
Guess I was wrong :slight_smile:

Nico