# GLSL: can i use matrix transformation functions in vertex shader?

I have a working OpenGL code where i render a terrain with some trees.

I am doing all the matrix mathematics on the client side. Because of which the frame rate of my app is very low, around 25-30 [its not LOW but, i used to get 60 before the calculations]

If i were to do all these matrix transformations on server side, in say vertex shader, or even better a geometry shader, are there functions in GLSL which translate, rotate, ans scale?

for example, what would the following client side code look on server side?

        model   = tes_terr.glm_model; //get the current camera movement matrix
model   *=  glm::translate( glm::mat4(1.0f),  glm::vec3(tvec.x, tvec.y, tvec.z))
* glm::rotate   ( glm::mat4(1.0f), -90.0f, glm::vec3(1, 0, 0))
* glm::scale    ( glm::mat4(1.0f),  glm::vec3(scaleFactor));


Or do i have to write these function in vertex shader separately.

You should create the matrices on the cpu and pass them to the gpu so there's as little redundancy as possible( you don't want to create new transforms per vertex if all of your vertices for a mesh have the same transform. )

As for multiplying matrices on the gpu, you simply use the * operator with any two valid operands.

To answer your question; there is no function in glsl to create any matrices for you. You either need to create them yourself or upload them from the cpu. The common practice for this is to create you model, view and projection matrices on the cpu and upload them separately so that we have all the information needed for each coordinate space.

• that is what i am doing right now. Calculating all the matrices on the CPU, sending MVP and model matrix that you see in the code above to shaders via uniform variables. But i wanted to do all the calculations for the model on shader side, so the CPU is not overloaded.
– 2am
Apr 28, 2014 at 5:16
• @2am Well, the point of a scene graph is you can describe one object's position in terms of another. Constructing the entire model matrix on the gpu doesn't sound feasible. This is why we have a matrix stack in opengl. I think you should leave shaders to do shader stuff, like lighting calculations and shadows etc. Also, you really don't know if the cpu is being overloaded.
– Ben
Apr 28, 2014 at 5:23

The CPU is very unlikely to be overloaded by this.

Let's look at an example. Let's say you have a model with 5000 vertices. You want to draw it.

Setting up your matrix on the CPU involves:

• One translation.
• One rotation.
• One scale.

Doing it on the GPU involves:

• 5000 translations.
• 5000 rotations.
• 5000 scales.

While it's true that GPUs are faster than the CPU for this kind of calculation, doing it 5000 times rather than once is going to totally burn through your performance and on balance it will run even slower.

Reading this question, you have a performance problem but it seems as though you've decided where the problem must be without any proper profiling. Your performance problem is not where you think it is. You're doing something else that's causing it to be slow, and the challenge is to find out what that "something else" might be. Without seeing the rest of your code it's difficult to be more specific.

• nice one, I will let you know if i find out where its slowing down :)
– 2am
Apr 29, 2014 at 2:52
• Dont forget that the slowest part is the bus between GPU and CPU so minimizing the amount of data passed between them are vital for performance. Dec 20, 2018 at 13:05