What is a cube map

Quote:

Is it correct that a 'cube map' is just a '3d' OpenGL texture?

No. A 3D texture is another thing entirely, although they're both accessed with 3D texture coords.

A cube map is essentially 6 textures which form a cube. Texture lookups work by finding the colour on the cube where the texture coordinate vector intercepts it. They're commonly used for environment maps as well as for normalisation lookups for vectors in fragment shaders (google for "normalisation cube map").

3D textures OTOH (sometimes known as volume textures), are textures which contain a 3 dimensional array of texels. This can get pretty expensive for medium resolution images (say 256x256x256) as you might imagine, and they're not often used in games.

Since benjamin bunny told everything essential, I can only point you to this.

Ok that makes sense to me and I appreciate the link. Thanks for not flaming me with my newbie question :) (rank ++)

EDIT:
Yeah, a 3D texture seems a bit excessive because the texture lookup would probably take longer if it needs to be calculated and the memory footprint is huge. I don't see how a 3D texture is really applicable to rasterizing primitives which are projected onto a 2D screen (unless the third texture coordinate is used for something other than color).

As I said, thanks again.

Hi,

3D Textures can be used as lightmaps. They can give quite good result. Almost similar thing can be done by using 2d + 1d attenuation maps. They have their uses in lighting. Game Programming Gem 2 has an example of using 3d lightmaps. I think ATI have that demo on their site as well.

Quote:

Original post by BobMcGee Yeah, a 3D texture seems a bit excessive because the texture lookup would probably take longer if it needs to be calculated and the memory footprint is huge. I don't see how a 3D texture is really applicable to rasterizing primitives which are projected onto a 2D screen (unless the third texture coordinate is used for something other than color).

A prime example of where 3d textures are used is in the medical field. CAT scans, MRI's, etc... all that stuff. The head, the body, it's all 3-d. They can essentially create one 3-d texture representing the entire head (blood vessels, skull, brain, tumors). Then, depending on where the doctor wants to look, the software will simply create a plane and cull everything in front of it, revealing the top layer of the 3d texture behind it.

As ben said, 3d textures can get extremely expensive, and aren't traditionally used in the gaming field. In the medical field (and others I'm sure), though, they are very common. I've heard of 4d textures, but I'd prefer not to blow up my brain with this notion. ;P

Could someone show an axample or paste a link of creating and using normalization cubemap? I've tied to google, but didn't find anything.

IMO using cubemaps for normalization aint really worth it, visually the results are worse, thus the only reason is speed, and from what ive heard on ati hardware theyre even slower so its only on nvidia hardware that u get the benifit from them and from what ive seen this is only about 10%, ie piss all, not to mention u consumes more resources

Quote:

Original post by Atm97fin Could someone show an axample or paste a link of creating and using normalization cubemap? I've tied to google, but didn't find anything.

For each texel in the cubemap, just calculate the normalised vector. Before you store it, you need to scale and bias the value to fit in the range 0..1 (add [1,1,1]^T and multiply by 0.5). To use it, just do a texture lookup in the fragment shader as with an ordinary texture, using your vector to be normalised as the tex coords; obviously you need to reverse the scale and bias for the returned colour to get the normalised vector.

As zedzeek says, some hardware will benefit from this more than others. There shouldn't be any visible artifacts if you do it properly. Just make sure you use a high enough resolution (128x128 should be sufficient) and you use GL_NEAREST filtering (otherwise the interpolated vectors won't necessarily be unit-length).