PDA

View Full Version : Invariance after PushMatrix/PopMatrix?



Tom Nuydens
04-13-2003, 10:49 AM
I've got some code which first does a normal rendering pass (i.e. render some geometry), then switches to ortho to draw a few fullscreen quads over the scene, and then returns to perspective to do another geometry pass.

I have glPushMatrix()/glPopMatrix() calls surrounding the switch to ortho mode, but the second geometry pass is not invariant, so I get tons of Z-fighting. Is this normal behaviour? Obviously simply changing the top-of-stack matrix breaks invariance, but why should push/change/pop do so? Just doing push/pop without changing it does work.

The spec says invariance is required when changing "the values of matrices other than the top-of-stack matrices". I'm not sure how to interpret this, since it's not possible to change anything other than the top-of-stack matrix unless you push/pop.

I will try to rearrange my code so that the ortho stuff is drawn last, but I'm still interested in hearing your thoughts on whether or not what I'm seeing is normal.

Thanks,

-- Tom

Ysaneya
04-13-2003, 11:15 PM
That could be explained by the states you've changed between the first and second rendering passes (if any). You already know that mixing fixed T&L and vertex shaders is not invariant, but i think it's also true for some states; i clearly remember it being the case with lighting on some old video cards, so...

If i were you i'd try to enable/disable individually the states to see which one is causing the Z-fighting. Other than that... no idea.

Y.

PH
04-13-2003, 11:29 PM
You could try to load the matrices using glLoadMatrixd rather than glLoadMatrixf. It could be that the driver stores matrices using doubles and it's likely the conversion from (float)->(double) breaks invariance ( assuming that you use the float API call ). On the other hand, I don't see how this could be a problem.

Other than that, changing matrix mode is not on the required list ( but that's not likely the problem ).

[This message has been edited by PH (edited 04-14-2003).]

Tom Nuydens
04-13-2003, 11:53 PM
Thanks for the feedback, guys. I narrowed it down to this:



glCallList(myScene);
glMatrixMode(GL_PROJECTION);
glPushMatrix;
glLoadIdentity;
glPopMatrix;
glMatrixMode(GL_MODELVIEW);
glCallList(myScene);

Removing the glLoadIdentity() call fixes it. However, I believe I also only enable blending for the second pass, and I just noticed that blending is not on the required list. The blending function is on the "strongly recommended" list, but the enable is not.

I don't have my code with me at the moment, but I'll look into that tonight. It would be peculiar in this case that the glLoadIdentity() call is what triggers the problem, though.

-- Tom

(EDIT: Forgot to switch back to GL_MODELVIEW)

[This message has been edited by Tom Nuydens (edited 04-14-2003).]

Mazy
04-14-2003, 12:46 AM
Silly question, but i must ask, your displaylist doenst depend on that your current matrix is the Modelview, i hope?

Tom Nuydens
04-14-2003, 01:12 AM
Sorry, that's just a typo in my previous post. I do set it back to GL_MODELVIEW, of course.

-- Tom

V-man
04-14-2003, 04:56 AM
Originally posted by PH:
You could try to load the matrices using glLoadMatrixd rather than glLoadMatrixf. It could be that the driver stores matrices using doubles and it's likely the conversion from (float)->(double) breaks invariance ( assuming that you use the float API call ). On the other hand, I don't see how this could be a problem.

Other than that, changing matrix mode is not on the required list ( but that's not likely the problem ).

[This message has been edited by PH (edited 04-14-2003).]

If the graphics card is using the cpu to do matrix calculations some of the time, it will lead to a major disaster like this.
If the card is making this mistake, then using float or double won't help you.

What does the GL spec say about this?
I think driver writers know this problem very well and I assumed it was a non-issue.