quote:
==> For the 1st example. Am I right ? :

(SRC_COLOR * GL_ONE) + (DST_COLOR * GL_ZERO)
==> Output = (SRC_COLOR * (1,1,1,1)) + (DST_COLOR * (0,0,0,0))
= (SRC_COLOR) + (0,0,0,0)
= (SRC_COLOR) ==> The destination color has been replaced by the source color ?

quote:
==> For the 2nd example is :

(SRC_COLOR * GL_ZERO) + (DST_COLOR * GL_ONE)
==> Output = (SRC_COLOR * (0,0,0,0)) + (DST_COLOR * (1,1,1,1))
= (0,0,0,0) + (DST_COLOR)
= (DST_COLOR) ==> The destination color has not changed, nothing has changed in the destination color

Yup that's exactly that.

quote:
==> For this :

(SRC_COLOR * GL_DST_COLOR) + (DST_COLOR * GL_ZERO)
==> Output = (SRC_COLOR * GL_DST_COLOR) + (DST_COLOR * (0,0,0,0))
= (SRC_COLOR * GL_DST_COLOR) + (0,0,0,0)
= SRC_COLOR * GL_DST_COLOR
=> What's the result ? It depends from the source color ?

It depends on both the source color and destination color. The '*' operation is simply the component-by-component multiplication, also known as modulation in OpenGL.
The source color is modulated by the destination color, which means that if any of the source or destination color is black, then the result is black ; if both the source and destination colors are white, then the result is white ; and for example if the source color is yellow (1,1,0,1) and the destination color magenta (1,0,1,1) then the result is red because (1,1,0,1)*(1,0,1,1)=(1,0,0,1).

I'm not laughing at you at all. As I stated above, I myself couldn't bare the specification in the first sight, with regard to the blending paragraph. But then it's just a matter of logic. Like most things in OpenGL, once you've been able to see what the designers wanted, it all comes incredibly clear.

[edited by - vincoof on October 7, 2003 11:24:41 PM]

The vertex program looks fine. At least it is syntaxically correct otherwise you wouldn't even see your triangles rendered (usually rendering is skipped when an invalid vertex program is bound).

There are only two things you could improve :
1- if you render your models in multipass (which seems to be the case here) and if at least one of the passes does not use vertex programs, then it's better to use the ARB_position_invariant option which guarantees that rasterized fragments will be done exactly at the same position. It's especially important for Z-buffer issues that are typically needed for multipass rendering.
2- if in your code you use a non-identity texture matrix, you should multiply the texture coordinate by this matrix instead of copying the input texcoord to the output texcoord directly.

But these are just improvements. I'm not sure it's vital actually.

[edited by - vincoof on October 7, 2003 10:38:50 PM]

Yup Mirko, you got it.
The problem is due to the fact that the first pass uses two texture units, but the vertex program here does only transfer texture coordinate 0. Without vertex programs, there would have been no problem as Mirko pointed out
So, simply add those lines in the vertex program (I think you will guess where to insert them) :
ATTRIB iTex1 = vertex.texcoord[1];\
OUTPUT oTex1 = result.texcoord[1];\
MOV oTex1, iTex1;\

Cheers