Turbo Sequence renders skeletal crowds in Unreal with Niagara instancing

A crowd renderer that keeps the skeleton

Turbo Sequence is described as a plugin for Unreal Engine 5 which is open source with an MIT licence, and the repository description calls it a Skeletal Based GPU Crowds plugin for UE5.

The technical idea has two halves. It uses GPU Instancing with Niagara to manage draw calls efficiently, which the README calls mostly the bottleneck of traditional rendering systems. And it uses bones to animate the meshes, which allows IK and layer mask blending per bone.

The second half is the interesting one, because it is what separates this from the usual answer to the same problem. The common approach is Vertex Animation Textures, where a character's animation is baked into a texture and the GPU samples it. The README states the advantage of Turbo Sequence over VATs directly: it uses bone joint bending instead of pre-computed animations, which allows runtime bone joint bending like IK or Sockets.

So a character in a Turbo Sequence crowd can still have a hand reach for a socket, and a layer mask can still hide an arm, and those are exactly the things a baked VAT cannot do. The cost is that the animation is evaluated on the CPU, and the README says so plainly: TS is CPU bound and optimized for crowds around 10k to 50k, and if you need more units you should use VATs and or pure GPU systems.

That number is the single most useful thing in the README, because it tells you when to stop using this approach.

Draw calls per archetype instead of per instance

The README explains the rendering difference with two diagrams, and the first is the traditional model:

CPU       GPU
         |
         v
Instance 1 (Mesh data 1) -> Draw call
         |                      |
         v                      v
Instance 2 (Mesh data 2) -> Draw call
         |                      |
         v                      v
Instance N (Mesh data N) -> Draw call

The second is the GPU instancing model:

CPU       GPU
         |
         v
Base mesh data -> Draw call
                  | (all instances combined)
                  v
                  Rendered instances

One base mesh and one draw call produce all the instances, and that is the whole saving. The README frames the goal in the same terms, trying to use draw calls per archetype efficiently and not per instance, which has an advantage compared to traditional rendering methods.

The archetype word is worth pausing on, because it sets the limit. All instances in a draw call share the same base mesh data, so a crowd of humans and a crowd of orcs are two draw calls, not two thousand, but only if they share a mesh. A crowd where every character has different geometry gives up the benefit.

The feature list is a list of animation controls

The features section reads like a checklist of the things a crowd system usually cannot do.

There is playing animations, stopping animation, and getting and setting the IK transform, so you can pose a character in a crowd at run time. There is tweaking animation with speed, weight and start and end transition, which is how you vary a crowd without a separate animation asset per variant. There is support for most possible skeleton rigs without bugs, blend spaces, switching the surface material, switching the mesh, and an editor UI.

Then the parts that matter at scale. Dynamic chunked async animation loading, so a large crowd does not stall while its animations stream in. Animation layer masks per bone, which is the masking that VATs lose. Root motion, and getting the socket transform, so a character in a crowd can still attach to something. Getting animation curves, so game logic can read values out of the animation. Level of details. Multi-mesh-character animations, for a character made of several meshes. Per instance custom data. Smooth and flat normals. Two optimisation hooks, smart vertex iterations in the surface material and update groups.

There is also a Hybrid Animation Mode between the UE system and the TS system, which is the escape hatch for a project that needs some characters on the standard pipeline and some on the crowd pipeline. Rendering is offered through either Niagara or ISMC, the instanced static mesh component path.

Blueprint support is listed, which is worth reading carefully against the limits section later on, because the two say different things.

Nanite changed the argument for using it

The README is candid that the ground moved underneath this project, and it does so in a short section.

In UE 5.5 Nanite Skeletal Meshes are here, and before using Turbo Sequence, UE's own skeletal mesh system for crowds can be a good option when using Nanite. That is the project's own recommendation against itself for a whole class of use cases.

The plugin has adapted rather than disappeared. Since UE 5.7 there is a Niagara Nanite Renderer, and since Turbo Sequence 5.7 it is part of the plugin, and Nanite can be turned on in the Control Panel when building a Mesh. So the plugin now covers the case it was not built for, using the engine's own path for the geometry and the plugin's path for the animation.

For a team evaluating this today, the version matters as much as the feature set. The release tags are named after the engine version they target, with UE 5.8 published on 2026-06-23, a UE 5.7 fix on 2026-01-19 and UE 5.7 on 2025-12-26, and the last push was on 2026-06-23. The plugin tracks the engine, and a project on a different engine version needs the matching tag.

Installing means copying a plugin folder into your project

There is no package manager step here, and the quick start guide is four steps. Download Turbo Sequence, install it in your UE project in the Plugin folder, open the Feature Demo Map and press Play, and navigate to the wiki to get started with the API.

The download is engine-version specific. You go to the Releases page and download the source of your Unreal Engine version. Then you extract the release on your computer and copy the extracted root folder to the Plugin folder of your Games UE project, and the README is emphatic that this is not in the Engine. You then compile the project and open it in Unreal Engine.

That last point, compiling, is the practical cost of this plugin. You are building the C++ side of your project against it, which is consistent with the later statement that the C++ API is the one to use.

The demo content is included. Inside Unreal Engine you navigate to `..\Plugins\TurboSequence\Content\Demo` and play through the demos, and the README says there is no additional setup required. The API documentation is in `DOCS.md` in the repository, and the repository layout follows the Unreal plugin convention, with `Source/`, `Content/`, `Config/`, `Shaders/`, `Resources/` and the `TurboSequence_Lf.uplugin` descriptor at the root.

The limits and the support policy are stated in the same tone

The Limits section is short and blunt. Blueprint-only projects are not supported. A Blueprint API exists, but the README highly recommends using the C++ API because it is so much faster. Only Windows and Linux are supported, not iOS and Android or Mac. And Turbo Sequence is not built to handle metahumans, please use UE Nanite Skeletal Meshes instead.

That last one is the most consequential for a game project, since a human character with hands and a face is exactly the case the engine's own path now handles better.

The support section is equally direct. Turbo Sequence is a Hobby Project, nothing commercial behind the Repo, the Contributors are not responsible for solving bugs for users of Turbo Sequence, features may or may not come, and if you really need a specific feature you should fork the Repo and build your own system on top of it, with an optional pull request if you think it belongs upstream. If you encounter a bug, you create an issue and when the maintainer has the time, they try to respond to it.

Contributions are welcome, with the recipe: fork the Repo, create an Exp Branch, and create a Pull Request from the Exp Branch. Pull requests need to be reviewed to maintain the quality standards of the Repo in terms of runtime performance and the UE Coding Standards.

So the realistic expectation is a well documented, capable plugin with one maintainer's time behind it. That is a fine thing to build a prototype on, and a different thing to bet a shipped game on.

Editorial conclusion

Adopt Turbo Sequence when your Unreal project needs tens of thousands of animated skeletal characters and you can live with a C++ side and a Windows or Linux target. Do not adopt it for a Blueprint-only project, for iOS, Android or Mac, for human character detail, or for crowds beyond roughly fifty thousand units. Verify first that the release you download matches your Unreal Engine version, since the tags are named per engine version, that the Nanite option in the Control Panel is a deliberate choice rather than a default, and that the maintainer's stated position on bugs and features, that this is a hobby project with no guarantee of fixes, matches what your team needs from an engine plugin.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. LukasFratzl/TurboSequence on GitHub
4. README
5. Releases