Skies and 3D ness

[Baker]

I thought I came up with a cheap way to use a single texture as a sky background as a single quad in 2D (ortho) before going to 3D. (Ignore the inefficiency of a huge quad that cannot be drawn last and potentially Z-failed)





But although it "works", it has no 3D feel to it and when you turn, objects actually in 3D aren't in sync with the background since the background is rendered as 2D and lacks curvature.

Obviously, the next thing I start doing is looking for an old skysphere tutorial hiding somewhere around here, hehe ...

[taniwha]

QuakeForge has a sky-sphere option (hiding in libs/video/renderer/gl/gl_sky.c as skydome).

That said, you might want to review map projection before getting too carried away. The best way to get good spherical mapping in GL is with a cube-map texture (or failing that, look at gl_sky_clip.c in QF (same place as gl_sky.c).

[Baker]

QuakeForge has a sky-sphere option (hiding in libs/video/renderer/gl/gl_sky.c as skydome).

That said, you might want to review map projection before getting too carried away. The best way to get good spherical mapping in GL is with a cube-map texture (or failing that, look at gl_sky_clip.c in QF (same place as gl_sky.c).

/ +1 to queue. I'm hoping cubemaps don't require an extension or ... that the extension is virtually omni-present.

Thanks!

[Spike]

cubemaps are the way to go.
they've been supported universally since at least the geforce2.

If you want a faithful sky, glsl is much much better than a skysphere.

Either option allows you to draw polys only where the sky actually is, so small windows on eg dm2 don't result in massive overdraw. Both can also be depth-tested properly, and will not result in leaks.

[leileilol]

they've been supported universally since at least the geforce2.

Since the GeForce256 actually

Perpixel lighting generally requires cubemapping, so pretty much everything modern should support it. You'll only screw over the 7 people in the world who still use a 3dfx.

[mh]

Another +1 for cubemaps here. The only downside is that you need to re-orient the images from Quake's standard layout to a layout appropriate for cubemaps (Doom 3 has code for doing that, all sides must be square, and all sides must be the same size. You can write shader code to do your own cubemapping manually, at some (small) performance cost, as a fallback if you can't meet those, but in the general case cubemaps are just fine.

[taniwha]

Eh? Every cube-map I've tried worked just fine, though I did have to play around with things a little (like which map is "up", and a little swizzle).

shader code (minus decls and fog calc):

Code: Select all

void
main (void)
{
    vec3        dir = direction;

    dir *= inversesqrt (dot (dir, dir));

    // NOTE: quake's world and GL's world are rotated relative to each other
    // quake has x right, y in, z up. gl has x right, y up, z out
    // The textures are loaded with GL's z (quake's y) already negated, so
    // all that's needed here is to swizzle y and z.
    gl_FragColor = fogBlend (textureCube(sky, dir.xzy));
}

fun stuff in glsl_bsp.c:

Code: Select all

    // NOTE: quake's world and GL's world are rotated relative to each other
    // quake has x right, y in, z up. gl has x right, y up, z out
    // However, skymaps have lf and rt swapped :/    lf    rt
    static const char *sky_suffix[] = { "ft", "bk", "rt", "lf", "up", "dn"};
    static int  sky_coords[][2] = {
        {2, 0}, // front
        {0, 0}, // back
        {2, 1}, // left
        {1, 0}, // right
        {1, 1}, // up
        {0, 1}, // down
    };
    static int  sky_target[] = {
        GL_TEXTURE_CUBE_MAP_POSITIVE_X, // front
        GL_TEXTURE_CUBE_MAP_NEGATIVE_X, // back
        GL_TEXTURE_CUBE_MAP_POSITIVE_Z, // left  (normally -ve Z, see shader)
        GL_TEXTURE_CUBE_MAP_NEGATIVE_Z, // right (normally +ve Z, see shader)
        GL_TEXTURE_CUBE_MAP_POSITIVE_Y, // up
        GL_TEXTURE_CUBE_MAP_NEGATIVE_Y, // down
    };

BTW, sky_coords is for directly using env maps exported from blender (single png)

[Spike]

I expect you could also use a texture matrix to flip the cubemap as required.

taniwha, its more noticable with light projection cubemaps, but for skies you're not likely to notice.

[mh]

What I'm talking about is - if you take a set of standard skybox textures, with ft, bk, lf, rt, up, dn images, and try to convert them to a cubemap, you're going to need to selectively rotate/flip/mirror individual faces to get them right.

It's a restriction of the GL spec that cubemap face images must be square; see http://www.opengl.org/sdk/docs/man/xhtm ... VALID_ENUM is generated if target is one of the six cube map 2D image targets and the width and height parameters are not equal.[/quote]
An individual GL implementation may relax this restriction, but if you're relying on that behaviour then your code won't port to all GL implementations. Standard 6-face skyboxes don't have that restriction, so in order to cubemap a skybox you might need to do some texture resampling or you might need to do some other magic stuff (don't rely on modders to respect hardware limits or restrictions - they won't and eventually you're going to get a crasher or odd behaviour).

Other behaviour observed in released mods is skybox face textures of different sizes (e.g. the bottom face may be smaller) or missing face textures (e.g. the bottom face may be missing). Most skybox implementations also allow for each face image file to be a different format, and some even allow for each face image file to be in a different directory. In other words you can rely on nothing, and if it works with standard 6-face boxes then you better damn well make sure that it'll also work with a cubemap or sometime you're going to try load content that'll break your code.

[Baker]

What I'm talking about is - if you take a set of standard skybox textures, with ft, bk, lf, rt, up, dn images, and try to convert them to a cubemap, you're going to need to selectively rotate/flip/mirror individual faces to get them right.

Does the cubemap facilitiate the skydome (I'm guessing no). I've looked through QuakeForge and done some Google "homework" and as far as I can tell it is the "reverse" of a sphere map, so that doesn't seem like it should need to have a skydome to render on to.

[And for some reason, I mostly get stuff I'm not looking for when trying to investigate the cubemap angle in relation to rendering a sky ... then again, I'm also bogged down with mathematical problems I'm working through to improve my 3D math and understanding of, say, collision.]

INVALID ENUM ...

Not on topic, but this got on my nerves ...

Code: Select all

static fbool Renderer_Cmd_GetStates (rstate_t* getState)
{
	rstate_t temp;

	glGetBooleanv	(GL_ALPHA_TEST,			&temp.gl_alpha_test);				GL_CheckError ();
	glGetIntegerv	(GL_ALPHA_TEST_FUNC,	&temp.gl_alpha_test_func);			GL_CheckError ();
	glGetFloatv		(GL_ALPHA_TEST_REF,		&temp.gl_alpha_test_ref);			GL_CheckError ();
...
	glGetFloatv		(GL_TEXTURE_ENV_MODE, 	&temp.gl_texture_env_mode);		// This GL Errors for some reason	
	GL_CheckError ();  

glGetFloatv (GL_TEXTURE_ENV_MODE, &temp.gl_texture_env_mode); // This GL Errors for some reason

Every document I've read say this should not error. I wasted maybe an hour on that to no avail. Now I get the frustration some drivers can cause. This laptop has an ATI mobility or some such thing, yet reports as an Intel. Now, I'm tracking the gl states myself, so I don't actually need to do the glGetFloatv as I should already know.

[taniwha]

mh: my point is QF did no such flipping (other than respecting the appropriate bits in the original tga files at load time).

[mh]

mh: my point is QF did no such flipping (other than respecting the appropriate bits in the original tga files at load time).

Have you tried to load a regular skybox (such as the one that comes with Marcher)? You should definitely need to flip/etc the images - I've confirmed this across D3D and GL, using both Q1 and Q2. And Doom 3 also does this so it's not just me.....

Does the cubemap facilitiate the skydome (I'm guessing no). I've looked through QuakeForge and done some Google "homework" and as far as I can tell it is the "reverse" of a sphere map, so that doesn't seem like it should need to have a skydome to render on to.

You can draw a cubemap on the regular sky surfaces that come straight from the BSP. No need for dome or sphere geometry. With Q1 you'd keep depth testing and writing enabled as sky is meant to occlude other geometry; with Q2 you don't as sky isn't.

Also look at lat-long maps; they're interesting in that they're computationally more expensive to draw but save on texture memory usage.

Every document I've read say this should not error. I wasted maybe an hour on that to no avail. Now I get the frustration some drivers can cause. This laptop has an ATI mobility or some such thing, yet reports as an Intel. Now, I'm tracking the gl states myself, so I don't actually need to do the glGetFloatv as I should already know.

Sounds like the joy of AMD's switchable graphics. You should have an option in the BIOS to disable that.

[taniwha]

mh: I've just verified that Marcher's skybox seems to render correctly (note: I might have "north" wrong).

[mh]

I guess your shader code and your sky_coords compensates for the different orientations and cancels out what's otherwise wrong. What I do is just pass through the vertex position (from the original sky surface in the BSP) and reuse that as texcoords (which allows moving sky brushes to be properly textured, as well as allowing the same vertex shader for sky boxes as I use for the classic sky warp) so with that scheme it does need the flip/mirror/rotate setup.

[taniwha]

sky_coords is used only when extracting the cube faces from the blender environment map, though if you meant sky_suffix and sky_target, then yes, those two combined with the swizzle in the fragment shader do all the magic. However, it does make me wonder why certain faces aren't drawn mirrored. I do need to check that out properly (although I was careful when I wrote the code, this discussion has given me some doubts). At worst, I'll need to undo the negation in the sky_target array and introduce a negation in the skybox fragment shader.

Also, id skys and skyboxes use the same vertex shader. The differences between the sky vertex shader and the bsp vertex shader (walls and water) are just vertex color and surface and lightmap st extraction (wall/water) and direction vector setup (sky). While the sky vertex shader does transform the sky brush vertex, it's for shifting the origin to the camera and adding optional spin (try playing with the values where sky_velocity is set )