Fluxa - A Custom Runtime Animation Engine for Roblox

Resources Community Resources
1

:star:Fluxa — A Custom Runtime Animation Engine for Roblox

by Brycki (@Brycki404) / X

What is Fluxa?

Fluxa is a complete runtime substitute for Roblox’s built‑in Animator and AnimationController.
Instead of relying on the limitations of Roblox’s animation system, Fluxa lets you:

  • Load KeyframeSequences directly
  • Build procedural animation logic in code
  • Create runtime blend trees
  • Implement custom state machines
  • Apply IK, retargeting, and procedural layers
  • Write directly to Motor6D.Transform, Bone.Transform, and AnimationConstraint.Transform
  • Build animation systems similar to Unreal Animation Blueprints or Unity Playables

:warning:This tool does not alter the process of animating at all.

Fluxa is designed for scripters who want full control over animation behavior at runtime — something Roblox’s built‑in Animator does not provide.

I originally built this because I needed a workflow like this for my own projects, and I’m releasing it for anyone who wants the same level of control.

:warning:Project Status Notice

Fluxa is currently in active development, and the API, structure, and features are subject to change as the library evolves.
Full documentation will be added here once the API stabilizes.
For now, you can explore the included demo place to learn the basics.
Additional examples will be added for every feature in future updates.

Clips of Demos 1, 2, and 3

The example 1 demo showcases an R6 procedural 5‑way locomotion blend tree, blending between animations based on relative movement direction.
Medal Clip

The example 2 demo showcases an R15 procedural momentum-based blend tree between, blending between 3 movement animations mixed with a jump, fall, and landing animation set.
Medal Clip

The example 3 demo builds upon example 2, showcasing the packaged FluxaController, AnimationLayers, and the Network Replication of Animations via the packaged FluxaReplicationService.
Medal Clip

These are just some of the basic examples of what Fluxa can do — the system is designed to support far more advanced animation logic.

:star:Getting Started

GitHub repository

For Rojo + Wally users
Add the latest version to your wally.toml from here Wally

For Studio users
(fluxa-dev uncopylocked) Fluxa Dev | Play on Roblox

:star:Is Fluxa redundant now that Roblox has an Animation Graph Editor?

No — and here’s why.
Roblox’s new Animation Graph System (currently in beta) is a visual authoring tool.
It lets animators build graphs inside an Animation asset, similar to Unity’s Animator Controller.
But it is not a runtime animation engine.

Roblox’s Animation Graph System:

  • Runs inside the Animator
  • Cannot be modified at runtime
  • Cannot generate graphs procedurally
  • Cannot blend multiple graphs together
  • Cannot perform IK or retargeting
  • Cannot override Motor6D, Bone, and AnimationConstraint transforms
  • Cannot replace the Animator
  • Only exposes parameter updates, not graph control

Fluxa:

  • Runs outside the Animator
  • Fully scriptable
  • Fully runtime‑driven
  • Supports procedural animation
  • Supports custom IK and retargeting solvers
  • Supports custom blend trees
  • Supports runtime state machines
  • Writes directly to Motor6D.Transform, Bone.Transform, and AnimationConstraint.Transform properties
  • Lets you build animation logic in pure code

In short:

Roblox’s Graph Editor = visual authoring tool for animators
Fluxa = runtime animation engine for programmers

They solve different problems and complement each other rather than overlap.

19 Likes
2

This seems redundant compared to the animation graph editor that was released, what’s the use case for this compared to that? Also can these be baked into keyframes?

1 Like
3

Apologies if the post wasn’t very clear. I have just updated it to hopefully answer your questions. I appreciate you pointing out what was lacking in the original post.

5

Just released a video for you guys to share around! This should save you from reading a lot, it’s just a bit over 10 minutes, and is an easy watch. I’d greatly appreciate it if we could get the ball rolling with Fluxa and start garnering a user base. I really want to see some cool projects made with this and some community contributions would be awesome to see too!
Fluxa YouTube Tutorial / Showcase

6

