GLSL anyone?

MK27 · 12-29-2009, 09:16 AM

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.

psychopath · 12-29-2009, 11:02 AM

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?

MK27 · 12-29-2009, 11:37 AM

Quote:

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);
}

**Bubba** · 12-29-2009, 05:27 PM

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?

MK27 · 12-29-2009, 05:39 PM

Quote:

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.

dehebo · 01-09-2010, 04:21 PM

in modern games, and the like, transformations are calculated in shaders.
This is because shaders are run by the GPU which is specifically designed to compute 3D math and the like, so it excels at jobs like calculated new coordinates from a given transformation matrix.
In comparison to a GPU a CPU sucks at these jobs hence the move from fixed functionality to a programmable pipeline (shaders).

Short of it: you took the best path

12-29-2009, 09:16 AM	#1
MK27 dat is, vast staat Join Date: Jul 2008 Location: SE Queens Posts: 6,612	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. __________________ C programming resources: GNU C Function and Macro Index -- glibc reference manual The C Book -- nice online learner guide Current ISO draft standard CCAN -- new CPAN like open source library repository GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2 cpwiki -- our wiki on sourceforge
MK27 is offline

12-29-2009, 11:02 AM	#2
psychopath The Right Honourable Join Date: Mar 2004 Location: Where circles begin. Posts: 1,069	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? __________________ Memorial University of Newfoundland Computer Science www.daniel-cook.net Mac and OpenGL evangelist.
psychopath is offline

12-29-2009, 05:27 PM	#4
Bubba Super Moderator Join Date: Aug 2001 Posts: 8,322	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? __________________ I remember when The Weather Channel talked about weather, MTV played music videos, and the History Channel talked about history instead of conspiracy theories.
Bubba is offline

01-09-2010, 04:21 PM	#6
dehebo Registered User Join Date: Jan 2010 Posts: 1	in modern games, and the like, transformations are calculated in shaders. This is because shaders are run by the GPU which is specifically designed to compute 3D math and the like, so it excels at jobs like calculated new coordinates from a given transformation matrix. In comparison to a GPU a CPU sucks at these jobs hence the move from fixed functionality to a programmable pipeline (shaders). Short of it: you took the best path
dehebo is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
shaders: directx/opengl	Raven Arkadon	Game Programming	5	08-24-2006 09:19 AM
GLSL: polygon soup on nVidia cards.	psychopath	Game Programming	9	04-23-2006 07:08 AM
GLSL lighting (again)	psychopath	Game Programming	6	12-19-2005 01:34 PM
GLSL lighting. Bad normals? Bad shader? Something else entirely?	psychopath	Game Programming	6	11-12-2005 11:57 AM