Last updated June 2026.
I'll save you the suspense: the hard part of turning a video into a Roblox animation usually isn't the video. Modern AI mocap tracks a clean phone clip surprisingly well. The motion falls apart in the handoff — the moment it has to leave your capture tool, land on an R15 rig, survive the import, and then behave under Roblox's animation system inside an actual game.
I've watched plenty of clips that looked perfect in a 3D viewport turn into a foot-sliding, torso-clipping mess the second they hit a Roblox dummy. Almost every time, the fix was somewhere in the pipeline — not the source motion.
So this is the pipeline, in order, with the six spots that actually break and how to get past each one.
Quick disclosure: we build NoCapMocap, which exists specifically to delete most of this pipeline — it auto-retargets to R15 and imports onto a rig in one click. I'll flag where it helps and where you're still on your own. Everything else here is true no matter which tool you use.
1. Recording: garbage in, garbage to clean up later
Good Roblox motion starts before Roblox Studio ever opens. If the footage is shaky, half-occluded, or hard to track, every step after this becomes cleanup — and some of it you'll never fully fix.
A motion solver wants to see one person, head to toe, moving clearly against a stable background. Give it that and you skip a surprising amount of pain downstream:
- Shoot 1080p, 60fps if you can. More frames give the solver more to work with, especially on fast moves.
- Lock the camera down. Handheld wobble gets baked into the motion as drift you'll have to remove by hand.
- Keep the whole performer in frame, feet included. Cropped feet are where foot-sliding bugs are born.
- Even lighting, no hard backlight. Silhouettes confuse trackers.
- One person per clip, no loose hoodies or long hair hiding the joints.
- If your retarget step wants a rest pose, hold a clear T-pose or A-pose for a second at the start.
This isn't busywork. Bad source footage doesn't just look rough — it produces wrong joint rotations and noisy curves that get more obvious, not less, once they're stretched onto blocky Roblox proportions.
2. Retargeting: getting the motion onto an R15 skeleton
This is where most video-to-Roblox workflows quietly die. A great clip becomes unusable if the rest pose, the root, the scale, or the bone mapping is wrong — and the editor often won't warn you, it'll just look off.
The core problem: a real human skeleton and a Roblox R15 rig are not the same shape. R15 limbs are shorter and blockier, and — this catches people — R15 has a single Waist joint where a human skeleton has several spine bones. So a multi-bone spine has to collapse down to one.
Here's roughly how a standard humanoid (Mixamo-style) skeleton maps onto R15:
| Source bone | R15 part (joint) |
|---|---|
| Hips | LowerTorso (Root) |
| Spine / Spine1 / Spine2 | UpperTorso (Waist — all of them collapse here) |
| Neck → Head | Head (Neck) |
| LeftArm → LeftForeArm → LeftHand | LeftUpperArm → LeftLowerArm → LeftHand (Shoulder/Elbow/Wrist) |
| LeftUpLeg → LeftLeg → LeftFoot | LeftUpperLeg → LeftLowerLeg → LeftFoot (Hip/Knee/Ankle) |
A few rules that save the most grief:
- Map the root (hips) first. If the root is wrong, the whole body drifts or offsets and nothing below it will look right.
- Scale root translation to the avatar. Don't preserve real-world distance — a 1.7m human stride on a 1m-ish Roblox body is the #1 cause of foot sliding.
- Decide what to do with fingers, toes, and face bones. R15 doesn't have them. Drop them rather than leave them mapped to nothing.
- Scrub before you export. Check the first frame, 25%, 50%, 75%, and the last frame. Twisted shoulders, inverted knees, floating feet, or hands punching through the torso show up at these checkpoints first.
Don't trust the first solve just because it plays. Play it on the actual R15 rig and fix the mapping before you export anything.
The shortcut
If you generate with NoCapMocap, this whole step is done for you — every motion comes out already retargeted to R15. The table above is what's happening under the hood, not a checklist you have to run by hand.
3. FBX import: bring in only what Studio needs
If you're going the manual route, Roblox supports FBX for rigged content — but imported animation is far easier to debug when the file contains only the animation, nothing else.
- Bake your keys before exporting if the source uses IK, constraints, or drivers. Unbaked rigs are the classic "imports fine, doesn't move" bug.
- Strip unused meshes, lights, cameras, and materials.
- Import onto a clean default R15 rig first, not your fancy custom avatar. Prove the motion is good before you add variables.
- After import, confirm the track actually contains motion — not an empty or static curve.
- If a custom rig fails but a default R15 rig works, the problem is your rig, not the motion data.
Roblox's own export-requirements docs spell out the FBX settings and specifically call out baking animation when animation data is involved — worth a read if an import looks empty.
This is the other place the shortcut shows up: with the Motion Lab plugin there's no FBX at all. You generate or pull a motion and click Apply to selected rig. (And if you do need FBX for Unity, Unreal, or Blender, NoCapMocap exports a standard humanoid FBX too — so you're not locked in.)
4. Loop and priority: the settings that decide in-game behavior
An animation can preview perfectly and still misbehave the moment it's in a live game. Two properties decide that: Loop and Priority.
Loop is the easy one — on for cycles (idle, walk, run, hover, repeated emotes), off for one-shots (attacks, jumps, hits). One gotcha: Roblox doesn't interpolate from your last keyframe back to the first, so a loop with mismatched start/end poses will visibly snap. Match the end pose to the start, or it'll hitch every cycle.
Priority is where people lose an afternoon. Roblox plays animations in this order, highest wins:
Action4 > Action3 > Action2 > Action > Movement > Idle > Core
The classic failure: you import a cool attack, leave it at Core priority, and in-game the default Animate script's walk cycle (running at Movement) overrides it — so your attack barely shows. The reverse bites too: an idle accidentally saved as Action4 stomps on everything else. Set priority to match intent — gameplay actions at Action/Action2, locomotion at Movement, idles at Idle.
And test it the way the game runs it, not the way the editor previews it:
local animator = humanoid:WaitForChild("Animator")
local track = animator:LoadAnimation(animation)
track.Priority = Enum.AnimationPriority.Action
track.Looped = false
track:Play()
If it plays here but not in your experience, check that the asset is published and owned by the right account — an asset the experience can't access will preview in Studio and silently fail at runtime.
5. Cleanup: fix what players actually notice
Video-based motion and AI mocap almost always need a polish pass. The good news: players only notice a handful of things, so you don't have to chase perfection — just the visible stuff.
In rough order of how fast people spot it:
- Foot sliding. The most visible mocap artifact, period. If you scaled root translation in step 2 it's already smaller; lock the planted foot across its contact frames to kill the rest.
- Clipping — hands through the torso, weapons through legs. Worse on crouch, sit, and combat poses where R15 proportions exaggerate overlap.
- Jitter. Smooth jittery joints lightly. Over-smooth and the character goes floaty, which reads as fake just as fast as jitter does.
- Warm-up / tail-off frames. Trim the solver's messy first and last few frames, then re-check your loop seam since trimming moved it.
Keep an untouched copy before you start cutting, so you can compare. The target isn't flawless mocap — it's motion that reads clearly in the actual game camera and doesn't pull the player's eye for the wrong reason.
6. Test in-game, not in the editor
This is its own step because skipping it is the single most common reason a finished animation looks great to you and broken to everyone else. The Studio editor preview uses different camera distance, lighting, scale, and zero gameplay context. Drop the animation into a real playtest, move the camera where players actually hold it, and watch it next to the other motion it'll run beside. Half the "why does this look weird" reports disappear the moment you do this.
Where this gets easy — and where it doesn't
I'll be straight about the boundary. NoCapMocap is built to erase steps 2 through 4: you describe a move (or upload a clip), get four R15 variations back, and one-click them onto a rig — no retargeting, no FBX, no manual loop/priority guesswork to get started. Here's that video-to-motion flow:
What no tool can do for you is steps 1, 5, and 6 — shooting trackable footage, the final cleanup judgment calls, and actually testing in-game. Those stay your job. Anyone who tells you a button removes all of it is selling you something.
If you want the happy-path version of the whole workflow, our guide to making Roblox animations walks through it click by click, and if you're weighing options, the best Mixamo alternatives for Roblox lays out how the tools compare. Here are a few R15 animations made with this exact flow:
The 60-second checklist
A quick recap you can run before you ship a clip:
- Footage is 1080p/60, locked camera, one person, feet in frame
- Root/hips mapped first; root translation scaled to the avatar
- Imported and confirmed on a default R15 rig before a custom one
- Loop set correctly; start/end poses match on cycles
- Priority matches intent (actions above
Movement, idles atIdle) - Foot sliding, clipping, and jitter cleaned; warm-up/tail-off trimmed
- Tested in a real playtest, not just the editor preview
FAQ
Can you actually turn any video into a Roblox animation?
Any clean clip of one person, full body in frame, performing a clear move — yes, that retargets well. Crowded shots, half-occluded limbs, or finger-level detail are where it struggles. Either way the video is the input, not the finished animation: you still have to get it onto an R15 rig and clean it up.
Why does my mocap look fine in Blender but broken on the R15 dummy?
Proportions and skeleton structure. A Roblox R15 rig has shorter, blockier limbs than a real human and collapses your whole spine into a single Waist joint, so motion that read fine on a human skeleton can twist, clip, or float once it lands on R15. Bad root mapping and unscaled hip translation are the usual culprits.
Why does the animation play in the editor but not in-game?
Most often the priority is too low and Roblox's default Animate script overrides it, or you're testing the editor preview instead of the runtime Animator:LoadAnimation() flow. A wrong AnimationId, an unpublished asset, or a missing Animator will do it too.
Do I have to deal with FBX and retargeting at all?
Only if your tool hands you a generic FBX. NoCapMocap auto-retargets every motion to R15 and imports onto a rig in one click, so the bone-mapping and import steps above mostly disappear. Recording quality and in-game cleanup are still on you, no matter the tool.
