whereby t_i stands for independend textures t_0, t_1, t_2 and c_pi stands for primary per-vertex colors c_p0, c_p1, c_p2.
Notice, that the addition must done after the computation of the three terms!
The problem is, I have to modulate each texture separately with a self computed per-vertex color and must add finally all 3 terms together! But in the pixel shader I have only the possibility to input one secondary color! In case of three pass rendering, there is no problem. Just a modulate the first primary color with the first texture and blend it with the second primary color modulated with the second texture …
Can anybody help me to realise this function in hardware OpenGL in only one pass?
I think you are looking for register combiners rather than texture shaders.
For NVIDIA hardware, there is an extension to the original GL_NV_register_combiners, cleverly called GL_NV_register_combiners2 , that enables you to use more color constants. Actually, you still have two unique color registers but they can be different for each combiner stage.
Well, have a look in NVIDIA’s doc to see if that suits your needs !
Regards.
Eric
P.S.: this extension is emulated on NV1X and HW-accelerated on NV2X.
I’m not sure but with the GL_NV_register_combiners2 extension and a GF3/GF4 it should be possible
Look at nvidias SDK and their nvparse for using register combiners more easy
Bye
ScottManDeath
PS: sh*** Eric took pole position
[This message has been edited by ScottManDeath (edited 02-15-2002).]
Im not very familiar with the GL_NV_register_combiners2 extension (or pixel shaders for that matter), but doesnt only allow you to define 2 CONSTANT colors per combiner? It seems like jam needs 3 per-vertex colors.
That said, is there any way you can combine these? You have a primary and secondary per vertex color you can work with. Is there any possibility of a relationship between these, such as c1=1-c2 or c1+c2+c3=1, and maybe then you could calculate the third one from the first 2?
Here is another option for you. Since you have 4 texture units available but are only using 3, maybe you could put a RGB volumetric texture into the 4th texture unit and feed in your 3rd color as 3D texture coords for this texture? Not the most elegant, but it should work.
[This message has been edited by LordKronos (edited 02-15-2002).]
dont use a 3d-texture for it but instead try it with pass_through in the texture_shader instead… just clamp the 4th texcoors between [0,1] before passing them trhough the pass_through
Originally posted by LordKronos: … but doesnt only allow you to define 2 CONSTANT colors per combiner?
Hi
this shouln’t be a really problem because you can setup the constant colors by glCombinerInputNV(…) There you can specifiy a stage ( 0 to 7) and set this stages constant color 0 to the color. if you use 3 stages yout have to set before each vertex is specified the corresponding constants and let they modulate the texture.
Then sum they all up and you 'll get it.
(maybe this won’t work if you use vertex arrays, perhaps performance is bad )
You are right, davepermen!
I can’t use the constant color registers, because they define only one unchangeable color for the whole primitive! But I need per-vertex colors which are automatically interpolated among the vertices.
The “pass_through” idea seems to be very interesting and could be successfully. Also the 3D-texture variant could be a fall back.
Thanx a lot for your ideas!
Jam
P.S.: Maybe, the next pixel shader generation should has any capabilities to address more than two per-vertex colors directly!
i would prefer pervertex vectors, wich not get clamped pervertex like the 2 colors, but perpixel. like passthrough. as far as i know ps2.0 will have them (dx9)… gpu that support it will support it on gl, too, i guess
, that enables you to use more color constants. Actually, you still have two unique color registers but they can be different for each combiner stage.