Re: [Algorithms] Cubemap support

[Paul F. <pf...@at...>]

Jon Watte wrote:

> > > Is GeForce the only card to support cube maps? (In both GL and DX)
> >
> > What I'd like to know is how much slower a cube-mapped surface is
> > to render
> > than a single textured surface?
> >
> > Surely it would be six times slower since it has to render the
> > object six times?
>
> No, there's only one texture fetch, which chooses between one of six
> simultaneously bound textures.

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

> The difference between cube map texture
> coordinate generation and general 2D texture coordinate generation is that
> the cube map math is higher order than just the single texture matrix
> transform (and uses normal and possibly eye ray as inputs instead of u,v).
>
> Note that cube maps are used for many other things than just environment
> maps. If you do a true live environment map, then the entire SCENE has to be
> rendered six times PER OBJECT, plus a last time for actually displaying it;
> this can get a tad slow. But there are other, more interesting uses of cube
> maps.

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?

> I think most modern cards support cube mapping (if they say "EMBM" chances
> are good, and that started back in the Matrox G400 days :-). Whether they
> expose the ARB_texture_cube_map extension to OpenGL is up to the driver
> writers, but as it's an ARB, support is fairly widespread. (I suggest
> reading the spec for more details about how it's rendered).

Do you have any references for the definitive rendering algorithm for cube-mapping?
I can only find very vague stuff.

Actually, whilest I'm at it, do you know of any references for EMBM - I thought only

cards which could do dependent texture reads were capable of EMBM?

Cheers, Paul.