New RC question

Hi,
I have a problem here. My code is this

glCombinerInputNV(GL_COMBINER1_NV, GL_RGB, GL_VARIABLE_A_NV, GL_TEXTURE0_ARB, GL_UNSIGNED_IDENTITY_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER1_NV, GL_RGB, GL_VARIABLE_B_NV, GL_ZERO, GL_EXPAND_NEGATE_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER1_NV, GL_RGB, GL_VARIABLE_C_NV, GL_CONSTANT_COLOR0_NV, GL_SIGNED_NEGATE_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER1_NV, GL_RGB, GL_VARIABLE_D_NV, GL_ZERO, GL_EXPAND_NEGATE_NV, GL_RGB);

glCombinerOutputNV(GL_COMBINER1_NV, GL_RGB, GL_DISCARD_NV, GL_DISCARD_NV, GL_SPARE0_NV, 
				   GL_NONE, GL_NONE, GL_FALSE, GL_FALSE, GL_FALSE);

And I think is does this: tex0 * 1 + ((-const) * 1)
<=>
A - const

but the value in spare0 always become 0.
I think the answers are often negative. Is it clampled to [0, 1]? I read somewhere that the answer was clamped to [-1, 1]. Anyone know whats wrong?

-Ninja

Use GL_UNSIGNED_INVERT_NV instead of GL_EXPAND_NEGATE_NV. The rest looks fine.

Ok, but it does not help.
Spare0 must be clamped to 0, because if I set spare0 to -1 or 0 there is no differance, but if I set it to 1, there’s a big differance in my program.
Here is the rest of the code:

glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_A_NV, GL_SPARE0_NV, GL_SIGNED_IDENTITY_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_B_NV, GL_PRIMARY_COLOR_NV, GL_SIGNED_IDENTITY_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_C_NV, GL_SPARE1_NV, GL_SIGNED_IDENTITY_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_D_NV, GL_SECONDARY_COLOR_NV, GL_SIGNED_IDENTITY_NV, GL_RGB);

glCombinerOutputNV(GL_COMBINER2_NV, GL_RGB, GL_SPARE0_NV, GL_SPARE1_NV, GL_DISCARD_NV, 
				   GL_NONE, GL_NONE, GL_TRUE, GL_TRUE, GL_FALSE);

glFinalCombinerInputNV(GL_VARIABLE_A_NV, GL_TEXTURE2_ARB,    GL_UNSIGNED_IDENTITY_NV, GL_RGB);
glFinalCombinerInputNV(GL_VARIABLE_B_NV, GL_SPARE0_NV,       GL_UNSIGNED_IDENTITY_NV, GL_RGB);

glFinalCombinerInputNV(GL_VARIABLE_C_NV, GL_ZERO,			GL_UNSIGNED_IDENTITY_NV, GL_RGB);
glFinalCombinerInputNV(GL_VARIABLE_E_NV, GL_TEXTURE2_ARB,	GL_UNSIGNED_IDENTITY_NV, GL_RGB);
glFinalCombinerInputNV(GL_VARIABLE_F_NV, GL_SPARE1_NV,		GL_UNSIGNED_IDENTITY_NV, GL_RGB);
glFinalCombinerInputNV(GL_VARIABLE_D_NV, GL_E_TIMES_F_NV,	GL_UNSIGNED_IDENTITY_NV, GL_RGB);

Do u see where it goes wrong?

-Ninja

I’ll have a look, one question though: where’s your combiner 0 (GL_COMBINER0_NV)?

Here:

glCombinerParameteriNV(GL_NUM_GENERAL_COMBINERS_NV, 3);
glCombinerParameterfvNV(GL_CONSTANT_COLOR0_NV, bias0);
glCombinerParameterfvNV(GL_CONSTANT_COLOR1_NV, bias1);

glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_A_NV, GL_TEXTURE1_ARB,       GL_UNSIGNED_IDENTITY_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_B_NV, GL_ZERO,				GL_UNSIGNED_INVERT_NV , GL_RGB);
glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_C_NV, GL_CONSTANT_COLOR1_NV,	GL_SIGNED_NEGATE_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_D_NV, GL_ZERO,				GL_UNSIGNED_INVERT_NV , GL_RGB);

