Vertex Animation in Games: How to Make It Art-Directable, Performant, and Shippable

DeGGeD — Fri, 13 Nov 2026 08:51:49 +0000

Making vertices move is easy. Making the motion art-directable, cheap at scene scale, and correct across the entire render pipeline is the skill real production actually demands.

Vertex tricks are among the most popular topics among technical artists and developers and for good reason: they deliver fast, impressive results. Flags flutter, foliage sways, water ripples, list can go on.

Then the effect leaves the demo scene, and the real work begins:

The leaves move, but the shadow stays still.
The entire forest sways in perfect unison (unnatural).
The effect pops out of existence near the edge of the screen.
TAA smears the foliage, even though the geometry looks correct.

That's the devil in the details and as you'll discover if you've been in the industry long enough, it's always there. Newcomers, don't be afraid: you'll meet it too, as you progress.

At some point, I decided to build a resource that answers the question I keep getting: "Vertex animation - where do I start? Where can I learn it in the most time-efficient way?" The goal is a future-proof, go-to answer you can hand to anyone who asks.

This article is my attempt at that: a practical, readable guide to vertex-stage motion in games. What the stage is (and isn't) good at, the building blocks every piece of motion is made from, and the production checks that decide whether your effect survives once it leaves the demo scene. By the end, you'll have a clear mental model of how to approach vertex motion in production.

The samples and resources mentioned within the article were built and tested in Unity 6.4 with URP 17.4, using Blender 5.1 for the data-authoring and baking workflows, both as the primer and the playground. The concepts are engine-agnostic: spaces, data, time, masks, pivots, passes. Code samples are Unity URP.

Let's dive in!

Contents:

When Vertex Animation Is the Right Tool Coordinate Spaces: Who Owns This Motion?
Data: Know Where Every Input Comes From
Matrices in a Minute (and why production code often avoids manual calculations)
Time: Wrap It, Shape It, Offset It
Masks: Where Does The Motion Happen?
-- Procedural masks: gradients and noise
-- Authored masks: vertex colors, UVs, textures
-- Runtime-driven masks
Gameplay-Driven Motion: From Loop to Response
Reusable Motion Patterns
-- The sine-wave offset
-- Layered waveforms: Gerstner-style
-- Shading repair: normals after deformation
-- When repetition starts to feel fake
Pivot-Driven Motion: Believability Comes from Anchors
Now Make It Shippable: The Six Production Checks
-- Pass consistency
-- Bounds
-- Motion vectors and TAA
-- Normals
-- LODs
-- Instancing
Key Takeaways, Next Steps & Where to Go From Here

Scope: what this article does not cover: vertex animation textures, Alembic and geometry caches, blend-shape setups, compute-driven deformation, mesh shaders, and ML deformers. Each of those deserves its own dedicated deep dive, and squeezing them in would make this piece wider and shallower. Today we go narrower, but deep enough to build, control, debug, and reason about vertex-stage motion.

All the scenes, shaders, and scripts referenced in this article are available in the ShaderStory repository, feel free to follow along with the code.

When Vertex Animation Is the Right Tool

The rule of thumb that guides everything else:

Broad motion, low cost, high control. Not perfect motion.

Vertex animation is strongest when you need motion that is cheap, procedural, controllable, and scalable across many objects.

The classic list:

Foliage in the wind
Flags and cloth-like strips
Water-like surfaces, ripples, waves
Breathing props, idle sway
Impact reactions, shockwaves
Wind response, proximity deformation, gameplay reactions
Per-instance variation: thousands of assets sharing one shader, each moving slightly differently

The key word is approximate. Vertex animation is excellent when the motion needs to feel believable. It is the wrong tool when it has to match a precise simulation, an authored performance, or physical truth. A character animation, a cloth that must collide, a liquid that must preserve volume: those need real systems.

Why the vertex stage is so useful

The vertex stage happens early, before rasterization. You move vertices before the GPU even draws triangles, and if the illusion holds at that level, you get a lot of perceived motion for very little cost. Concretely, a well-built vertex stage setup can:

replace bones, baked clips, and CPU-side updates with one shared shader
drive many assets from a single material
source variation from masks, vertex colors, time offsets, wind, instance data, or gameplay parameters

There is one important condition: the mesh has to be reasonable. Cheap deformation on a sensible mesh is cheap. The same math on a dense mesh, rendered in four passes, and instanced a thousand times, is suddenly not.

Keep this as the filter for every idea: does this need to be believable, or does it need to be true? Believable: the vertex stage. True: a real system. If the silhouette of the motion can sell the effect, prototype it in the vertex stage first.

Coordinate Spaces: Who Owns This Motion?

When you start moving vertices, the first question is not "what's the formula?" The first question is: what is this motion attached to?

Get it wrong and the effect looks almost right, which is worse than obviously wrong. It's the root of nearly every space-related vertex bug I've debugged, so it's worth internalizing properly.

Object (model) space: the motion belongs to the asset's local frame. If the object rotates, the motion rotates with it. This is what you want for local bends, pivots, authored masks, and behavior that should stay welded to the mesh.
World space: the motion belongs to the environment. The right choice for wind direction, waves, shockwaves, proximity fields, and gameplay volumes, because many objects need to agree on the same position or direction.
View (camera) space: the motion belongs to the camera. Useful for billboards, impostors, camera-facing cards, view-dependent VFX. Risky for anything that should feel physically grounded, because the motion changes relative to the viewer.
Clip / NDC space: projection-space tricks, outlines, screen-relative effects. A specialist lane, not a starting point for mesh deformation.
Screen space: UI, screen-space decals, outlines.

The practical pattern: you usually start from object-space position; if you need world behavior (wind, gameplay fields), you transform to world, apply the offset, then transform to clip for rendering. If you need camera-relative behavior, you do it in view space.

Two rules that prevent most space-related bugs:

The position and the offset must agree on space. Don't add a world-space wind offset to an object-space position without transforming one into the other.
Positions, directions, and normals are different things. Positions include translation. Directions don't. Normals need their own correct transform, especially when scale is involved.

Watch those three together: the math is nearly identical in each, and the behavior changes completely depending on where the position and offset are evaluated. Same wave, three different owners.

Data: Know Where Every Input Comes From

Don't treat shader data as magic. Once you know the space, the next question is: what data do I have to drive the motion, and where should custom data live?

The data hierarchy

Everything available to a vertex shader falls into tiers:

Where custom motion data should live

The rule: pick the smallest stable data path that satisfies the control.

Painted or baked per-vertex, rarely changes → vertex colors / UVs / custom streams (masks, stiffness, pivot weights, phase offsets).
Artist-tuned for the whole material → material properties (amplitude, frequency, direction, noise scale).
Different for each placed object → per-object / instanced data (random seed, phase offset, bend multiplier).
Belongs to a shared system → global shader properties (wind, player position, impact points).
Large, or changing every frame → buffers, with the understanding that this adds setup and an extra memory read.

And here is the production lesson that I cannot emphasize enough:

A lot of vertex motion bugs are not math bugs. They are undocumented data-ownership bugs.

If UV2.x means pivot weight, vertex-color red means stiffness, and alpha means phase, write that convention down. Document the valid range and how the shader decodes it. The shader can be brilliant and still rot in three months if only one person remembers what the channels mean.

Matrices in a Minute (and why production code often avoids manual calculations)

You can't do rotation-based motion without meeting matrices. Here's the shortest version: think of a matrix as a recipe that builds a new position from an old one. Where values land is meaningful:

Values on the diagonal → each axis affects itself → scale
Values in the translation column → adds an offset → translation
Values off-diagonal → axes start mixing → rotation

Two things to remember from this:

W matters. We use 4×4 matrices even though positions are XYZ because W lets translation live in the same multiply. Positions use w = 1 (translation applies); directions use w = 0 (they rotate/scale but never translate).
Order matters. Scale, rotate, and translate are not interchangeable. In Unity, the local matrix is composed T R S, but a point experiences Scale → Rotation → Translation because the rightmost operation applies first. The same values produce a different result when the order changes. That sentence will save you at least once per project.

Theory vs. production

For learning, writing out explicit matrices is great: the structure becomes visible. But in production vertex code I usually prefer exposed variables & functions:

// scale in local space, rotate around the intended pivot,
// translate the final result, no 3 matrices materialization
float3 local = positionOS - pivotOS;
local = RotateAroundAxis(local, axisOS, angle);
positionOS = pivotOS + local;

Why? Explicit matrices can cost more ALU per vertex, increase register pressure, make row-major/column-major mistakes easier, and block compiler optimizations. So the lesson isn't "never use raw matrices". It's: use matrices when they improve clarity or are structurally required; don't build them out of habit.

Time: Wrap It, Shape It, Offset It

Time is one of the main ingredients of procedural motion, but raw time is almost never the final value you want.

Raw _Time.y grows forever. That's fine for sequencing and system-level logic. But for motion, you usually want a local, bounded value.

Wrap It

For loops, pulses, and repeating motion, convert time into a bounded 0..1 phase:

// Looping motion: stable repeating 0..1 phase
float phase01 = fracTime.y * Speed);
// Duration-based motion: local time, easier to restart
float localTime = fmodTime.y, Duration);
float local01 = localTime / _Duration;

