A static model I just copy it's vertex position to a buffer, right? So when there's a bone animation I just update the vertex in my models and the copy it again to the buffer, for every frame?
I was using ThinMatrix [1] videos as guidelines when I was creating my engine. I'll take a look in how he implemented animations. Thank you.
The transformation matrices are interpolated for each rendered frame using the hierarchial animation data and the computed matrices are uploaded to the gpu in a buffer. The matrices are accessed in the vertex shader by indexing into the matrix buffer to calculate the vertex position.
How do you reconcile noise in motion capture data to bone transformations? For example, isn't it possible that the motion capture data slightly elongates or shortens the forearm in a way that makes it impossible to maintain the relationship with the upper arm bone?
In my head, it feels like you would have to pick the closest point on the sphere that's created if you rotate the forearm all around the elbow joint, but that seems expensive to do everywhere all the time.
That said - and I haven't done this myself, I'm just speculating - if you're using motion capture data directly maybe it makes sense to ditch the hierarchy altogether and have each bone be independent? Though, that could be problematic if you wanted to blend some "artificial" animations together with the recorded ones. I'm not sure what the standard practice is.
I only know the basics, but as far as I know that stuff is generally pretty straightforward (at least compared to actual rendering)
Basically you have an invisible vertex floating inside the mesh, and vertices on the visible mesh are "weighted" to it (with a floating point weight), so that when the bone moves, it "pulls" vertices towards it based on the weight strength. A mesh vertex can be weighted to multiple bone vertices at once. Bones typically consist of two vertices, where one is treated as an anchor and the other rotates around it. They're then arranged in a hierarchy, so that a parent bone's transform (translate/rotate/scale) applies to its children, and so on. So for example, rotating an upper arm bone causes the forearm bone to rotate with it.
An animation is then a series of keyframes on those bones (translate/rotate/scale to a particular x/y/z at time t). Those keyframes are interpolated when the animation is applied, and the mesh vertices are dragged along accordingly.
Motion-capture is just taking position data from a live actor and mapping it to those bone keyframes.
Things get slightly more complicated when it comes to blending between multiple animations (for example, running + swinging a sword; you basically average the keyframes). And then there's IK or Inverse Kinematics, which basically means that instead of driving an animation purely from explicit keyframes, you procedurally place the "end" of the limb (a character's foot goes all the way to the ground, for example) and then procedurally work backwards adjusting the bones up the hierarchy to satisfy that position. This is pretty common these days and leads to dramatically more natural-looking animation for characters and creatures (you can see it in action by walking on some stairs in a recent game). I don't know exactly how it's implemented.
But that's about it from a technical perspective. Of course the artistry of getting all of this just right is much harder - from the bone-weighting ("rigging") to the keyframes to the motion capture data cleanup - but the technical aspect isn't nearly as complicated as rendering (to my understanding).