I’m writing a film resolution movie color correction app on an 8800GTS. My source texture is 2048x1556. When applying geometric transformations, the rotation created with glRotate causes the image to be stretched while at 90 degrees and 270 degrees into a rectangle of the original aspect ratio (4:3, when it should be 3:4). I wouldn’t think this is a NON_POWER_OF_TWO issue. Would using a larger square texture of 2048 x 2048 and sub-textue into the center solve the problem, or is there something simple I’m missing. I’m grateful for your advice.
The only thing I can think of that might cause this to happen is that the initial vertex coordinates are already stored in a way that makes glRotate cause this. For instance if you use (0,0) (1,1) for the corner vertices this would happen. You need to make sure the vertex coordinates of the rectangle are 4:3 in the first place.
[ www.trenki.net | vector_math (3d math library) | software renderer ]
Trenki: You’re amazing! I would never have even thought of that. None of the books describe this phenomenon. You are correct that I use (0->1) coordinates. If I use (0,0) (4,3) for coordinates, are there any other types of code areas that would need to be revised (ie viewports, etc)? or is the texture coordinate system invisible to other openGL code?
After much experimentation with both vertex and texture coordinates, the only solution I can find is to create a larger square texture of 2048 x 2048 and adjusting the clipping plane with glOrtho to truncate the top/bottom texture areas that are not needed.
Since glRotate only affects the modelview matrix, which in turn only affects vertex positions (not texture coords), I would think you could just change your vertex locations without touching texture at all.
Of course, you’d have to adjust your projection matrix (gluLookAt or glOrtho) to compensate, but that goes without saying.
Originally posted by Lindley:
[b] Since glRotate only affects the modelview matrix, which in turn only affects vertex positions (not texture coords), I would think you could just change your vertex locations without touching texture at all.
Of course, you’d have to adjust your projection matrix (gluLookAt or glOrtho) to compensate, but that goes without saying. [/b]
Any matrix function, including glRotate, affects whatever matrix stack is the currently active one. No matrix function is limited to a particular set of stacks, but can operate on all of them.
All right, true. But who knows what the heck would happen if you tried to apply glRotate to something other than the modelview matrix? And why would you want to find out?
It might work. Depends on the final order in which things are applied. But that gets rather tricky to keep track of.
Easier to just conceptually consider anything else a bug.
But who knows what the heck would happen if you tried to apply glRotate to something other than the modelview matrix?
It would do what glRotate does to the modelview matrix stack.
Matrix stacks aren’t some form of magic; they’re matrices. What glRotate will do to the projection matrix stack is exactly what it does to the modelview matrix stack.
It will create a rotation matrix about the given axis by the given angle, and multiply it with the matrix on the current matrix stack.
Now, what that means is an entirely different story. And that depends on how the user is using OpenGL.
If the user is using GL the way that GL describes the semantics, then glRotate probably shouldn’t be applied to the projection matrix. However, if the user is using semantics where the projection matrix stores the projection and the camera, and the modelview is only the model-to-world (rather than model-to-camera), then glRotate is perfectly reasonable for a camera operation.
Now granted, these semantics change quite a few things, like how GL’s fixed-function lighting works. But they’re perfectly viable, so long as you know what you’re doing.