glSecondaryColor3fvEXT but with VertexShader?

[B_old]

Hello.
(I asked a similiar question in the beginner section but did not get any reply, so I*ll try it here)
I am experimenting with the lighting Ron Frazier wrote http://www.ronfrazier.net/

All is working more or less nice but I would like to 'translate' it to VertexArrays.
Here is the part where I am stuck:

void CLightTexture: [img]http://www.opengl.org/discussion_boards/ubb/tongue.gif[/img]rocessAlphaDiffuseIntensityVertex(const cVector3& Vertex, cVector3 TSLight)
{
	cVector3 TexCoord = TSLight / (brightness * 2.0f) + 0.5f;
	cVector3 SecondaryColor = TSLight * 0.5f + 0.5f;
 
	glColor3fv((float*)&TexCoord);
	glSecondaryColor3fvEXT((float*)&SecondaryColor);
	glMultiTexCoord2fvARB(GL_TEXTURE0_ARB, (float*)&TexCoord);
	glVertex3fv((float*)&Vertex);
}

Setting the VA for the vertex and the texture is no problem for me.
But the two colors annoy me, as I don't want every vertex to hold 2 colors as I only use it once per frame (being different every time).
So I thought a vertex shader would be the answer. I have no experience with shaders but I thought the GL_VERTEX_PROGRAM_ARB would fit well here.
What do you think? My actual question is dedicated to the secondary color and how to express it in the vertex shader. Thanks for your time!

[This message has been edited by B_old (edited 02-18-2003).]

[Obli]

As far as I know, you can use a VERTEX PROGRAM to procedurally compute the secondary color, however, this may not be what you're searching for.

With vertex programs there are also "vertex attribute arrays" so, most of the time, if you have precomputed secondary color you can't really get the rid of it unless you compute them in the vertex program.

BTW, I don't really get where the problem is. If all the vertices got the same color at each frame, you could just do the setup once per frame using the standard FF pipe - VP are executed at each vertex so, you may be just wasting time...

Really, where's the problem? I cannot get it.

[B_old]

Hello.
The secondary color is different for EVERY vertex in EVERY frame and it is ONLY used ONCE per frame, thus I don't want to waste memory to store the color longer then needed.
(Same for the first color)
I thought a vertex shader would be the ideal thing, computing the two colors for every vertex and allowing me to use vertex arrays.

If anybody knows how to express those two colors in a vertex program please let me know, thanks!

[Obli]

If you are asking what is the vertex attribute name here we are:

COL0 - primary, front facing color
COL1 - secondary front facing color

Looks like you already know how to compute these.

[B_old]

Hmm interesting, thanks.
I guess I have to read more about the vertex program now.

[Obli]

Forgot to tell you that it was written in the extension spec. Always read the specs. I sometimes read them and come out discovering marvellous things ^_^


Bye

[This message has been edited by Obli (edited 02-20-2003).]

[B_old]

Hello.
Could you maybe have a look at my code?
Thanks.

glColorPointer(3, GL_FLOAT, sizeof(cSMPVertex), &(Vertices[0].TSLight));
//...
 glTrackMatrixNV( GL_VERTEX_PROGRAM_NV, 0, GL_MODELVIEW_PROJECTION_NV, GL_IDENTITY_NV );
 glBindProgramNV( GL_VERTEX_PROGRAM_NV, g_vertexProgramID );
//...
cVector3 Temp (1 / (Light->brightness * 2.0f), 1 / (Light->brightness * 2.0f), 1 / (Light->brightness * 2.0f));
glProgramParameter4fNV( GL_VERTEX_PROGRAM_NV, 3, 0.5f, 0.5f, 0.5f, 0.0f );
glProgramParameter4fNV( GL_VERTEX_PROGRAM_NV, 4, Temp.X, Temp.Y, Temp.Z, 0.0f );
glEnable( GL_VERTEX_PROGRAM_NV );
//...
//render with vertex arrays
 
//Here is the vertex program and what it is supposed to do:
!!VP1.1
 
DP4   o[HPOS].x, c[0], v[OPOS];   # Transform the x component of the per-vertex position into clip-space
DP4   o[HPOS].y, c[1], v[OPOS];   # Transform the y component of the per-vertex position into clip-space
DP4   o[HPOS].z, c[2], v[OPOS];   # Transform the z component of the per-vertex position into clip-space
DP4   o[HPOS].w, c[3], v[OPOS];   # Transform the w component of the per-vertex position into clip-space
 
MAD  o[COL0], v[COL0], c[4], c[3];  #cVector3 TexCoord = TSLight / (brightness * 2.0f) + 0.5f;
									#glColor3fv((float*)&TexCoord);
 
MAD  o[COL1], v[COL0], c[3], c[3];  #cVector3 SecondaryColor = TSLight * 0.5f + 0.5f;
									#glSecondaryColor3fvEXT((float*)&SecondaryColor);
 
MOV  o[TEX0], o[COL0];              #glMultiTexCoord2fvARB(GL_TEXTURE0_ARB, (float*)&TexCoord);
 
#	glVertex3fv((float*)&Vertex);
 
END

Thanks for any help!

[pbrown]

B_old,

NV_vertex_program doesn't allow you to read from two program parameters in the same instruction. So, the instruction

MAD o[COL0], v[COL0], c[4], c[3];

is illegal.

One alternative is to set c[3] to {2.0, 0.5, 0.0, 0.0} and issue

MAD o[COL0], v[COL0], c[3].x, c[3].y;

The query token GL_PROGRAM_ERROR_POSITION_NV gives you the position in the string where the error occured, so the following untested code prints out your program string with the error highlighted:

glGetIntegerv(GL_PROGRAM_ERROR_POSITION, &errorPos);
if (errorPos >= 0) {
   for (i = 0; i < errorPos; i++) {
     putchar(string[i]);
   }
   printf("***");
   for (; i < stringLength; i++) {
     putchar(string[i]);
   } 
}

ARB_vertex_program does not have any restriction on the use of program parameters. On NVIDIA platforms, reading multiple parameters in an instruction may require an extra instruction/temporary.

Also note we added an error string query in NV_fragment_program that was carried over to ARB_vertex_program and ARB_fragment_program. This query gives you a description of why your program failed to load, and may contain warning messages as well. Error string support has not been enabled for !!VP1.0 programs.

[B_old]

Hello.
Thanks for the reply.
It seems though as something else is totaly wrong with my vertex program.

DP4   o[HPOS].x, c[0], v[OPOS];   
DP4   o[HPOS].y, c[1], v[OPOS];  
DP4   o[HPOS].z, c[2], v[OPOS];   
DP4   o[HPOS].w, c[3], v[OPOS];   
 
MOV o[COL0], v[3];
MOV o[COL1], v[4];
MOV o[TEX0], v[8];

Should this not give correct results (without changing anything) when I use the code I posted in my first post?
It produces strange effects that somehow remind of the correct results but I cannot see why it should change anything at all.

Thanks for the help.

[M/\dm/\n]

Quickly ran through this topic and there is somthing I don't understand. Why you need to call different extensions (SecColEXT), if cards that support vp MUZZT have them as 2+2=4 (in whole numbers ) and why you need sec color array if specular lighting is usualy calculated on GPU (vp). You can simply pass N,L,E & output everything to COL1, thats all! No ext, no unneeded arrays!