Why wrap? A bounded local time is easier to reason about, easier to restart, and easier to combine with masks and easing. It also stops you feeding ever-growing values into sin() or noise, which eventually invites precision problems and visual drift.

Use continuous time for systems. Use wrapped time for motion.

Shape It

Once you have a normalized 0..1 value, you don't have to use it raw. Two levers shape how it moves.

Easing changes the curve. Linear time changes at a constant rate, which feels mechanical. Easing reshapes the acceleration profile:

Ease-in, starts slow, accelerates. Reads as anticipation, charge-up.
Ease-out, starts fast, settles. Reads as recovery, landing.
Ease-in-out, soft, controlled. Often the best default for organic motion.
Bounce / back / elastic, overshoot and secondary response. Great for stylized impacts and recoil; easy to overuse.

Ping-pong removes the hard restart. A wrapped phase runs 0 to 1, then snaps back to 0. Ping-pong runs 0 to 1 to 0 and reverses, which turns a jarring loop into a continuous in-out motion. It's the natural fit for breathing, sway, and anything that should ease back instead of resetting:

float t01 = fracTime.y * Speed); // wrapped phase, 0 -> 1
float pp = abs(1.0 - t01 * 2.0); // optional ping-pong, 0 -> 1 -> 0
float shaped = EaseInOutSine(pp); // or your curve of choice
float3 offsetOS = directionOS shaped _Amplitude;
positionOS += offsetOS;

