# How are the positions of skinned mesh vertices with multiple weighted parents stored?

I'm trying to wrap my head around the basics of skinning and skeletal animation. I understand not every skeletal animation implementation works exactly the same, but I'm just trying to understand the generally accepted practice.

I'm not sure if I used the correct terminology for my question, but my issue is this - if I have a vertex with a single bone as a parent, I can just store the local coordinates to the parent.

So if my parent bone is at any random location and the vertex is located exactly where the parent bone is, I would store it's x,y location as 0,0. If it were to move the vertex down the length of the bone parallel to it, regardless of the parent bone's angle and location, the local x value for the vertex would increase and the y would stay the same. This makes sense, and the math to get from any arbitrary point in world space to that local position to it's parent is also very straightforward. This position local to the parent also seems like the ideal way to store the vertex information for any given vertex with a single parent bone.

My question is if the vertex has multiple weighted parents, what xy location is stored? Would I need to store the relative coordinates to each parent for each vertex, or is there some way to store a single coordinate that represents it's weighted position relative to all parents? And if the math isn't simple enough to be explained here, what is the math required to get this multi-weighted relative coordinate called so I can go find more information?

A skeletal animation consists of three things, really: the bones, the skin, and the animation itself.

The bones form a "skeleton," a rig which is a crude representation of the overall thing being animated. A stick figure version, essentially. Every bone has a single parent except for the root bone, which is an orphan.

The animation drives the skeleton. An animation is essentially a collection of transformations to apply to each bone to move the stick figure in the desired fashion.

The skin is the actual vertices of the mesh in question. Every vertex is weighted to some collection of bones. The weight determines how much influence each bone's position has on the vertex position.

Each bone contributes to the vertex first in isolation. That is, the vertex is transformed into bone space, transformed per the bone's current transform (based on the current animation frame's impact on the skeleton), and back into mesh space. This yields, as you note, a position. For the sake of this discussion, call this an "intermediate position."

This is done for each contributing bone. The final resulting vertex is generally a simple linear combination of the intermediate positions based on the associated weight. That is, a vertex with weights (0.1, 0.2, 0.7, 0) against bones (1, 9, 2, 15) is 10% of bone 1's intermediate position, 20% of bone 2's, 70% bone 3's, and bone 15 has no influence since its weight is zero.

That final combined position is what is rendered.

The position of the vertex relative to the parent bone doesn't need to be stored. It's directly computable from the position of the vertex in bind (basically model) space and the bone in bind space. All you need is the vertex's bind space position, the four bone weights, the four bone indices, and the transformations for each bone (which the bone indices index into).

• The part of your answer that answers the question is the last paragraph if you'd like to edit for conciseness. But to clarify, the the bind space position is transformed to each parent bone, and then back into the model space after the weights are applied? Do you know if the bone-space position of the vertex for each weighted parent ever stored to trade off the computational cost of that extra transformation from bind space in exchange for the greater cost of storage in ram or vram? Jun 28, 2016 at 17:15
• I wouldn't ever consider storing that, personally, as the computational cost of that one extra aspect of the transform is trivial compared to extra cost in memory of storing it.
– user1430
Jun 28, 2016 at 17:33