Example 5 is complete. A lot of improvements have been made. Fluxa Example 5 - Clipped Roblox with Medal.tv
Just some notable changes:

  • Better integration with Roblox’s task scheduler using RunService.Stepped. You can now keep your Humanoid.Animator and AnimationController instances (only for workspace.SignalBehavior == “Immediate”), which means we can use IKControl instances on top of Fluxa (as seen with my ServerOwned but completely Local Animated NPC in example 5).
  • LocalOnly, ClientOwned, and ServerOwned FluxaControllers. This is for total control over how you decide you want to make and replicate NPCs.
  • A lot more per-track options when it comes to animation time position syncing, replication decisions, and much more.
  • Binding Catalogs for swapping animations out on the fly and Set Managers to do swap out entire sets of Animations. This is for equipping weapons, stances, etc. when you want to swap out animations that already exist like your walk cycle or idle animation.
7

Looks interesting and will have a play test on the uncopylocked demo tomorrow hopefully. Just an initial question without diving in fully, does this need to have the scripted animation be preloaded like normal animations?

*Getting a 505 Internal Server Error when trying to look at the documentation.

1 Like
8

Great question. Fluxa doesn’t require “preloading” in the Roblox Animator sense. What Fluxa needs is the KeyframeSequence so it can convert it into an internal AnimationAsset.

Once Fluxa has built the asset, you can store it wherever you want (usually in a module or an internal FluxaAssetManager), and the original KeyframeSequence instance can be removed since you don’t need it anymore.

If you’re comparing it to Animator:LoadAnimation(): Fluxa has a similar concept for tracking active animation tracks, but it doesn’t have the 256‑track limit and you can unload animations cleanly.

So: yes, the KeyframeSequence must exist long enough for Fluxa to read it, but no, Fluxa doesn’t rely on Roblox’s preload system. So you don’t need to do something like this:

ContentProvider:PreloadAsync({"rbxassetid://123456789"})

In practice, loading animations in Fluxa looks like one of two ways:
Method 1
You have a KeyframeSequence sitting on the server in someplace like game.ReplicatedStorage, then for each client you load them into an AnimationAsset and destroy the KeyframeSequence instances sitting in that storage place for that Client. Note, don’t destroy them on the server in this method, you still need them there or else they don’t replicate to new clients.

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local keyframeSequence = ReplicatedStorage.KeyframeSequence1
local asset = Fluxa.AnimationAsset.new(keyframeSequence, "UNIQUE_IDENTIFIER")
keyframeSequence:Destroy()

Method 2.
You load the KeyframeSequence with something like this:

local KeyframeSequenceProvider = game:GetService("KeyframeSequenceProvider")
local success, keyframeSequence = pcall(KeyframeSequenceProvider, KeyframeSequenceProvider.GetKeyframeSequenceAsync, "rbxassetid://123456789")
if success then
    local asset = Fluxa.AnimationAsset.new(keyframeSequence, "UNIQUE_IDENTIFIER")
    keyframeSequence:Destroy()
end

Both methods 1 and 2 can be done with the FluxaAssetManager class that wraps all the ways of loading up for you. I suggest starting out by looking at the source code for Example 1 and slowly working you way up to Example 5’s complexity. Example 4 and 5 both look drastically different from 1-3 since they introduce the usage of a FluxaAssetManager and FluxaBindingSetManager together for the capability of replacing animations on the fly in animation sets. So, for example, you could equip a weapon that changes some, if not all, of your character’s animations. I unfortunately don’t have an example of just the FluxaAssetManager without the FluxaBindingSetManager, but you can totally get away with that.

Also thanks for letting me know that the Gitbook Documentation was down. Not even Gitbook notified me that my 14 day free trial ran out. Needless to say, I had to go back to only having 1 site online instead of 2. :sob:

1 Like
9

Looks interesting. Have you considered looking into CFrame animation support also? e.g. considering a rig that has no joints, will there be a way to load CFrame data into the animator, or does that require the rig to have joints for manipulation (Maybe it’s an FPS)

10

Is it stable enough to be used in production?

11

CFrame animation definitely has its uses, but it’s solving a different problem than what Fluxa is targeting.

If a model doesn’t have joints, I’m not sure it really qualifies as a rig. You need some kind of transform hierarchy for blending, IK, retargeting, or even basic layered animation. For FPS viewmodels specifically, there’s no downside to adding Motor6Ds, Bones, or AnimationConstraints. Once those are in place, you get proper hierarchical local-space transforms for free.

At that point, raw CFrame animation becomes mostly redundant. Roblox’s KeyframeSequence pipeline is just vastly superior:

  • Named keyframes make it easy to reference specific poses
  • Markers/Events let you embed gameplay‑relevant triggers directly in the animation
  • Parameter values on markers give you structured data instead of hard‑coded timing hacks

