Thread: GLSL anyone?

I'm starting to learn GLSL, which has some very clever math features, but since I am not so clever with math, it's a little difficult.

You will have to understand GLSL in order to answer this, I'm hoping someone does.

I have a vertex shader which rotates an object; it passes on a float value, "Diffuse", to the fragment shader which is multiplied with the color value to produce lighting.

Code:

void rotateY (inout vec4 vert, float rads);

uniform float YRot;
varying float Diffuse;

void main() {
	vec3 vnormal = normalize(gl_NormalMatrix * gl_Normal);
	Diffuse = max(dot(vnormal, gl_LightSource[0].position.xyz), 0.0);
	rotateY (gl_Vertex, YRot);
	gl_Position = ftransform();
}


void rotateY (inout vec4 vert, float rads) {
	vec4 old = vert;
	mat2 rotY = mat2(cos(rads), -sin(rads), sin(rads), cos(rads));
	vert.xz = old.xz * rotY;
}

The problem is, the light on the object so rotated moves with the object.

The light is being calculated prior to rotating, but is never calculated with the rotated vertices, so naturally the light would rotate "with" the object. I'm not completely sure if there's a good way to do this entirely inside GLSL (although I am a bit rusty) - is there any reason in particular why you want to rotate the object in the vertex shader?

Originally Posted by psychopath

1) Recalculate the vertices using a C version of the GLSL rotate function above, and then modify the buffer data in video memory. Major and maybe insurmountable drawback: you then have to recalculate all the normals, and modify those in the buffer too. Advantage: it could be done once, rather than every frame. However, this would mean using the CPU to perform the calculations.

If I can just rotate the normal using the same algorithm, then it won't be so hard, but this did not work in the shader, so I haven't tried it outside of that yet.

Like, OMG, it worked. Whew! I needed some encouragement here.

So now I can do rotation and transformation on the video buffer data without having to call any standard functions, before the shaders are executed.

Code:

void rotate (glThing *obj, float rads, int a, int b) {
	int i;
	float x, z, cs = cos(rads), sn = sin(rads);
	for (i=0; i<obj->len; i+=3) {
		x = obj->data[i+a];
		z = obj->data[i+b];
		obj->data[i+a] = x*cs - z*sn;
		obj->data[i+b] = x*sn + z*cs;
	}
	glBindBuffer(GL_ARRAY_BUFFER, obj->VBO);
	glBufferSubData(GL_ARRAY_BUFFER,0,obj->len*sizeof(GLfloat),obj->data);
	glBindBuffer(GL_ARRAY_BUFFER, 0);
}

Originally Posted by Bubba

I fail to see how this benefits you. All the vertex shader is supposed to do is transform the vertices. In more advanced shaders it might perform some vertex texturing but all in all it is a simple transformation process. Why are you rotating objects inside of a vertex shader?

Well, that's good to hear. I don't really see the point either, which is why I'm happier with my second idea.

I was just slightly confused by the fact that GL 3.2 removes all the "fixed functionality" stuff, inc all functions that provide any kind of rotation or translation of objects -- glRotate(), glTranslate, et al. They also remove the pushing and popping of state matrixes, so the only way to duplicate those functions exactly (which operate per frame on static object data, ie, the data remains the same, you keep track of rotation relative to world) is in the vertex shader.