Dynamic cube maps and windowed mode


A strange problem occurred to me after developing a dynamic cube mapping:

It seems that the cubemap textures aren’t fully updated when running the demo in windowed mode with resolution 1024x768. There’s a small area of garbage in every cubeface texture. It looks like it’s not updating the whole texture. If I run the same piece in fullscreen mode 1024x768 the textures update just fine.

Other resolutions like 640x480 or 800x600 work just fine too, fullscreen or not.

My cubemaps are 256x256. I tried to lower them as low as 64x64 but it didn’t make any difference.

I runned some tests I’ve cut the problem down to the updating function as static cubemaps seem to work fine in any resolution or screen mode.

Here’s the function I use:

void Mirroring::renderEnvironment()
	unsigned int i;	
	glViewport(0, 0, 256, 256);

	/* Setup 90 FOV perspective */
	gluPerspective(90.0f, 1.0f, 1.0f, 5000.0f);

	for(i = 0; i < 6; i++)

		glRotatef(rotations[i][0], rotations[i][1], rotations[i][2], rotations[i][3]);
		if(i == 0 &#0124; &#0124; i == 1)
			glRotatef(180.0f, 0.0f, 0.0f, 1.0f);			

		glBindTexture(GL_TEXTURE_CUBE_MAP_EXT, cubeMap);
		glCopyTexSubImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_X_EXT+i, 0, 0, 0, 0, 0, 256, 256);

	sys.resize(win.getWidth(), win.getHeight());

	glViewport(0, 0, win.getWidth(), win.getHeight());	

I hope the code appears ok as this is my first post

If someone has been similar problems I’d be glad to here how they’re been solved.


Any screenshots showing the garbage? My own dynamic cubemap demo runs fine in any windowed size. What hardware and drivers are you using?

Edit: Hmmm I replied, yet the forum page, says 0 replies… oddd…

[This message has been edited by Nutty (edited 08-06-2003).]

Like Nutty my cube maps update OK at any resolution with windowed mode.

I presume you are using a single context (ie. the Window) to update - rather than pbuffers? If so is there a chance that there is something overlapping your window, or that part of the window (in the area where the pbuffer would be drawn) is off the screen?

[EDIT] A tip for you while I’m at it, only update one side of your cube map each frame. You most likely won’t notice any problems and it provides a great speed increase.

[This message has been edited by rgpc (edited 08-06-2003).]

Nutty, Sorry for not posting an image. I try to get one asap, but I need to do some code cleaning as I’m in middle of hectic coding.
(I’ll just let it be for this prod)

rpgc, that might be possible. The window is same size as my desktop so it is slighty over the edge when viewing it in windowed mode. However, I thought that WS_CLIPSIBLINGS and WS_CLIPCHILDREN would prevent other applications from drawing into my openGL-window?

Maybe I should check the window creation code again, there might be some flag that overrides the clip styles(?)

Thanks for the help,

  • Vman

Ok, the problem is solved (allmost). I changed my desktop to bigger resolution and runned the 1024x768 window demo.

The textures were updated fine. So it seems that rpgc was right with this

I should debug my window flags, tnx fellows.


It actually has nothing to do with the “rights” of other applications etc. If a fragment is not visible (ie. Under another window or off the screen) then it’s contents are undefined with respect to Opengl.

Basically this means that if a fragment is not visible, opengl can ignore it completely.

If you execute your application and then drag another window over it, you will get the same effect (Eg. Open and drag Calc over the lower left corner of your apps window and you’ll see the same effect).

That is why pbuffers were created (to allow drawing onto non-visible surfaces).

In general, neither the front nor the back buffer has defined contents in windowed mode; especially in the case of not the entire window being visible (obscured by monitor edges or other windows, say).

If you need predictable render-to-texture or render-to-buffer-copy-to-texture in windowed mode, the only good solution is pbuffers.