I started to study OpenGL and I learned how to show figures and stuff using Vertex and Fragment shader. I created a (very) stylized man, and now I want it to move his arm and legs. The question is: should I change vertex data in the VBO, directly in a timer function called in the main (as I did), or is it a job that should be done in the vertex shader, without touching vertex data?
I suppose the answer is the first one, but I feel like it overload CPU, instead of make the GPU work.
Both ways will work fine: if your aim it to utilise the GPU more then do the transformations in vertex shaders, otherwise you could use the CPU. Bear in mind however if checking for collisions you need data present at the CPU side....
In essence:
Doing the manipulation on the GPU means you only need to send the mesh data once, then you can send the matrix transformations to deform or animate it. This is ideal as it greatly reduces the bandwidth of data trasmission between CPU->GPU. It can also mean that you can upload just one copy of the mesh to the GPU and apply transforms for many different instances of the mesh to achieve varied but similar models (ie bear mesh sent to GPU make an instance at scale *2 scale *1 and scale *0.5 for Daddy bear, Mummy bear and Baby bear, and then send a Goldilocks mesh, now you have 2 meshes in memory to get 4 distinct models).
The transformed meshes however are not immediately available on the CPU side, so mesh-perfect Collision Detection will be more intensive.
Animating on the CPU means you have access to the transformed mesh, with the major caveat that you must upload that whole mesh to the GPU each frame and for each instance: more work, more data and more memory used up on both CPU and GPU sides.
Utilise bounding Boxes(axis aligned or non axis aligned as per your preference): this allows a small dataset to represent the model on the CPU side (8 points per box, as opposed to millions of points per mesh). If the bounding boxes collide, then transfer the mesh from GPU -> CPU and do the refined calculation to get an exact mesh to mesh collision detection. This gives the best of both worlds for the least overhead.
As the performance of the GPU could be tens, hundreds or even thousands of time higher than a CPU at processing meshes it quickly becomes evident why for performant coding as much as possible in this area is farmed out to the GPU.
Hope this helps:)