This is the shift that separates animating values from designing the motion curve: the start and end can be identical; the acceleration profile is what the eye actually reads. If the effect will live in your project long enough for someone else to maintain it, put the easing and ping-pong helpers in a shared include file, not copied into every shader.

Offset It

If every object uses exactly the same time value, everything moves in perfect sync, which reads as immediately artificial. A phase offset (a stable random value added to the phase) staggers motion per object, per instance, or per vertex:

float phase = fracTime.y * Speed + _PhaseOffset);

One line. One of the highest-value lines in the whole article.

Masks: Where Does the Motion Happen?

A mask answers the question that raw time and amplitude never answer: where does the motion happen, and how strongly?

Procedural masks: gradient for structure, noise for breakup

The simplest procedural mask is a gradient, for example, object-space height, so the bottom of a plant stays planted while the top moves:

float gradientMask = smoothstepGradientMin, GradientMax, positionOS.y);

A gradient alone is structured but uniform. Noise breaks the uniformity so not every vertex moves in lockstep:

float2 noiseUV = positionWS.xz * NoiseScale + float2(frac(Time.y * _NoiseSpeed), 0.0);
float noiseMask = SimpleNoise(noiseUV);
float mask = gradientMask * noiseMask; // structure × breakup

The production pairing: the gradient gives structure, the noise adds variation, and smoothstep gives you art direction, because a hard procedural falloff reads as artificial while a smooth one reads as intent.

