---
title: 'Velocity Skinning: Real-Time Deformation'
url: https://www.emergentmind.com/topics/velocity-skinning
type: topic
---

# Velocity Skinning: Real-Time Deformation

Velocity Skinning (VS) is a real-time, artist-tunable extension to standard Linear Blend Skinning (LBS) and Dual-Quaternion Skinning (DQS) that enables automatic synthesis of stylized secondary motion on skinned characters by introducing velocity-driven per-vertex deformations. Unlike conventional methods that rely solely on instantaneous joint poses, VS leverages skeletal velocity information—both linear and angular—to generate effects such as squash-and-stretch, drag, and follow-through, integrating seamlessly into standard GPU or CPU skinning pipelines without physical simulation, temporal integration, or additional rig complexity [2104.04934].

## 1. Overview and Motivation

Traditional skinning techniques, notably LBS, compute the skinned mesh vertex positions by blending bone transformations, operating only on current joint poses:
$$
v_{\text{LBS}} = \sum_{i} w_{i} T_{i} v_0
$$
where $v_0$ is the rest pose vertex position, $T_i$ is bone-$i$’s rigid transformation in $SE(3)$, and $w_i$ are normalized skinning weights. While LBS and DQS provide efficient deformation, they do not encode skeletal velocities, precluding automated generation of physically suggestive secondary behaviors. Professional workflows often require hand-authoring deformers for follow-through or squash effects—a laborious process.

Velocity Skinning addresses this by analyzing the velocity of each bone—both translational and rotational—propagating this information throughout the skeletal hierarchy, and synthesizing per-vertex displacements accordingly. These deformations are artist-controllable via per-vertex “squashiness” and “floppiness” weights and operate in real-time as a single mesh pass, making them accessible and efficient for production environments [2104.04934].

## 2. Mathematical Formulation

VS formulates per-vertex velocity as a sum of bone-induced components via up-propagated weights. Letting $v(t)$ be the LBS position trajectory,
$$
\dot{v} = \frac{d}{dt}\left(\sum_{i} w_i v_i\right) = \sum_{i} w_i \left(\sum_{j \in A(i)} V_j\right)
$$
where $A(i)$ is the ancestor set for bone $i$, and $V_j \in \mathbb{R}^3$ is bone $j$’s velocity contribution.

Rearranging, the velocity can be written as a single sum:
$$
\dot{v} = \sum_j W_j V_j
$$
$W_j(v_0) = \sum_{i \in D(j)} w_i(v_0)$ are up-propagated weights, where $D(j)$ is all descendants of bone $j$ (including itself).

Bone velocity decomposes into:
- Translation: $V_j^T$ (linear velocity of bone $j$’s origin $p_j$)
- Rotation: $V_j^R = \Omega_j \times (x_{\text{LBS}} - p_j)$, with $\Omega_j$ the angular velocity

Rather than displacing along $\dot{v}$ directly, VS blends stylized, per-bone, per-vertex displacements $D_j(V_j^T, V_j^R)$ with weights $W_j$:
$$
\delta v = \sum_j W_j D_j( V_j^T, V_j^R )
$$
with the final output:
$$
v_{\text{VS}} = v_{\text{LBS}} + \delta v
$$

Practically, VS separates two effect classes: “squashy” and “floppy.” The total displacement is
$$
\delta v = \sum_j W_j \left[ D_{\text{squash}}( V_j^T, V_j^R ) + D_{\text{floppy}}( V_j^T, V_j^R ) \right]
$$

### Squashiness Deformer

- Intuition: volume-preserving scaling—elongation in motion direction, compression perpendicular.
- Translation: For bone $j$, centroid $c_j$, local x-axis aligned to $V_j^T / \|V_j^T\|$, use $S = \operatorname{diag}[1+s, (1+s)^{-1/2}, (1+s)^{-1/2}]$ with $s = \alpha_T \|V_j^T\|$ and “squashiness” gain $\alpha_T$.
  $$
  D_{\text{squash}}^T = (RSR^T - I)(x_{\text{LBS}} - c_j)
  $$
- Rotation: similar, with scaling directed along a medial axis $m_j$, and $s = \alpha_R \|V_j^R\|$.

### Floppiness Deformer

- Intuition: delayed motion—vertices appear to lag the skeleton.
- Translation: $D_{\text{floppy}}^T = -\beta_T V_j^T$ (floppiness gain $\beta_T \geq 0$)
- Rotation: For projection $r = \operatorname{Proj}_{\Omega_j}( x_{\text{LBS}} - p_j )$, rotate about axis $\Omega_j$ by angle $\theta = -\beta_R \|\Omega_j \times (x_{\text{LBS}} - p_j)\|$, with $D_{\text{floppy}}^R = (R_{(\theta)} - I)(-r)$.

Parameters $\alpha_T(u), \alpha_R(u), \beta_T(u), \beta_R(u)$ are stored per-vertex and can be painted interactively.

## 3. Algorithmic Pipeline

VS operates in three passes: per-model, per-animation, and per-frame.

