real time cube map

OpenGL OpenGL: Advanced Coding
1

Hey guys. I’m working on doing a cube map that changes each frame.

Unfortunately, when I copy the newly rendered images to the cube map, they come out being on the wrong faces and with the wrong orientations! How is this possible? I cut and paste the code from my cube map creation, replacing the copyTexImage2d with a copyTexSubImage2d, but now the textures seem to end up in the wrong places.

The cube map is correct the first time, upon creation, so if I leave it alone it accurately reflects the first environment.

It’s also interesting to note that if I put the gentextures and teximage2d calls back in when I update the cube map, it changes correctly (before it quickly runs out of memory from creating new textures each frame).

Anyone have any idea what might be going on here?

Things I have checked include:

Texture Matrix - identity each time
Texture target - Same each time GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB + i

Thanks,

Zeno

2

Grr. I figured out the problem. glCopyTexSubImage() does NOT work correctly with cube map targets on my GeForce with the newest Nvidia Drivers. Can you look into this, Matt? It will copy the POSITIVE_X_ARB correctly, but none of the others (on mine, they were all copies of POSITIVE_X_ARB).

Changing glCopyTexSubImage() to glCopyTexImage() fixed the problem (with no other code changes), but of course now my program is doing all this extra texture creation. It doesn’t seem to crash, so I guess the old textures must be being released somehow…

Zeno

3

Interesting, especially that no one ever noticed if that’s so… do you have a test app?

I could imagine three behaviors:

  1. When you try to update a different face, we bomb out with a GL error and do nothing.
  2. When you try to update a different face, we do nothing at all, not generating a GL error and not updating any images.
  3. When you try to update a different face, we always update the positive X face, no matter which one you asked us to update.

Which one is it?

Does TexSubImage work where CopyTexSubImage fails?

On first glance the code looks right, but it would be easy to miss something.

  • Matt
4

Well, now you cast doubt on my belief that I’m right . I would also think someone would have noticed this. I can’t send you the app, but I’ll make a test one for you tomorrow. I probably screwed up in some way that I don’t understand yet.

It went something like this, only with more swearing:

Me: OpenGL, please use CopyTexSubImage to replace the POSITIVE_X image in the cube map with a portion of the frame buffer.

OpenGL: Ok, happy to Zeno

Me: OpenGL, please use CopyTexSubImage to replace the NEGATIVE_X image in the cube map with a portion of the frame buffer.

OpenGL: Ok, but I don’t feel like using the frame buffer. I think I’ll just copy the data you gave me before that I’ve got in POSITIVE_X. He he.

Me: Bad OpenGL! Try this: Only replace your NEGATIVE_X image with what’s in the frame buffer.

OpenGL: No, I think what I’ll do instead is put what is in the NEGATIVE_Z map in there. I rule.

Me: ARGH! What if I ask you to use glCopyTexImage() and try them all again?

OpenGL: Why didn’t you say so in the first place? (it worked)

I didn’t check for GL Errors, but whether they’re being generated or not, some data changed with each of my calls to CopyTexSubImage. I believe that all of the cube map sides would display whatever data I put in first, but there was different behaviour if I just replaced ONE side of the cube. It was very confusing and I don’t remember everything I tried, so I’ll investigate more tomorrow and send you an app if it turns out that I wasn’t doing something dumb (which isn’t unlikely).

I don’t know if it matters, but I’m using an ultra.

Thanks again,

Zeno

5

There was indeed a driver bug, which I just fixed.

The fix will be in versions 6.50, 6.64, and 7.20.

The workaround is to use CopyTexImage instead.

  • Matt