None of that exists in a pure CFrame dump. You lose blending, you lose events, and you lose any ability to integrate with an animation graph.

If someone really wants to animate a completely jointless model, that’s basically just manually applying world-space CFrames to parts every frame, which is outside the scope of an animation rig and doesn’t play well with any modern animation features, let alone replication.

So the short version: yes, you could load CFrame data (not with Fluxa), but rigs with actual joints + KeyframeSequences are almost always the better path, even for FPS setups.

12

Short answer: it’s usable in production, but I wouldn’t call it “frozen and finalized” yet.

The API is still evolving as I refine the workflow and add features. Network replication in particular isn’t fully optimized. With higher player counts you can see recv bandwidth spike. Send bandwidth is sitting between 10-20 kb/s from where I last left the replication layer.

That doesn’t sound right to me since right now I don’t replicate raw transform CFrames. Instead, I replicate driver changes (the parameters that actually produce the animation). Each client takes those driver values and recomputes the exact same pose locally. It should be more deterministic, lightweight, and avoids shipping full pose data every frame. Yet it’s still 20 kb/s. so I’m not quite sure where I might’ve missed an optimization.

Long‑term, I’m hoping my Engine Request gets traction so we can eliminate the need for custom replication on rigs entirely and let the engine handle animation state sync natively, ultimately removing the need for Remotes with Fluxa.

Fluxa is being used in real projects. I’m using it myself, and there’s already a really cool paintball game that someone else is building on top of it. So, while it’s not “production‑ready” in the sense of being locked‑down and API‑stable, it’s absolutely capable of shipping a game today. It’s open‑source, constantly improving, and easy to fork or extend if someone needs something specific.

So the realistic answer: it’s stable enough to build with, but still evolving, and that’s by design.

13

Before the animation graphs I would have jumped on the occasion but now?
I don’t even know if it’s of much use…
Don’t think I’m saying that this ressource is bad the opposite actually just that for once Roblox actually did their job and made this (kind of) obsolete.

14

And that’s only from my POV if I’m wrong feel free to correct me.

15

The Animation Graph system is a great high‑level orchestration tool, but it doesn’t address runtime procedural animation, IK layering, or dynamic graph modification.

Games with complex animation sets like multiple weapons, stances, locomotion variants, or procedural layers cannot rely on a static, pre‑compiled graph.

What’s missing is a runtime pose API and more procedural passes in the animation pipeline.

Fluxa demonstrates the need for:
• Animator:ApplyPose() (something that flushes a final pose and replicates it)
• A procedural layer after Animators and before IKControls (a signal like RunService.PostAnimation)
• A second procedural pass after IKControls (a signal like RunService.PostIK)
• Runtime graph editing or subgraph injection

These features would allow developers to combine the strengths of Animation Graphs with procedural animation systems, enabling far more advanced character animation than is currently possible.

In a way, with Fluxa I’m trying to influence what Roblox needs to implement to make a AAA engine Animation pipeline. I believe Roblox is in a very unique situation to do much more than Unity or Unreal with this. Even in those engines, they are behind in many categories like IK layering and procedural stuff where most people have to make their own IK frameworks to work alongside those Animation systems. Whereas with Roblox, right now there’s not enough yet to even be able to work alongside the animation system. That’s what I’m ultimately trying to achieve. A system that looks like:

  • Animator → Fluxa → IKControl → Fluxa → Natively Replicate Final Poses

Imagine the powerful pose modifications that something like that could provide.

Currently we just have:

  • Animator → IKControl → Native Replication

With Fluxa currently you have:

  • Animator → IKControl → Fluxa → Custom Replication
  • Animator → Fluxa → IKControl → Custom Replication
    • only in workspace.SignalBehavior == “Immediate”
  • Fluxa → Custom Replication
    • with no Animators or IKControls

All of the current Fluxa methods require custom replication though, which isn’t ideal, but that won’t stop me from trying to further progress the Roblox animation pipeline.

2 Likes
17

Been having a play with this and absolutely love it. I am currently building a climb tower game and this more likely will be used.

Quick question, would it be possible to add in leg/foot IK on the R15 model example? This is the last missing piece on my opinion to make this perfect - just the legs/feet. Basically similar to the few R15 IK foot placement assets on this forum.

*Based on the documentation, this look’s relatively possible based on the IKControl that Fluxa uses.

1 Like