And remember the space rule from the coordinate-spaces section: procedural masks are not space-neutral. Noise sampled in object space sticks to the asset; noise sampled in world space stays fixed in the world while the asset moves through the pattern. Same function, different behavior.

Authored masks: direct artistic control

Procedural masks are fast to generate, but they're still procedural guesses. When an artist or a tool needs direct control over where motion happens, you reach for authored data:

The last row is the most powerful and the most fragile: packed channels only work if everyone agrees what each channel means. Write that convention down.

And the single most repeated rule in this article and production:

Debug the mask before you debug the motion. If the mask is wrong, the deformation will be wrong no matter how good the motion function is. Always build a mask-debug view first, render the mask as the final color and look at it before you apply any displacement.

Runtime-driven masks: motion becomes interaction

Procedural masks come from math. Authored masks come from artists. Runtime-driven masks come from live game state, and this is where vertex motion stops being decoration and starts being behavior.

The workhorse example is the sphere mask: the game provides a world-space center, radius, and falloff, and every vertex checks its distance to that center and computes its own local response. The same setup drives a player-proximity lean, a wind gust, a shockwave, or a water ripple; only the displacement direction and shaping change.

float dist = length(positionWS - _MaskCenterWS);
float mask = 1.0 - smoothstepMaskRadius * Softness, _MaskRadius, dist);
positionWS += DisplaceDirWS * Amplitude * mask;

Because it's a distance test in world space, the space rule bites here: if the mask center is world-space, the position used for the test must be world-space as well. Mismatch the spaces and the mask silently fails.

One or two global masks are simple. If you need many overlapping masks, move to arrays, buffers, or a gameplay-side aggregation system, not a dozen hand-authored globals.

Gameplay-Driven Motion: From Loop to Response

This is my favorite part of the whole subject, because it's built by adding one ingredient at a time, and each addition is a distinct, visible level of believability. Follow the four steps with the GIFs; you'll see the same shader go from "generic animation" to "alive."

Step 1: Time only

float3 positionWS = TransformObjectToWorld(positionOS);
float wave = sinTime.y * Speed) * _Amplitude;
positionWS += float3(0.0, wave, 0.0);
positionCS = TransformWorldToHClip(positionWS);

The motion works, but every vertex receives the same temporal input, so the whole asset pulses uniformly. This is motion, not yet behavior. It's still a valuable checkpoint: it proves the deformation path is live before you complicate anything.

Step 2: Time + Axis: position gives the motion structure

Project world position onto a direction to spread the phase across the mesh. Now the wave travels instead of pulsing:

float wave = sin(dot(positionWS, normalizeWaveAxisWS)) * Frequency + Time.y * Speed) * _Amplitude;
positionWS += normalize(_MoveAxisWS) * wave;

Note the two jobs: the axis sets where the pattern travels; the move direction sets which way vertices displace. Different vectors, different effects. Time keeps the wave moving; position is what gives it structure.

Step 3: + Mask: the mask makes it feel attached

Now tell the shader where motion is allowed. Here the vertex color acts as influence: near zero at the attached end, strong at the free end.

float mask = IN.color.r; // or a UV gradient, the motion function stays reusable
positionWS += normalize(_MoveAxisWS) wave mask;

This is a strong production pattern: the motion function stays generic and reusable; the asset decides where that motion is allowed. Same shader, different meshes, different character.

