Shaders problems on Ubuntu Remix (eeepc)

[Yann_LE_PETITCORPS]

Hi,

I have a problem with vertex/fragment shaders on Ubuntu Remix on a EEEPC

My vertex and fragment shaders are really very basics :

vertex shader : void main(){ gl_Position = ftransform(); }

fragment shader : void main(){ gl_FragColor = vec4(1,1,0,1); }

And I draw only a shape as this (for the instant, this is only a triangle) :

glColor3f(0,1,0);
glBegin(GL_POLYGON);

   glColor3f(1,0,0);
   glVertex3f(0,1,0);

   glColor3f(0,1,0);
   glVertex3f(1,-1,0);

   glColor3f(0,0,1);
   glVertex3f(-1,-1,0);

glEnd();

When I attach only a vertex shader, I have a red color on the shape and a background in blue.

When I attach only a fragment shader, all the screen is of the color that I have fixed in this fragment shader.

When I attach a vertex shader and a fragment shader, all the screen is too of the color that I have fixed in the fragment shader.

And when I attach nothing, this is logically the default pipeline, so it’s OK
(cf. I have a triangle that have smooth transition between red, blue and green on a black background)

And I have too a full green screen if I set only the glColor3f(0,1,0) before the glBegin and without glColor3f into the glBegin/glEnd (with the 3 glColor3f into the glBegin/glEnd I have a red triangle with a blue background)

Where can be the problem : the fragment shader, the vertex shader or the method I use for display the triangle ???
(I don’t think this can be the last because this work very fine when I don’t use shaders)

My source is only 172 lines, perhaps can I put this into the next post if this is necessary ?

I think use the hardware acceleration because glxgears say about 1000 frames in 5.0s (and I don’t think that a eeepc can display at 200 fps with a software only pipeline)

Note that this very work fine (and fast if shaders aren’t recompiled at each iteration) if I set the vertex and fragment shaders just before to display the triangle and make a glUseProgram(0) just after => so in fact this problem can be easily resolved But I don’t understand where is really the problem

@+
Yannoo

[RigoN]

Try like this, it works for me
vertex

varying vec3 FrontColor;

void main()
{

	 FrontColor=gl_Color;
	 gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

}

fragment

varying vec3 FrontColor;

void main()
{
     gl_FragColor    = vec4(FrontColor, 1.0);
}

[Yann_LE_PETITCORPS]

A lot of thanks, this work very fine with this now

This is a specific bug on the EEEPC or this is the same thing on others plateforms ?
(I don’t remember to have see a similar problem on a PC or a Mac => I test this tomorow because it’s 03:42 in French and I begin my work at 10:00 …)

@+
Yannoo

[Alfonse_Reinheart]

This is a specific bug on the EEEPC or this is the same thing on others plateforms ?

I don’t understand what you mean.

In your shader code, you didn’t pass a per-vertex color to the fragment program. So naturally, it could only fill the triangle in with a single color. In the code given by Rigon, he does pass a per-vertex color to the fragment program. Therefore, it interpolates that color across the surface of the polygon.

Your shader code doesn’t do this because it doesn’t say to do it.

However, I was never quite clear on what your bug actually was. Was it that the triangle only had one color? Or was it something else?

[Yann_LE_PETITCORPS]

The problem is that I have a blue background with a red shape with my first version of shaders but with the RigoN version, it’s perfect.

I test this night the same source on a PC and a Mac, it’s certainly a bug on my source.

In alls cases, the RigoN version have totally resolved my problem and have give me a new idea for to pass anothers arguments from the vertex shader to the fragment shader

@+
Yannoo

[Yann_LE_PETITCORPS]

In first view, this is the fault of my code and I see in a lot of demos that they make an glUseProgram(n) just before to begin to display and a glUseProgram(0) at the end.

So I think that the standard way to go is to always make a glUseProgram(0) at the end of the use of a specific program shader.

Somewhere that isn’t a bad thing because this permit to use standards defaults shaders (that are certainly the more highly hardware accellerated that it is possible) in the majority of time (cf. when the use of specifics shaders is not necessary).

This seem logic that, such as a glBegin have always a glEnd pairing, a glUseProgram(n) have too a glUseProgram(0) counterpart.

So I use now a more visual/logic pairing using this

#define glBeginProgram(n)  glUseProgram(n)
#define glEndProgram()       glUseProgram(0)       

=> this resolve easily and elegantly my problem

Heu … and where can I find “simples but completes” tutorials that explain how to begin for create and use geometry shaders and instanciation on various plateforms ? (it’s because I want for example a special effect that permit that each texel of the video display can rotate independently in “3D on a plane”, all this on a eeepc of course ).

@+
Yannoo