RE: [Algorithms] Cubemap support

[Jon W. <hp...@mi...>]

> But surely you can see more than one of the cube reflection's faces on the
> surface of a reflective sphere, for example?

Actually, no, each fragment only fetches texels from one of the six cube
sides. That's why cube maps need extra-special careful attention to detail
in interpolation/borders/wrapping/clamping (like use GL_CLAMP_TO_EDGE). Of
course, each individual fragment can get a texel from a different side of
the cube. (In Direct3D, this means each output pixel comes from exactly one
side of the cube).

> Sure, like per-pixel lighting. I'd have thought that
> dual-peraboloid would be
> faster and more correct (less distortion) than cube-mapping for
> that kind of thing?

Why? If you pre-calculate your cube map to match the light distribution you
want, it's a fairly distortion free method. The drawback is that it uses
more texture memory than the other mapping functions supported in hardware.

> Do you have any references for the definitive rendering algorithm
> for cube-mapping?

http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_cube_map.txt

As the hardware is more or less the same, Direct3D cube mapping uses the
same underlying mechanism, although some details (handedness etc) are
different (as is the way you use the API to make it happen).

Cheers,

				/ h+