Step 4: + Gameplay parameters: reactive, not decorative

The final stage modulates everything with live gameplay data. The controller sends smoothed world velocity, facing direction, and signed turn rate into the shader:

speed scales the response, running makes it stream, standing still leaves a subtle idle flutter
turning adds sideways drag
a small idle flutter remains at zero speed, because a fully static idle reads as dead, while an instant jump from still to full motion reads as fake

The core gate, reusing the wave and mask from the earlier steps:

float velocity01 = smoothstep(0.0, 1.0, saturateCharacterSpeed / MaxCharacterSpeed));
float response = _IdleAmplitude + velocity01; // small idle flutter even at rest
positionWS += normalize(_MoveAxisWS) wave mask * response;

One production rule that step 4 is really worth memorizing:

Filter gameplay data before it drives deformation. Smooth and clamp on the CPU (or in a controlled shader pass); never let raw, jittery inputs reach the vertex math directly. "Fake it till you make it" is a legitimate production strategy, as long as the fake is smooth.

That GIF is the thesis of this whole article in eight seconds.

Reusable Motion Patterns

There are two patterns that do most of the work, and two follow-ups decide whether they actually sell.

The sine-wave offset

float3 offsetDirOS = normalize(_OffsetDirectionOS);
float spatialPhase = positionOS.x * _Frequency;
float temporalPhase = frac(Time.y * Speed) / TWO_PI) * TWO_PI;
float wave = sin(spatialPhase + temporalPhase + PhaseOffset) * Amplitude;
positionOS += offsetDirOS wave mask;

The idea is two independent phases: position spreads the wave across the surface, time advances it. Amplitude is how far it moves; frequency is how tightly packed; direction is where it travels; _PhaseOffset is your per-object anti-sync.

It is the right first pattern for flags, cloth strips, grass, water-like surfaces, idle sway, anything that benefits from rhythmic deformation rather than authored animation.

And be honest about what it is: it is not a simulation. You are not solving cloth or water. You are building a controllable, repeatable pattern that sells the effect cheaply.

Layered waveforms: Gerstner-style

A single sine is readable, and obviously repetitive within a few seconds. The fix is layering: several waves, each with its own direction, amplitude, frequency, speed, and phase:

float3 posWS = baseWS;
posWS += GerstnerOffset(baseWS, DirA, AmpA, FreqA, SpeedA, PhaseA, SteepA);
posWS += GerstnerOffset(baseWS, DirB, AmpB, FreqB, SpeedB, PhaseB, SteepB);

The Gerstner step that separates this from plain sines: it displaces horizontally along the wave direction, not just vertically, which produces the sharp, leaning crest that reads as "water" instead of "bumpy plane."

The cost warning scales with the layer count: every wave adds math per vertex, repeated across every pass, multiplied by mesh density. Layer enough waves to sell the surface; keep the count deliberately controlled.

Remember that displaced water is not only a vertex problem, normals, reflections, and foam must support the motion (we will take a closer look in the next section).

Shading repair: normals after deformation

Here's a classic trap: the geometry moves perfectly, but the lighting behaves as if the surface never changed. Highlights slide the wrong way, reflections feel detached, and the deformation sells itself as fake in one glance, because the normals still describe the original flat surface.

The practical fix for wave-style surfaces is finite-difference reconstruction:

For wave-style surfaces, finite-difference reconstruction is the practical default:

evaluate the displaced surface at the current point,
evaluate it again at two small nearby offsets,
build local tangent directions from those displaced neighbors,
cross product → the reconstructed geometric normal.

float3 D(float3 p) { return deform(p); } // the same deformation the pass uses
float3 p = D(baseWS);
float3 t = D(baseWS + e1) - p; // e1 / e2: small, non-parallel neighbor offsets
float3 b = D(baseWS + e2) - p;
float3 n = normalize(cross(t, b)); // tangent x tangent = new normal