glCombinerOutputNV(GL_COMBINER0_NV, GL_RGB, GL_DISCARD_NV, GL_DISCARD_NV, GL_SPARE1_NV, 
				   GL_NONE, GL_NONE, GL_FALSE, GL_FALSE, GL_FALSE);

This is what the above should compute,

Result = tex2*( color0 . ( tex0 - bias0 ) ) + tex2*( color1 . (tex1 - bias1 ) )

Is that what you expected ?

You may need to use GL_EXPAND_NORMAL_NV on color0, color1 and on the results of spare0 and spare1 ( from combiners 0 and 1 ). It depends on what you want to achieve.

Try this on combiner 2 and see if it does what you want,

glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_A_NV, GL_SPARE0_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_B_NV, GL_PRIMARY_COLOR_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_C_NV, GL_SPARE1_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_D_NV, GL_SECONDARY_COLOR_NV, GL_EXPAND_NORMAL_NV, GL_RGB);

Or expand in combiners 0 and 1 if you are operating on vectors.

Yes, this is right:
Result = tex2*( color0 . ( tex0 - bias0 ) ) + tex2*( color1 . (tex1 - bias1 ) )

But

glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_A_NV, GL_SPARE0_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_B_NV, GL_PRIMARY_COLOR_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_C_NV, GL_SPARE1_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER2_NV, GL_RGB, GL_VARIABLE_D_NV, GL_SECONDARY_COLOR_NV, GL_EXPAND_NORMAL_NV, GL_RGB);

does not help :stuck_out_tongue:

When entering the final combiner stage, all values are clamped to [0,1].
That’s not the output of general combiner stages that are clamped, that’s the input of final combiner stage.
Outputs of general combiner stages are “just” clamped to [-1,+1]

Are tex0, tex1, color0 and color1 meant to be interpreted as vectors ? And what is bias0 and bias1 ?

If tex0, tex1, color0 and color1 contain vectors ( compressed to [0,1] ) then these need to be expanded. If bias0 and bias1 are vectors that are meant to offset the vectors from tex0 and tex1, then these need to be expanded too ( signed_identity should be expand_normal ).

Vincoof, as you know I whant to compute this
Result = tex2*( color0 . ( tex0 - bias0 ) ) + tex2*( color1 . (tex1 - bias1 ) )

and the last calculation is done in the final register as you helped me to do.
But for example color0 . ( tex0 - bias0 ) could be less then 0 sometimes. Is there a way around the problem that that value is clampled to [0, 1] ?

-Ninja

Then you need to request another general combiner stage.

And in the general combiner stage 3 (which is not the final combiner stage) :

  • assign texture2 to variables A and C,
  • assign spare0 to variable B,
  • assign spare1 to variable D,
  • output AB+CD into spare0.

And in the final combiner stage, simply forward spare0 :

  • assign zero to variables A, B and C,
  • assign spare0 to variable D.

I consider this is wasting one general combiner stage, but since nVidia’s implementation clamps (excessively?) to [0,1] in the final combiner stage, you can’t perform signed operations in this stage.

[This message has been edited by vincoof (edited 07-31-2002).]

Do you expect tex0 and tex1 to be mapped in [-1,+1] or [0,1] ?
In your general combiner stages 0 and 1, you seem to use tex0 and tex1 as unsigned values. If you want to map to [0,1] then you’re doing the right thing. Otherwise PH is right when he writes than you can map the textures to [-1,+1] thanks to EXPAND_NORMAL.

Also, I’ve read your equation again in the first topic and I’m wonderig what you feed into primary and secondary colors.
Because if you feed (col.rcol.r, col.gcol.g, col.r*col.g) into primary and (col.r, col.g, 1) into secondary, it will work with flat shading (ie glShadeModel(GL_FLAT)) but you may not interpolate with Gouraud shading (ie glShadeModel(GL_SMOOTH)).
If you want to interpolate col.r and col.g, you have to implement the “other” method.

Ok, it works now!
Thanks for your help vincoof and PH

-Ninja