View Full Version : Skybox & killing performance drop.

01-16-2003, 02:21 AM
I was using some sort of limited world in my engine - simple box with limits. 2 days ago I replaced that thing with skybox. I'm drawing cube with cubemap textures & disabled DEPTH_TEST centred at cameras orgin with size 2x2 units. The problem is in fact that program slows down 3x. Before I had also 6 faces (large polygons 100x20) with texture repeating, but that wasn't so expensive. BTW everything is and were done in display lists.

01-16-2003, 02:26 AM
How about using 2d-textures instead of a cubemap. Just use cubemap sides as 2d-textures and dom't repeat them.


01-16-2003, 03:01 AM
I guess I was misunderstood, I am using 6x2D textures to create skybox. And I'm afraid what will happen if I'll start thinking about dynamic cubemap reflections.
BTW, when I'm creating cubemap, does it comes up as texture in my world or is it used as reflection lookup only?

01-16-2003, 03:33 AM
Originally posted by M/\dm/\n:
I was using some sort of limited world in my engine - simple box with limits. 2 days ago I replaced that thing with skybox.

What's the difference between "simple box with limits" and skybox then?

Cubemap consisting of 6 2D textures is treated as one texture by OpenGL.

Reflection is not a parameter or something in cubemap. It works by specifying some parameters to OpenGL texture generation function - glTexGen().

01-16-2003, 04:12 AM
Actually, skybox is smaller, uses disabled DEPTH_TEST, there is no texture repeating across polygon & it's always drawn as a surrounding, before it was somthing like box I was able to move in.

01-16-2003, 04:22 AM
The difference is really slight and in some games there's also skybox you can move in (the motion is slowed down though on purpose) to simulate you're positioned relatively to say mountains on your skybox...

Actually, skybox is smaller

It doesn't really matter what size your skybox has as it's not moving along with player (assuming static skybox). Skybox of size 1x1x1 and 1000x1000x1000 will be seen exactly same http://www.opengl.org/discussion_boards/ubb/smile.gif

01-16-2003, 08:16 AM
Actually the skybox would be the last thing to draw (but still before any transparency).

Also I wouldn't disable the depth test.
Why disable the depth test when you don't want to draw your skybox where it won't be seen?
In the worst case you'll just have to modify a bit the depth test settings so that the skybox can be actually smaller than the rest of what you're drawing.

But you might consider disabling depth writing, as the skybox can be considered as infinitly far away.

You also might want to split your skybox into smaller quads (e.g. 16 to 64 quads per face).
So that you can make your own occlusion culling on those and/or let modern 3D card do it for you.
Basic frustrum culling would be nice too, avoid drawing cube faces that won't be seen. This way you won't waste your time binding a new texture and sending useless quads.

[This message has been edited by GPSnoopy (edited 01-16-2003).]

01-17-2003, 12:39 AM
What's the difference between depthtest&depthwriting? If I disable depth test & draw my skybox moved away by 1 unit, then enable depth test & draw everything else, it remains (at infinity, all other objects that occlude it comes in front, despite the fact they may be further away z1<z2), only thing I must worry about is skybox center positioning, it must match with cameras position, so that I'll never cross any of skyboxes quads.

01-17-2003, 01:38 AM
The difference is, when you have depth test enabled but depth writes disabled, the depth buffer doesn't get modified, but fragments are tested against the current depths.

That way you can draw your skybox after everything else, changes are you get a little speed improvement thanks to depth testing out occluded fragments.

Frustum culling might me a bit unnecessary, 6 quads won't kill the performance anyways. And at least on my card it seems that a texture doesn't really get "bound" until some triangle using it is actually drawn.


01-18-2003, 11:20 AM
Checked out your recomendations, but there was NO difference in fps between your and my method. Found out that I can get 10+ fps by disabling COLOR_BUFFER_BIT. The performance drop I think is connected with texture res, because when I increase res fps drops down a lot. Sadly, but I can use my skybox only with low res.

01-19-2003, 07:13 AM
Are you sure you are not trying to use a texture that is bigger than the area it will take on screen. In that case mipmapping might help, but I'm not sure if there's any sense in using such accurate textures anyway. Or maybe you are running out of texture memory.


01-19-2003, 10:43 PM
I have 256x256@96dpi textures and they look like crap, skybox takes whole screen & there is almost no difference whether I run windowed, 640x800, 800x640, 1024x728 or 1240x1024 mode. But 512x512@96 textures are too slow.

01-20-2003, 12:28 AM
512*512 shouldn't kill performance. You must be running out of texture memory, a possible solution is to make the other textures in the scene smaller or use less of them. Unless this is about some 300 fps dropping down to 200. In that case, just don't care!


01-20-2003, 12:41 AM
But, how can I surely tell are textures on VCARD or not. There was some kind of querry ARE_TEXTURES_RESIDENT (don't remember for sure), but most of my objects are created in lists and and I asign to those texture u ints another values

unsigned int tex0=0;

, without actually deleting textures, so I'm realy confused.
BTW, if I draw my skybox last with depth masking on, objects are still rewritten by skybox.

01-20-2003, 01:54 AM
I don't know about the first question. To draw the skybox after everything else, you must enable depth test, depth mask doesn't really matter here. Then the you must make sure that the skybox is always behind anything else, so it must have greater z then the other stuff. One way to do this could be to pull near plane really close when drawing the skybox. A more robust approach is to draw normal stuff with depthRange(0, 0.95) and skybox with depthRange(0.95, 1).