This follows the actual displaced shape, which matters more for Gerstner motion, which moves both vertically and horizontally. For mostly-vertical motion, a plain height-field gradient is cheaper and fine.

And keep one artistic knob: a repair-strength blend from original normal to fully reconstructed. In production, partial repair plus a normal map for micro-detail is usually the better option than chasing mathematical perfection: large motion from geometry, small detail from shading.

When repetition starts to feel fake

Procedural motion usually fails not because the math is wrong, but because the pattern becomes visible. One wave, same speed, same amplitude, same phase on every object → the whole field moves like a machine. And the first instinct, more amplitude, usually makes the fakeness louder.

The real toolkit is controlled irregularity:

phase offsets across vertices, objects, or instances
slightly different amplitudes, speeds, frequencies
layered broad + small secondary motion (a hierarchy, not one uniform wave)
masks and noise to break uniform patterns
simplified or reduced motion by distance, importance, or LOD

Enough variation to hide the repetition; not so much that the motion loses its art direction.

Pivot-Driven Motion: Believability Comes from Anchors

Simple offset motion is cheap and readable, but it often feels like the mesh is translating through space. Real objects don't do that. A leaf rotates from its stem. A branch rotates from its base. A door rotates around its hinge. The motion is believable because it is anchored to a meaningful point.

It's worth naming what goes wrong, because the failure is subtle. A plain offset floats the whole mesh in place. A rotation around the object origin reads as the mesh spinning on itself. Only a rotation around a local pivot reads as the part actually hinging where it should. Same angle, three completely different results.

That anchor is the pivot, and it's the single biggest leap in perceived quality for foliage and prop motion.

The core pattern:

float3 local = positionOS - pivotOS; // 1. move into pivot-local space
float3 axis = normalize(axisOS); // 2. rotation axis, same space
local = RotateAroundAxis(local, axis, angle);
positionOS = pivotOS + local; // 3. move back to object space

Subtract the pivot, rotate, add it back. One production detail: position, pivot, and axis must agree on space. Object-space position with a world-space pivot is a silent, confusing failure.

Where does pivot data come from?

One object: define the pivot by hand (a material property is fine). Many leaves, many parts: you need a data strategy, and this is a great Blender workflow to know:

Model each leaf as its own object, with the object origin placed at the stem.
Run a small bake script: write each object's origin into its vertices' vertex color, RGB = encoded pivot position (0..1 within bounds), A = random phase.
Merge everything into one mesh. Every vertex still knows which pivot it belongs to.
Decode in the shader:

float3 pivotOS = lerpPivotBoundsMin, PivotBoundsMax, IN.color.rgb);
float phase = IN.color.a;
float angle = sinTime.y * Speed + phase TWO_PI) _AngleAmplitude;
float3 local = positionOS - pivotOS;
local = RotateAroundAxis(local, axisOS, angle);
positionOS = pivotOS + local;

The result: one merged mesh, every leaf rotating from its own stem, with the alpha phase de-synchronizing the field. In the viewport the vertex color looks like a random gradient, but it's data. What matters isn't this exact channel layout; what matters is that the source, the packing, and the decode path are all explicitly defined and documented, as the data section says.

And, exactly as with the masks: debug the pivot before you trust the rotation. Render the pivot, or the distance to it, as color and look at it. If the pivot data is wrong, the motion will be wrong no matter how good the rotation function is.

Baking and unpacking pivot data

The classic foliage workflow bakes the pivot into the mesh, then unpacks it in the shader:

Model each leaf as its own object, with the object origin placed at the stem.
Bake each object's origin into its vertices' vertex color.
Merge everything into one mesh; every vertex still knows which pivot it belongs to.
Unpack in the shader:

