GL_INTERPOLATE_EXT lighting problems

I’m trying to do a cross-fade from one texture to another using GL_ARB_multitexture. I can figure out how to do a cross-fade using GL_EXT_texture_env_combine and GL_INTERPOLATE_EXT, but I can’t figure out how to get the lighting applied to both textures correctly.

Just as each texture by itself would simply use GL_MODULATE to factor in the color of the incoming fragment (which is lit), I need to achieve the same look as I’m fading smoothly from one texture to the other.

So one solution would be to have the incoming fragment color applied to each texture, then interpolate between the two texture fragments. The other solution would be to interpolate between the two texture fragments, then apply the incoming fragment color. Unfortunately, I’m not sure either is possible with OpenGL.

Hopefully this is just something stupid I’ve overlooked. I’ve done a search and read a number of discussions about this (as in,,) but none that mention the lighting problem.


This poster asks exactly what you are asking:

And he was directed to this thread for relevant information which is almost exactly related to what you are asking:

Actually, my question is different. His question was about additive blending with lighting, which works just fine with something like NV_texture_env_combine4 (AB + CD). I’m asking about interpolating smoothly from one to the other, which adds extra factors to the equation. It’s more like tAB + (1-t)CD. Or, since the primary color is the same for both sides, it could also be written as C*(t*A + (1-t)*B).

Although I’m sure I can get it working with register combiners, I’d like to avoid that if possible. As I’m using a GeForce2 MX, I don’t have a third texture component to work with, either. It would be nice if there was a way to use something like the texture color to handle the t and 1-t, allowing us to use the texture combiners for other things.

WRT register combiners, there’s no need for a third texture component.
You can control the fading with the constant color’s alpha:
const * primary * tex0 + (1 - const) * primary * tex1.
This can be done in only one stage plus the final combiner.

Thanks. I’m sure I can get it to work using register combiners. I suppose I can bite the bullet and use them, falling back to two passes when register combiners aren’t supported. It doesn’t seem like I have any other options.

Unfortunately, I’m pushing a very large number of triangles (50K+), so two passes would be pretty bad. I’m using NVidia’s vertex array range extensions, so it already seems to crawl on non-NVidia cards. Does anyone else have any alternatives for non-NVidia cards?

While I’m on the subject of vertex array ranges, does anyone know of an equivalent on the Radeon cards? Although I’m not fond of Direct3D, I must admit that a standard hardware vertex buffer feature would be nice to have.