Icon BVHView

 

Icon Dead Blending Node in Unreal Engine

 

Icon Propagating Velocities through Animation Systems

 

Icon Cubic Interpolation of Quaternions

 

Icon Dead Blending

 

Icon Perfect Tracking with Springs

 

Icon Creating Looping Animations from Motion Capture

 

Icon My Favourite Things

 

Icon Inertialization Transition Cost

 

Icon Scalar Velocity

 

Icon Tags, Ranges and Masks

 

Icon Fitting Code Driven Displacement

 

Icon atoi and Trillions of Whales

 

Icon SuperTrack: Motion Tracking for Physically Simulated Characters using Supervised Learning

 

Icon Joint Limits

 

Icon Code vs Data Driven Displacement

 

Icon Exponential Map, Angle Axis, and Angular Velocity

 

Icon Encoding Events for Neural Networks

 

Icon Visualizing Rotation Spaces

 

Icon Spring-It-On: The Game Developer's Spring-Roll-Call

 

Icon Interviewing Advice from the Other Side of the Table

 

Icon Saguaro

 

Icon Learned Motion Matching

 

Icon Why Can't I Reproduce Their Results?

 

Icon Latinendian vs Arabendian

 

Icon Machine Learning, Kolmogorov Complexity, and Squishy Bunnies

 

Icon Subspace Neural Physics: Fast Data-Driven Interactive Simulation

 

Icon Software for Rent

 

Icon Naraleian Caterpillars

 

Icon The Scientific Method is a Virus

 

Icon Local Minima, Saddle Points, and Plateaus

 

Icon Robust Solving of Optical Motion Capture Data by Denoising

 

Icon Simple Concurrency in Python

 

Icon The Software Thief

 

Icon ASCII : A Love Letter

 

Icon My Neural Network isn't working! What should I do?

 

Icon Phase-Functioned Neural Networks for Character Control

 

Icon 17 Line Markov Chain

 

Icon 14 Character Random Number Generator

 

Icon Simple Two Joint IK

 

Icon Generating Icons with Pixel Sorting

 

Icon Neural Network Ambient Occlusion

 

Icon Three Short Stories about the East Coast Main Line

 

Icon The New Alphabet

 

Icon "The Color Munifni Exists"

 

Icon A Deep Learning Framework For Character Motion Synthesis and Editing

 

Icon The Halting Problem and The Moral Arbitrator

 

Icon The Witness

 

Icon Four Seasons Crisp Omelette

 

Icon At the Bottom of the Elevator

 

Icon Tracing Functions in Python

 

Icon Still Things and Moving Things

 

Icon water.cpp

 

Icon Making Poetry in Piet

 

Icon Learning Motion Manifolds with Convolutional Autoencoders

 

Icon Learning an Inverse Rig Mapping for Character Animation

 

Icon Infinity Doesn't Exist

 

Icon Polyconf

 

Icon Raleigh

 

Icon The Skagerrak

 

Icon Printing a Stack Trace with MinGW

 

Icon The Border Pines

 

Icon You could have invented Parser Combinators

 

Icon Ready for the Fight

 

Icon Earthbound

 

Icon Turing Drawings

 

Icon Lost Child Announcement

 

Icon Shelter

 

Icon Data Science, how hard can it be?

 

Icon Denki Furo

 

Icon In Defence of the Unitype

 

Icon Maya Velocity Node

 

Icon Sandy Denny

 

Icon What type of Machine is the C Preprocessor?

 

Icon Which AI is more human?

 

Icon Gone Home

 

Icon Thoughts on Japan

 

Icon Can Computers Think?

 

Icon Counting Sheep & Infinity

 

Icon How Nature Builds Computers

 

Icon Painkillers

 

Icon Correct Box Sphere Intersection

 

Icon Avoiding Shader Conditionals

 

Icon Writing Portable OpenGL

 

Icon The Only Cable Car in Ireland

 

Icon Is the C Preprocessor Turing Complete?

 

Icon The aesthetics of code

 

Icon Issues with SDL on iOS and Android

 

Icon How I learned to stop worrying and love statistics

 

Icon PyMark

 

Icon AutoC Tools

 

Icon Scripting xNormal with Python

 

Icon Six Myths About Ray Tracing

 

Icon The Web Giants Will Fall

 

Icon PyAutoC

 

Icon The Pirate Song

 

Icon Dear Esther

 

Icon Unsharp Anti Aliasing

 

Icon The First Boy

 

Icon Parallel programming isn't hard, optimisation is.

 

Icon Skyrim

 

Icon Recognizing a language is solving a problem

 

Icon Could an animal learn to program?

 

Icon RAGE

 