// A common per-channel packing convention
float3 pivotOS = lerpPivotBoundsMin, PivotBoundsMax, IN.color.rgb); // pivot, 0..1 in bounds
float influence = IN.color.a; // stiffness / influence
float3 axisOS = DecodeAxisOS(IN.uv2.xy); // rotation axis
float phase = IN.uv2.z * TWO_PI; // per-leaf phase
float variation = IN.uv2.w; // per-leaf variationfloat angle = sinTime.y * Speed + phase) _AngleAmplitude influence;

The axis is the one flexible channel: it can be a constant, derived from the normal, or stored in another stream. But pivot, axis, and influence all have to live somewhere, and the source, the packing, and the decode path must all be explicitly defined and documented, as the data section says. In the viewport the packed vertex color looks like a random gradient, but it's data.

Now Make It Shippable: The Six Production Checks

Everything above makes a demo. This section is what separates a demo from a shipped system: the things that tend to break once the effect leaves the hero scene.

The unifying idea:

Don't ship a pretty vertex function. Ship the motion contract.

"Looks fine" in the main pass is not enough; it's only one part of the contract.

The six checks, at a glance:

1. Pass consistency: same deformation, same inputs, same space, same time

The most common failure: the forward pass bends the vertices, but the shadow, depth, and motion-vector passes don't reproduce that deformation. The asset looks correct, but the shadow doesn't move, while depth-dependent systems (fog, decals, SSAO, soft particles) read the wrong shape, and the whole thing is subtly inconsistent, which is exactly what the eye catches before the brain can name.

The correct fix is not to re-implement the effect per pass. Centralize the deformation in one shared function / include, call it from every pass, and make sure each pass uses the same inputs: same time source, same wind parameters, same masks, same pivots, same per-instance variation, same space conventions.

// One function, many passes:
float3 ApplyWind(float3 posOS, float time, float instanceSeed);

Copy-paste per pass will drift. Shared logic with shared inputs doesn't. The contract, pass by pass:

2. Bounds: design for worst-case displacement

The renderer decides visibility from bounds computed at rest, on the CPU, but your deformation happens later, on the GPU. If displaced vertices escape those bounds, the object pops, clips, or disappears at the edge of the screen. The same mismatch can hurt shadows too.

The fix is not to make bounds arbitrarily huge; oversized bounds wreck culling efficiency. Design for the maximum possible displacement (you should have defined this on day one), and expand bounds just enough to cover that worst case.

float3 safeExtents = originalExtents + float3(maxRadius, maxRadius, maxRadius);

3. Motion vectors and TAA: temporal systems need correct motion

TAA, motion blur, and friends don't only care about the current frame; they need to know where the surface was in the previous frame so history can be reprojected. If the motion-vector pass doesn't evaluate the same deformation, the renderer behaves as if the surface were static, and you get ghosting, smearing, and shimmering. Foliage makes this especially visible: thin, alpha-tested, high-frequency, constantly moving.

float3 currentOS = ApplyWind(restOS, currentTime, instanceSeed);
float3 previousOS = ApplyWind(restOS, previousTime, instanceSeed);
// motion vectors derive from the difference of the two clip-space results

Two details that matter: current and previous must come from the same function, and the previous-frame result must be deterministic; if it's driven by unstable randomness or frame-dependent noise, the vectors stay broken even when the code looks correct.

And a legitimate production escape valve: for dense distant forests, deliberately simplify or fade motion layers, and accept some temporal artifacts as a conscious performance tradeoff, never as an accidental bug.

4. Normals: match the visual goal, not the math by default

Subtle leaf flutter can be perfectly fine on imported, art-directed normals, often bent, averaged, or biased for a broader canopy response. Physically "correct" reconstruction can make a stylized asset look worse. But strong deformation (broad bends, large pivots, waves) detaches highlights and reflections from the shape, and that you must repair.

So this is a per-asset decision, keep, bend, bias, blend, or reconstruct, driven by the lighting intent of the asset, not by default. The reconstruction methods themselves live in the patterns section; here the question is a shipping decision, not a math exercise.

