# UVW: better explanation, and how to implement with GLES texture2D()

UVW texture coordinates, as opposed to UV texture coordinates, do not get very adequate explanation on the web. Many people offer the simple exlanation, "UV is for 2-dimensional textures and UVW are for 3-dimensional textures." I don't buy this.

I have found a small handful of explanations that I find inadequate. This and this seem to be the best I've come across.

The first link talks about an analogy of shining a laser on a wall. At a perpendicular to the wall, the beam will project as a circle. As the angle increases, however, the beam projects increasingly as an elongated ellipse (it skews).

This sounds to me strikingly like the math involved in lighting equations in that the outcome is related to a vector pointing perpendicular to the surface. How can this relationship be adequately described with a single scalar, the W coordinate (assuming my basic understanding is appropriate)? Can you explain the relationship between the UVW coordinates and the current model-view matrix?

More importantly, I have some models that describe texture coords with a non-zero W coordinate (about 1/3 of the tex coords, or so, and most non-zero values are nowhere near zero.) I'm using OpenGL ES 2.0, where my shading language only provides calls to texture2D(). First off, how significant is the effect of the W coordinate for typical models (think something shaped like an airplane)? (I suspect this question is unfair since it should depend equally on the texture itself.) Is the call to texture3D() required for this, and if so, how can I achieve the desired effect with texture2D()?

What you've read is probably confusing because there are at least four different cases where you might see three-component texture coordinates.

1. Volume textures (i.e. 3D textures). They are like a stack of 2D textures with the third component selecting which image out of the stack you want. (And you can get filtering, mipmapping etc. in the third dimension just like the first two.)
2. Projective textures. In this case you have a UV and a W that works just like the W value of the float4 position you output from your vertex shader. That is, the U and V are divided by W before accessing the texture. This allows you to do things like project a texture onto a wall as if from a slide projector, or reproject a render target onto the scene (for shadow mapping and various postprocessing techniques). But the texture itself is still 2D.
3. Cubemaps. You sample them by providing a 3D vector from the center of the cube toward the desired point. It's uncommon to actually store cubemap vectors in a model since they're usually generated on the fly, e.g. by calculating a reflection vector from the surface normal and eye vector. However, it's conceivable that these are cubemap vectors.
4. Some totally unrelated piece of data, such as ambient occlusion. Since graphics hardware works in terms of four-component vectors, but texture coordinates usually only use the first two, game developers have gotten in the habit of stashing extra data in the remaining components, which may have nothing to do with textures at all.

Unfortunately, unlike with XYZW vectors, there's no standard naming convention for UVs beyond the first two components. So "UVW" may refer to any of the possibilities above. If you have a model with some mysterious-looking third component data on it, and no documentation from the person or tool that created the model, there's no easy way to know what to do with that data. If you have regular-looking 2D textures for your model, I'd try just ignoring the third component to begin with, and see if the model looks right just using the U and V components in a regular texture2D() call.

• Thanks for the response, I think you cleared up the confusion a lot. With projective textures, I assume the final texture coordinates are (x/w, y/w). Is the idea that this is only useful if you've performed some transformation on x and y, say with the texture matrix (in fixed-pipeline OpenGL)? Most of these W coordinates are 0, so I think that rules #2 out as (x/0, y/0) is probably not the intent. Leaving potentially #4... I'll see if the modeler has any idea what these are about. – notlesh Nov 9 '11 at 16:20
• @stephelton, yes, with projective textures you would usually calculate the texture coordinates by multiplying the world-space positions with a projection matrix. – Nathan Reed Nov 9 '11 at 17:38