Order of Transformations (With and Without glPush/PopMatrix)

Hey all,

I feel pretty bad for not understanding this, but now’s the time to learn…

I’m trying to do an intermediate level of applying transformations to my scene, and I just can’t figure it out.

The objective is to have a 32x32 grid of blocks (where each block is 32x32 pixels in glOrtho mode)
So in total I have grids of 1024x1024 pixels.
Also, each block is to have a coordinate between 0 and 31 inclusive. (These are relative to the grid coordinates, which are divisible by 32 and range from 0 to 2.147Bil)

Also, after the first grid, I want another to be directly next to it.

Here’s some psuedo:


public void renderGrid()
{
    glTranslated(GridPos.x, GridPos.y, 0) //This is where I believe I'm having issues.
    getBlocks().render()
}

public void renderBlock()
{
    //Note, the methods used here are in a class "Primitive" that can be used to render any type of object (given the correct VBO's were initialized)
    //So it seems almost mandatory that the transformations are pushed as to not affect anything previous.
    glPushMatrix()
    glScaled(32, 32, 0) //Scale the blocks to be 32x32 pixels
    glTranslated(BlockPos.x, BlockPos.y, 0) //Now we can move each block by another 32 pixels per each coordinate. (so at a coordinate of 31 the bottom-left of the furthers block is at a real coordiante of 992x992.
    glPopMatrix()
}

I don’t know if this is really clear, so please ask for clarification if needed.
I greatly appreciate any help you have, and would like to know how the ordering of transformations affects the results.

Thanks so much! God Bless!
-Nick

You should do some reading in the Viewing chapter of the OpenGL Programming Guide. It describes this pretty well. Or in a good OpenGL tutorial on transformations.

pushMatrix and popMatrix do not change the order of transformations applied. They merely allow you to “save off” the current aggregate transform so you can restore it later. Can be useful when rendering multiple trees of objects within the same parent space.

Thanks for the reply Dark Photon.

Apparently there was more to it than simply ordering the transformations:
First I didn’t scale anything (only performed transformations) . This made the Grids appear 1 after another and the blocks relative to their Grid still. So everything was shrunk and each block took the size of pixel.

Then, my memory started to kick in, and I remembered what scaling the projection matrix did!!! Alas, a ‘camera zoom’ was performed by scaling the projection matrix (remember still in glOrtho), then all I had to do was center the Grids by translating the projection matrix.

Worked like a charm after all that!

Thanks for you help still, it pointed me in the right direction! :slight_smile:

God bless,
-Nick

Generally speaking, you want to avoid putting anything on the PROJECTION stack except the projection transform. You can just scale the size of the box you’re passing glOrtho to do what you want.

Hi Dark Photon,

I took your advice and moved my scale call into the MODELVIEW matrix. Now, at first I put it before my gluLookAt call, and everything was as expected; but if I put it afterwards (which I was doing earlier), I get the wrong results. Do you have any insight as to why this could be?

Also, I am curious why it is bad to modify the PROJECTION matrix other than the initial setup.

Thanks.

In OpenGL, here’s how them matrices are composited when going all the way to clip-space:

PROJECTION * VIEWING * MODELING * v[SUB]obj[/SUB] = v[SUB]clip[/SUB]

As you can see from this order, if you put something on the PROJECTION matrix after the projection, or if you end up putting on the MODELVIEW before the viewing transform, you end up having it in the same order.

As to your latter question, here’s a good post on this. In-short, the space between the PROJECTION and the VIEWING transforms (called EYE-SPACE) is important and used for various functions in the pipeline:

Also, I haven’t traced it through, but I’m not sure your “scale on the projection matrix” trick will work with a perspective transform. Probably safer to tweak your projection transform inputs if you really want to change the frustum.

Thanks again for all your help!

I appreciate you taking the time to help me understand this.

God bless
-Nick.