5. LODs: LOD the motion, not only the mesh

LODs are often different meshes, not cheaper copies of the same mesh: different topology, vertex counts, vertex colors, UV payloads, pivots, bounds. If your motion depends on vertex colors, packed UVs, stored pivots, or phase offsets, and that data disappears or shifts in a lower LOD, the motion can pop, rotate around the wrong point, or change amplitude at the transition.

And consistency is not identical motion. A coarse distant LOD should run simpler, weaker motion, spending performance where the player can actually read it. The production decision is intentional per LOD: keep, simplify, or disable layers, with stable cross-fades. If two LODs visibly disagree during dithered overlap, the asset shimmers and double-images.

6. Instancing: variation per instance; logic stays shared

One plant in the wind is believable. A hundred identical plants pulsing in unison is a machine; the problem only becomes visible at population scale, which is the trap: the single-asset test always passes.

The fix is per-instance variation, phase offset, bend multiplier, stiffness, gust response, tint, sourced from a supported per-instance channel: instanced properties, per-object data, indirect buffers, or a stable object hash. The cardinal sin to avoid: solving synchronization by creating a unique material per plant. That destroys batching, multiplies draw calls and material state, and trades one artificial-looking problem for an expensive one.

And variation must be consistent across passes: if the main pass varies per instance but the shadow pass ignores the seed, you're back to the first shipping check (pass consistency).

Key Takeaways, Next Steps & Where to Go From Here

If you remember nothing else, make it these:

Vertex motion is for believable approximation, not precision. Broad motion, low cost, high control.
Always define the space first. Who owns this motion, the asset, the world, or the camera? Position and offset must agree on space.
Every input has an owner. Pick the smallest stable data path, mesh, material, instance, global, or buffer, and document the convention.
Wrap time for motion, shape it with easing, offset it per instance. You're designing a curve, not moving a value.
Debug the mask before you debug the motion.
Cost = vertices × passes × complexity. Measure at scene scale, with real density, real instances, real passes.
Ship the motion contract: same deformation, same inputs, same space, same time, in every pass. Bounds, shadows, depth, motion vectors, normals, LODs, and instancing are all part of the same system.

From Idea to Shipped Asset: the Practical Order

When you start a new vertex-motion effect, in this order:

Start with the simplest motion that proves the idea, time + one direction.
Define the space (object / world / pivot / custom) and the maximum displacement, early, because it drives bounds, shadows, LODs, and performance.
Decide where the driving data lives, properties, vertex colors, UVs, textures, buffers, or gameplay, and write the convention down.
Build the deformation as shared logic, one function, every pass.
Add debug views before adding complexity, mask view, normal view, motion-vector view, batch-cost view.
Validate in three passes: one asset → all LODs → scene scale.

Where to Go Deeper

The mental checklist that outlasts every specific technique: who consumes this moved position, and what data do they need? If you keep that question alive, the domain opens up naturally from here. Four directions worth going deeper in:

In practice, that means xCode for shader cost, Unity Frame Debugger and RenderDoc for the render pipeline, motion-vector debug views, and batch / draw-call inspection at field scale.

There's a line I keep coming back to as a technical artist, one that captures the whole discipline, the point where craft effort and artistic intent meet:

"When love and skill work together, expect a masterpiece." - John Ruskin

Don't try to catch the rainbow. Try to be better than you were yesterday.

If this saved you an afternoon of wondering why your shadow wasn't moving, share it with a colleague who's about to find out the hard way.

Thank you for the attention and till next time!

Code, Resources & Support

If this was useful, here's where to find more:

Code: All scenes, shaders and scripts from this article are in the ShaderStory repository on GitHub. Stars and issues are welcome.
More articles: ArtStation blog
Support the work: Patreon for additional material and to help keep this content coming.

Questions or your own production war stories with vertex animation? Leave a comment below.

—-

Originally published on ArtStation.

DEV Community: DeGGeD