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 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]

[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]

[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]

[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]

[Baker]

[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]

[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 )