Icon Pure Depth SSAO

 

Icon Synchronized in Python

 

Icon 3d Printing

 

Icon Real Time Graphics is Virtual Reality

 

Icon Painting Style Renderer

 

Icon A very hard problem

 

Icon Indie Development vs Modding

 

Icon Corange

 

Icon 3ds Max PLY Exporter

 

Icon A Case for the Technical Artist

 

Icon Enums

 

Icon Scorpions have won evolution

 

Icon Dirt and Ashes

 

Icon Lazy Python

 

Icon Subdivision Modelling

 

Icon The Owl

 

Icon Mouse Traps

 

Icon Updated Art Reel

 

Icon Tech Reel

 

Icon Graphics Aren't the Enemy

 

Icon On Being A Games Artist

 

Icon The Bluebird

 

Icon Everything2

 

Icon Duck Engine

 

Icon Boarding Preview

 

Icon Sailing Preview

 

Icon Exodus Village Flyover

 

Icon Art Reel

 

Icon LOL I DREW THIS DRAGON

 

Icon One Cat Just Leads To Another

Dead Blending Node in Unreal Engine

Created on Aug. 13, 2023, 10:37 a.m.

Unreal Engine 5.3 comes with a new experimental "Dead Blending" node that acts as a drop-in replacement to the Inertialization node.

In general I've found it creates better looking blends than the standard Inertialization node, in particular when you have transitions between poses that are very different:

Or when you are triggering transitions very frequently:

However you may find that sometimes it tends to damp out the motion a bit more than the normal Inertialization node.

The way it works is a similar to the basic exponential decay method I described in my previous article on Dead Blending, with a few small differences.

First, instead of updating the extrapolated pose each frame we just store the pose at the point of transition and use an implicit extrapolation function to get the extrapolated transform of the joint at an arbitrary time in the future past the point of transition (given some half-life used to control the rate of decay of the velocity).

Here is some similar extrapolation code adapted for quaternions and allowing an individual half-life per rotation axis:

void extrapolate_decay_rotation(
    quat& x,
    vec3& v,
    vec3 halflife,
    float dt,
    float eps = 1e-8f)
{
    vec3 y = LN2f / (halflife + eps);
    x = quat_mul(quat_from_scaled_angle_axis(
        (v / (y + eps)) * (1.0f - fast_negexp(y * dt))), x);
    v = v * fast_negexp(y * dt);
}

Although it doesn't make much difference to the final result, this feels like a more elegant solution to me since it reduces the amount of state being mutated each frame and more closely resembles the setup for normal Inertialization.

The big difference in this implementation comes from having individual half-lives per degree of freedom for each joint of the character. This allows us to safely extrapolate joints on axes that we are sure can move far, while limiting the extrapolation for joints on axes that we are not certain can move.

These half-lives aren't set by hand. Instead we use a simple heuristic to compute them. At the point of transition we look at the source and destination animation and determine which joint axes are moving toward the destination animation and at what rate. Axes which are moving toward the destination animation with a low velocity can be extrapolated for a long time, while axes that are moving with a fast velocity, or away from the destination animation we want to give a short half-life.

In code it looks something like this:

float max_mag(float x, float eps)
{
    return
        x >= 0.0f && x <  eps ?  eps :
        x <  0.0f && x > -eps ? -eps : x;
}

vec3 max_mag(vec3 x, float eps)
{
    return vec3(
        max_mag(x.x, eps),
        max_mag(x.y, eps),
        max_mag(x.z, eps));
}

vec3 estimate_halflife(
    vec3 src_dst_diff,
    vec3 src_vel,
    float halflife_scale = 0.3f,
    float halflife_min = 0.1f,
    float halflife_max = 1.0f,
    float eps = 1e-8f)
{
    return clamp(
        halflife_scale * (src_dst_diff / max_mag(src_vel, eps)), 
        halflife_min, 
        halflife_max);
}

Here src_dst_diff is the difference between source and destination animations (rotations are encoded as scaled-angle-axis), src_vel is the velocity (or angular velocity) of the source animation, halflife_scale controls the overall expected scale of the half-lives, and halflife_min and halflife_max control the overall min and max half-life to allow.

If we visualize the extrapolations we can see how this heuristic affects them - some joints are allowed to extrapolate for a long time while others are brought to a halt almost instantly. In this way we almost always avoid violating joint limits while maintaining long extrapolations where we can.

This is still an experimental node, so the implementation and interface are subject to change, but I hope it will provide useful to developers who are having a bit of trouble getting good results out of the normal Inertialization node.

And if you'd like to try it out yourself I've added the same heuristic as an option in my previous article's demo code.

github twitter rss