GLSL anyone?

This is a discussion on GLSL anyone? within the Game Programming forums, part of the General Programming Boards category; I'm starting to learn GLSL, which has some very clever math features, but since I am not so clever with ...

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?

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.

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 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.

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).