- **Per-model**: Compute LBS weights $w_i(u)$ per vertex, up-propagated weights $W_j(u)$, centroids $c_j$, medial axes $m_j$, and initial per-vertex weights $\alpha, \beta$ (uniform or painted).
- **Per-animation**: For each keyframe, compute bone velocities $\Omega_j, \dot{p}_j$.
- **Per-frame**: For each vertex $u$,
  1. Compute $v_{\text{LBS}}(u)$.
  2. For each $j$ with non-zero $W_j(u)$:
      - Gather $V_j^T = \dot{p}_j$, $V_j^R = \Omega_j \times (v_{\text{LBS}} - p_j)$.
      - Compute $D_{\text{squash}}, D_{\text{floppy}}$.
      - Accumulate $\delta v(u) += W_j(u)[D_{\text{squash}} + D_{\text{floppy}}]$.
  3. Output $v_{\text{VS}}(u) = v_{\text{LBS}}(u) + \delta v(u)$.

All computations are strictly per-frame, relying only on current skeleton state; no temporal integration or physical simulation.

### Example Pseudocode

```python
for each frame:
    compute all bone velocities (Ω_j, ṗ_j)
    for each vertex u:
        v_LBS = sum_i w_i * T_i * v0
        δv = 0
        for each bone j where W_j(u) > 0:
            V_T = ṗ_j
            V_R = Ω_j × (v_LBS - p_j)
            Dsq = Squash(V_T, V_R, c_j, m_j, α_T(u), α_R(u))
            Dfl = Floppy(V_T, V_R, p_j, Ω_j, β_T(u), β_R(u))
            δv += W_j(u) * (Dsq + Dfl)
        v_out = v_LBS + δv
        emit v_out
```
[2104.04934]

## 4. Artist Control and Customization

VS provides extensive artist-driven control:

- **Per-vertex painting:** Weights $\alpha_T, \alpha_R$ (squashiness) and $\beta_T, \beta_R$ (floppiness) may be interactively painted using standard 3D viewport tools. Typical ranges are $\alpha$ in $[0, 0.5]$, $\beta$ in $[0, 1.0]$.
- **Per-bone toggles:** Exclude individual bones or disable translation/rotation components.
- **Axis and centroid offsets:** Centroid $c_j$ can be interactively shifted within local bone-space.
- **Floppy angle clamping:** Floppiness-induced bending angle $\theta$ may be clamped (e.g., $30^\circ$–$60^\circ$) to prevent overbending.
- **Static visualizer:** In pose editors, assign synthetic velocities to preview trajectories caused by VS displacements.

These controls enable precise, localized stylization and adaptation to multiple character rigs and animation styles.

## 5. Performance Profile

VS is designed for real-time applications:

- **CPU Implementation:** Single-pass over all vertices per frame; interactive speeds on meshes up to $50$k–$100$k vertices.
- **GPU Implementation:** All per-model data (weights, centroids, axes, artist weights) and per-frame bone velocities are provided to a vertex shader.
- **Empirical Timings:** On an NVIDIA Quadro P3200 laptop:

| Scene                      | Verts     | Bones Animated | LBS Frame | VS Frame |
|----------------------------|-----------|---------------|-----------|----------|
| Flying Cthulhu             | 150,000   | 1             | 3.9 ms    | 8.0 ms   |
| Flying Cthulhu             | 150,000   | 12            | 3.9 ms    | 8.7 ms   |
| Flying Cthulhu             | 750,000   | 1             | 18.7 ms   | 34.8 ms  |
| Flying Cthulhu             | 750,000   | 12            | 18.7 ms   | 36.7 ms  |
| 4000 cows (3.2k each)      | 12.8M     | 7 per cow     | 17.2 ms   | 39.0 ms  |

VS roughly doubles vertex transform cost relative to LBS, yet maintains real-time performance (30 fps+) for million-poly meshes and thousands of instances. Memory usage for up-propagated weights is $\sim$8–12 bytes per vertex-link, being denser than traditional LBS weights [2104.04934].

## 6. Applications and Known Limitations

### Applications

VS has been demonstrated in a range of stylization scenarios:

- Floppy ears and horns on a two-bone cow head
- Squashy and floppy neck on a giraffe
- Flapping wings and writhing tentacles on 150k–750k triangle models (“Cthulhu”)
- Thousands of cows with stylized jiggle using GPU instancing
- Minimal-rig dragons with enhanced wing/tail secondary motion

### Limitations

- **Non-linear Artifact Risk:** Additive, non-linear per-bone displacements can yield shearing or local volume artifacts, especially when adjacent bones undergo conflicting high-speed motions.
- **Geometry Issues:** Extreme floppiness may cause self-penetration in thin geometry; angle clamping is advised.
- **Kinematic Nature:** VS is purely kinematic—physical effects such as inertia, contact, or backward propagation are absent. No acceleration effects (rebound, bounces) as there is no memory or integration of past states.
- **No Collision Response:** VS does not handle collisions or physical constraints.

These limitations are significant for precision physical simulation but are typically acceptable or even preferable for artistic stylization within animation pipelines.

## 7. Context, Impact, and Outlook

VS extends standard skinning pipelines by fusing physically inspired, velocity-driven deformation with fully real-time, artist-friendly workflows. The method functions entirely within existing GPU/CPU animation architectures, requiring no new rigging or simulation tools, and introduces a minimal overhead relative to LBS. Its modular controls and compatibility with GPU instancing make it suitable for both high-density crowds and single-character hero assets.

A plausible implication is that future work may seek to augment VS with limited temporal integration for richer stylization effects or to hybridize with physics-based solutions for partially interactive or contact-aware deformation. The method offers a robust baseline for automated secondary animation in stylized or non-photorealistic rendering contexts [2104.04934].

Source: https://www.emergentmind.com/topics/velocity-skinning