Question

I’m writing a plugin for an application called Autodesk MotionBuilder, which has an OpenGL renderer, and I’m trying to render textured geometry into the scene. I have a window with a 3D View embedded in it, and every time my window is rendered, this is (in a nutshell) what happens:

1. I tell the renderer that I’m about to draw into a region with a given size
2. I tell the renderer to draw the MotionBuilder scene in that region
3. I draw some additional stuff into and/or on top of the scene

The challenge here is that I’m inheriting some arbitrary OpenGL state from MotionBuilder’s renderer, which varies depending on what it’s drawing and what’s present in the scene. I’ve been dealing with this fine so far, but there’s one thing I can’t figure out. The way that OpenGL interprets my UV coordinates seems to change based on whatever MotionBuilder is doing behind my back.

Here’s my rendering code. If there’s no textured geometry in the scene, meaning MotionBuilder hasn’t yet fiddled with any texture-related attributes, it works as expected.

// Tell MotionBuilder's renderer to draw the scene
RenderScene();

// Clear whatever arbitrary state MotionBuilder left for us
InitializeAttributes(); // includes glPushAttrib(GL_ALL_ATTRIB_BITS)
InitializePerspective(); // projects into the scene / loads matrices

// Enable texturing, bind to our texture, and draw a triangle into the scene
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, mTexture);

glBegin(GL_TRIANGLES);
glColor4f(1.0, 1.0, 1.0, 0.5f);
    glTexCoord2f(1.0, 0.0); glVertex3f(128.0,   0.0, 0.0);
    glTexCoord2f(0.0, 1.0); glVertex3f(  0.0, 128.0, 0.0);
    glTexCoord2f(0.0, 0.0); glVertex3f(  0.0,   0.0, 0.0);
glEnd();

// Clean up so we don't confound MotionBuilder's initial expectations
RestoreState(); // includes glPopAttrib()

Now, if I bring in some meshes with textures, something odd happens. My texture coordinates get scaled way up. Here’s a before and after:

_{(source: awforsythe.com)}

As you can see from the close-up on the right, when MotionBuilder is asked to render a texture whose file it can’t find, it instead loads this small question mark texture and tiles it across the geometry. My only hypothesis is that MotionBuilder is changing some global texture coordinate scalar so that, for example, glTexCoord2f(0.5, 1.0) will instead be interpreted as if it were (50.0, 100.0). Is there such a feature in OpenGL? Any idea what I need to modify in order to preserve my texture coordinates as I’ve entered them?

---

Since typing the above and after doing a bit of research, I have discovered that there’s a GL_TEXTURE matrix that’s used to this effect. Neat! And indeed, when I get the value of this matrix initially, it’s the good ol’ identity matrix:

 1  0  0  0
 0  1  0  0
 0  0  1  0
 0  0  0  1

When I check it again after MotionBuilder fudges up my texture coordinates:

16  0  0  0
 0 16  0  0
 0  0  1  0
 0  0  0  1

How telling! But here’s a slight problem: if I try to explicitly set the texture matrix before doing my own drawing, regardless of what MotionBuilder is doing, it seems like my texture coordinates have no effect and it simply samples the lower-left corner of the texture (0.0, 0.0) for every vertex.

Here’s the attempted fix, placed after RenderScene in the code posted above:

glMatrixMode(GL_TEXTURE);
glLoadIdentity();

I can verify that the value of GL_TEXTURE_MATRIX is now the identity matrix, but no matter what coordinates I specify in glTexCoord2f, it’s always drawn as if the coordinates for each vertex were (0.0, 0.0):

_{(source: awforsythe.com)}

Any idea what else could be affecting how OpenGL interprets my texture coordinates?

Answer 1

Aha! These calls:

glMatrixMode(GL_TEXTURE);
glLoadIdentity();

…have to be made after GL_TEXTURE_2D is enabled.

…should be followed up by setting the matrix mode back to GL_MODELVIEW. It turns out, apparently, that some functions I was calling immediately after resetting the texture matrix (glViewport and/or gluPerspective?) affect the current matrix stack. So those calls were affecting the texture matrix, causing my texture coordinates to be transformed in unexpected ways.

I think I’ve got it now.