For those who don’t know the tool: Cascadeur by Nekki is a standalone 3D character animation DCC focused on physics-assisted keyframe animation, AutoPosing and AI Inbetweening. It supports FBX and USD pipelines into engines such as Unity and Unreal Engine, and began life as an internal game tool.

Alexander Grishanin is a software engineer and CTO of Cascadeur. With a background in applied mathematics and real-time systems, he focuses on combining classical physics simulation, machine learning, and intuitive animation workflows into a cohesive production tool.

He joined Nekki in 2014 as a game developer, contributing to character animation systems for titles such as the Shadow Fight series. Today, together with Cascadeur’s original creator, Eugene Dyabin, he shapes the software’s technical vision, focusing on lowering the barrier to entry for 3D animation while preserving precise artistic control.

Cascadeur Today

DP: What was the very first problem you wanted Cascadeur to solve?

Alexander Grishanin: To put this into context, it helps to know that Nekki originally started more than 20 years ago as a game development studio. Animation was always a core production topic for us, not a theoretical exercise. We were building real games under real-life conditions.

The original idea for Cascadeur came from one of Nekki’s co-founders, Eugene Dyabin. Eugene has always been interested in animation, but approached it from a very technical perspective. What bothered him early on was that established tools like Maya, while extremely sophisticated, were almost completely disconnected from physics. For someone with a technical background, that felt like a fundamental mismatch, because character animation, beyond its artistic dimension, is strongly influenced by physical principles such as balance, weight and momentum.

At that time, Nekki was producing fighting and parkour games such as Shadow Fight and Vector. To generate large volumes of believable motion for those games, Cascadeur began as an internal tool. Initially, it was a relatively simple animation editor that relied on physics-based calculations to help animators manage balance, weight, and momentum more intuitively, rather than constantly tweaking animation curves.

What began as a small internal project gradually evolved as we added the tools we needed in production. For a long time, the idea was simply to use Cascadeur inside our own studio. But as the tool matured and proved itself in real projects, it became clear that it could be useful far beyond Nekki,  which eventually led to the decision to turn Cascadeur into a standalone product in 2019.

DP: And, when we look at the current version of Cascadeur, has that problem been solved? 

Alexander Grishanin: Largely, yes. But it was definitely not a single step; it was a long evolution. In its early days, Cascadeur was far from being a full-featured 3D animation tool. It used a very specific internal format and was tightly coupled to our own production setup.

Over time, especially with the rise of Unity and Unreal Engine, it became clear that Cascadeur had to integrate seamlessly into standard pipelines. A key part of “solving the problem” was turning it into a proper 3D editor: supporting skeletal animation as used in game engines and enabling reliable import and export via common formats such as FBX and USD. From a pipeline perspective, that part is largely solved today.

On the physics side, the journey was just as long. Initially, we worked with very explicit physics concepts: centre of mass, force vectors, and angular momentum visualisations. We even built detailed visual tools showing forces and reaction forces. Technically, that worked well, but we quickly realised that this approach had a very high entry barrier. While powerful, it required animators to think in highly abstract physical terms, which was intimidating for many artists.

That insight led to a fundamental shift in approach. Instead of asking animators to understand physics, we focused on letting the software demonstrate it. This resulted in what we now call the Physical Assistant (aka “Green ghost”): essentially a physically accurate version of the character that moves alongside the animator’s animation and shows how the motion would look if it fully respected physical laws. It’s generated automatically and acts as a continuous reference rather than a diagnostic tool.

At this point, we’re quite happy with where we landed. There’s still room for refinement and more automation, but in terms of making physics-based reasoning practical and usable in everyday animation work, the original problem is largely solved.

DP: One of Cascadeur’s party tricks is simplifying any Biped Rig, and making it usable for animation – how does it decide what parts of an imported rig should be simplified?

Alexander Grishanin: To be honest, there is no fully automatic “magic” that analyses an imported rig and decides which bones are essential and which are not. At least not at the moment. Our approach is actually quite pragmatic.

When you import a character into Cascadeur, it can indeed come with hundreds of bones: helper bones, controllers, deformation chains, design-driven additions – all the things riggers love. But for physically plausible biped animation, only a well-defined subset of those bones is actually relevant. Beyond areas like the spine, which often needs more detail, the structure required for body mechanics is fairly consistent.

So what Cascadeur does is this: the user selects the bones that the internal Cascadeur rig should work with. This can be done either via presets, which we created for common rig types or manually in the rigging tool. The generated Cascadeur rig then controls only this selected subset, while the rest of the bones follow through skinning or constraints.

This is very similar to how quick rigging or humanoid setup works in game engines. Once the system knows which bone represents the pelvis, the feet, the hands, and so on, a lot of things become much easier, including physics-based tools and retargeting between characters. So rather than automatically “simplifying” rigs in a black-box way, Cascadeur relies on a clear, explicit mapping. That gives us predictability and compatibility with existing production pipelines.

When is a joint really a joint?

DP: How does the system identify what counts as a joint?

Alexander Grishanin: This is handled in essentially the same way as rig simplification. If the system recognises a known rig, a preset can be loaded that defines the joints. Otherwise, joint identification is done manually during the rig setup.

Currently, Cascadeur does not automatically analyse an arbitrary hierarchy to determine what counts as a joint. We rely on explicit user input rather than automated heuristics. More automated approaches may be possible in the future, but currently the process is intentionally straightforward and transparent.

DP: How does Cascadeur separate intentional mocap motion from noise?

Alexander Grishanin: At the moment, Cascadeur does not have a specialized system that automatically distinguishes intentional mocap performance from noise. Mocap cleanup is not the core focus of the software. Cascadeur is primarily designed for creating animation from scratch, but we do provide tools that make working with mocap data practical.

Our main approach in this regard is the so-called Unbaking workflow. You can import a baked mocap animation and unbake it, which converts the motion into a reduced set of keyframes and interpolations while preserving the original movement as much as possible. This makes the animation much easier to edit and clean manually. Smaller jitters can be reduced through Unbaking precision settings, but larger artifacts will still be preserved and need manual correction.

In practice, this works well because most modern mocap systems already perform significant jitter reduction in their own software before the data reaches Cascadeur. On our side, we focus on making the resulting animation editable, readable, and controllable. Additional tools, such as automatic foot contact handling and upcoming collision-penetration fixes, help improve the overall cleanup process, but we don’t currently attempt to automatically distinguish artistic intent from noise.

Version 2025.3

Cascadeur 2025.3: Inbetweening De Luxe

DP: Having that in mind: How challenging was the transition from bipeds to quadrupeds? And does AutoPosing behave differently for quadrupeds?

Alexander Grishanin: The challenging part was not so much the core technology, but standardization. The underlying rigging system in Cascadeur (the part that generates IK/FK rigs)  is actually not tied to bipeds at all. You can rig pretty much anything with it, and our users have been doing that for years, including complex robots or non-humanoid characters.

What was new with quadrupeds in version 2025.3 was turning this flexibility into a standardized, production-ready workflow. That meant defining a clear IK/FK rig structure for quadrupeds and extending the rigging and “cooking” tools so users don’t have to build everything manually anymore.

AutoPosing was the second major piece, and here the behavior is indeed different. Quadrupeds have fundamentally different anatomy: more complex spines, different roles for front and hind legs, and different balance logic. So AutoPosing for quadrupeds is not a simple extension of the biped system – it’s a separate solution built on top of the same foundations, but with different assumptions.

From a system perspective, nothing really broke, but we had to add new logic and support layers to make quadrupeds feel natural to work with. We’ve already improved this significantly in recent updates, and there’s more coming in the next major release 2026.1. Retargeting for quadrupeds is now supported as well.

One thing we don’t yet have for quadrupeds is in-between pose generation at the same level as for bipeds. That requires a much larger and more specific dataset, and we’re currently exploring ways to obtain that. The transition is well underway but not yet complete.

DP: How does AutoPosing decide which constraints to prioritise between keyframes?

Alexander Grishanin: There’s a small clarification needed here: AutoPosing itself does not operate between keyframes. It is a tool used on a keyframe to generate or adjust a pose.

Our Inbetweening system is a separate mechanism. It generates motion between keyframes based on the keyframe poses, their timing, and optionally the tangents defined at the start and end keys. At the moment, it does not evaluate or prioritise constraints in the traditional sense. The keyframes themselves, and their timing, are the constraints.

When connecting two animation segments, the system interpolates between the defined poses, respecting timing and tangents rather than resolving competing constraints. More advanced constraint-aware Inbetweening is something we may explore in the future, but it’s not how the system works today.

DP: How does retargeting interact with locked joints or pinned positions?

Alexander Grishanin: Retargeting in Cascadeur does not explicitly take joint locks or pinned positions into account. What we focus on instead are fulcrum points – points of contact that should retain their global position, such as feet on the ground. These are detected and preserved during retargeting.

Technically, retargeting operates at the joint or IK-rig level, but it does not account for existing constraints or joint locks. Constraints exist in Cascadeur, but the retargeting system itself does not account for them.

In practice, this keeps the behaviour predictable. For example, when weapons or props are involved, they are usually switched to FK and remain in place, rather than being dynamically resolved during retargeting. More advanced constraint-aware retargeting would require significantly more context and assumptions, and at the moment, we don’t try to make it work “magically.”

DP: Cascadeur now understands complex collisions and “stuff in the scene” How far can Cascadeur go with understanding objects and full environments?

Alexander Grishanin: At the moment, Cascadeur handles environments in a fairly pragmatic way. The system automatically recognises the ground plane, and any additional objects in the scene can be treated as environment elements – as long as they have colliders assigned to them. Once that is set up, characters can interact with those objects, for example, by walking on them or making physical contact.

Most of our physics-based tools already account for these environment colliders. We support different types of collision behaviour, such as pinned or surface-based collisions, which allow for reasonably complex interactions with scene geometry.

The current limitations are higher-level automation. AutoPosing and Inbetweening do not yet consider environment colliders when generating poses or motion. We plan to improve this in the future, but it’s a complex problem, and we don’t want to overpromise on timelines.

DP: And within a scene, the movement is either interpolated from Keyframe to Keyframe, or inbetween-ed along a vector, curve or trajectory? 

Alexander Grishanin: In Cascadeur, animation is fundamentally built around keyframes. Between those keyframes, we support several types of interpolation. Most of them are fairly standard: linear, Bézier-based interpolation. Quite similar to what you find in other 3D animation tools.

One notable difference is on the rig side: we rely heavily on spherical interpolation. This gives us greater control over rotation continuity and tangents while avoiding issues such as gimbal lock. Compared to quaternion interpolation, it offers more predictable behaviour when animators want to art-direct motion using curves and timing.

Inbetweening is a separate mechanism. It uses AI to generate motion between keyframes, but it does not currently follow curves, trajectories, or environmental context. Its constraints are the poses, timing, and optionally the tangents defined at the surrounding keyframes. Artistic control still comes primarily from how those keyframes are set up.

We are exploring more advanced systems in the future. For example, root-motion-based generation that could follow a trajectory or directional intent. But that would not be traditional interpolation. It would be more of a generation step, where you define intent and let the system propose motion.

So even as locomotion and motion flows become more complex, the core idea remains the same: keyframes define intent, interpolation and Inbetweening assist – but art direction always stays with the animator.

DP: And how does Cascadeur switch between interpolation and Inbetweening? 

Alexander Grishanin: It’s entirely a choice made by the animator. There is no automatic switching. In earlier Cascadeur versions, Inbetweening was a separate operation: you selected a time interval, triggered the tool, and it generated a baked animation for that section.

In version 2025.3, this changed. Inbetweening is now implemented as a type of interpolation. That means the animator explicitly chooses, per segment, whether motion between keyframes should use a traditional interpolation method or Inbetweening. From a workflow perspective, this makes the system much more coherent and predictable.

One of the main challenges with this change was ensuring smooth transitions between different interpolation types. We added mechanisms to blend and smooth those transitions, so switching between standard interpolation and Inbetweening doesn’t introduce visual discontinuities. So the logic is simple: the animator decides what works best for a given situation, and the system focuses on making that choice behave consistently and smoothly.

How about Ragdolls?

Alexander Grishanin: Yes. But it’s important to clarify how physics and ragdoll simulation work in Cascadeur. Ragdoll is a type of physical simulation that operates on the resulting animation, not on the process that created it.

From the physics system’s point of view, it doesn’t matter whether an animation was created using standard interpolation, Inbetweening, imported mocap, or even a fully baked clip from a library. All interpolation and Inbetweening are evaluated first. Physics, including ragdoll, then uses the final animation frames as input and simulates from that point.

Once you activate ragdoll, the simulation will typically override the animation quite significantly. For example, when a character starts to fall. There is no tight coupling among interpolation, in-Betweening, and ragdoll logic. Physics simply “consumes” the finished motion and reacts to it.

In that sense, both interpolation and Inbetweening are fully compatible with ragdoll features – because physics doesn’t care how the motion was authored, only what the motion is at the moment the simulation starts.

DP: When we look at “AI-assisted Inbetweening”, wouldn’t the next step be to get additional data from a scene? 

Alexander Grishanin: That kind of scene-level, event-driven Inbetweening is far beyond what we are aiming for in the near future. Conceptually, it is interesting to use full-scene context, simulations, particles, or semantic events to influence animation behaviour, but this quickly becomes a very different class of system.

Right now, our focus is much more grounded. We aim to improve the quality, robustness, and controllability of AI-assisted Inbetweening, based on animation data and clearly defined inputs such as poses, timing, and physical plausibility. Adding higher-level scene understanding would significantly increase complexity and assumptions.

Ideas like text-driven reactions to explosions or environmental cues are intriguing, but they are not where Cascadeur is heading in the foreseeable future. Our priority is to make AI a reliable assistant within a traditional animation workflow, not a system that attempts to interpret entire scenes or narratives.

DP: With more interpolation tools added, how do you keep the timeline clean?

Alexander Grishanin: There isn’t a strict formal rule behind this. In practice, we test ourselves and carefully determine what should appear directly on the timeline and what can be placed in menus or settings. The goal is to keep the timeline readable, even as more interpolation options are added.

Unbaking is a good example of where this balance is not perfect. It can introduce quite a lot of keys and visual noise on the timeline. We’re aware of this, though in practice it hasn’t become a major usability issue yet.

In the long term, we would like to hide more of this complexity. Ideally, animators wouldn’t have to think in terms of linear versus Bézier versus IK or Inbetweening at all. You would define intent, and the system would choose the appropriate interpolation under the hood. That said, this is more of a direction or a vision than a concrete feature on the roadmap. By the way, if you want to know what we are working on right now, our Roadmap is public, and you can have a look here: https://trello.com/b/oNlIizJh/cascadeur-roadmap

DP: How big can an unbaked animation get before performance drops?

Alexander Grishanin: In practice, extremely long unbaked animations are more of a theoretical stress test than a real production scenario. We have users working with animations of up to 10,000 frames, and that is definitely possible. In version 2025.3, we added another round of optimisations specifically to improve performance with long timelines.

That said, usability becomes the limiting factor much earlier than raw performance. Working meaningfully with 10,000 frames is already very difficult, simply because it becomes hard to understand what is happening where. Most animation work happens in much smaller ranges, typically a few hundred frames at a time.

Cascadeur is optimised around that typical use case. When you focus on a limited time interval, for example, 300 to 500 frames, the system only evaluates and updates what is needed for that interval. The total length of the animation outside that range has very little impact on interactivity. That’s exactly what we improved further in 2025.3.

So yes, unbaked animations with 10,000 frames are feasible today. Beyond that, you’re likely to hit practical and conceptual limits before you hit hard technical ones. A 200,000-frame animation, for example, is far outside what we would consider a realistic working scenario.

AI in Animation

DP: Of course, in 2026 Cascadeur has AI-tools. What training data did the new Machine Learning tools rely on?

Alexander Grishanin: Our machine learning tools are primarily trained on data we own and understand very well. A large part of it comes from animation data created over many years for Nekki’s own games, especially the Shadow Fight action game series. That includes a substantial amount of hand-crafted animation and poses produced by Nekki’s animators.

In addition, we generate our own motion-capture data. We use two Xsens motion-capture suits internally and record motion data exclusively for training and validation. This allows us to create clean, well-defined datasets that align with the motion Cascadeur is designed to handle. So the foundation is a combination of long-term in-house animation data and dedicated mocap recordings, rather than external datasets.

DP: Do the new AI features change the minimum system requirements?

Alexander Grishanin: No, the new AI features do not change the minimum system requirements. At the moment, our AI-related computations run entirely on the CPU and are comparable in complexity to existing systems such as physics tools or interpolation.

We don’t rely on the GPU for AI processing, and all calculations are performed locally. Nothing is sent to the cloud. From the user’s perspective, AI in Cascadeur behaves like any other internal tool in terms of performance and system requirements.

DP: Wait, you said that all computation is done locally. None of it relies on the cloud?

Alexander Grishanin: Yes, Cascadeur runs completely on the client system. None of the AI features rely on the cloud. The neural networks we use are intentionally very lean. AutoPosing is quite small, and Inbetweening is a bit larger, but still nowhere near the scale of large models that require massive amounts of memory or external infrastructure. Because of that, all computation can happen locally without any special hardware or online connection.

DP: How do you balance classical physics with machine learning inside Cascadeur?

Alexander Grishanin: At the moment, classical physics and machine learning in Cascadeur are clearly separated and complement each other rather than competing. We don’t use AI inside the physics tools themselves. Physics is based on classical methods, mainly nonlinear equation optimisation, and operates on top of the animation that already exists in the scene.

Machine learning comes into play earlier. AI is used to help generate or refine animation, especially in cases where creating complex motion manually would be difficult or time-consuming. Physics tools then take that result and propose a physically correct version of the motion, for example, by improving balance or contact behaviour.

Over time, we realised that physics alone, while extremely valuable, cannot solve everything. An animation can be physically correct and still look wrong from an animation or artistic perspective. Contact situations are a good example: even with correct fulcrum points, physics does not necessarily enforce all the constraints needed to make motion look convincing.

This is where AI helps. It can generate complex, plausible motion that would be difficult to achieve solely through physics-based constraints. At the same time, AI is not particularly good at physics on its own. In practice, they work very well together: AI supports motion generation and plausibility, while physics supports correctness and grounding.

DP: How did you train the Inbetweening model, and what can artists tweak?

Alexander Grishanin: Our Inbetweening model is trained on our own animation data, basically to learn how it should behave in real production scenarios. We’re not trying to teach it some abstract idea of motion, but very concrete situations: how to move from one pose to another in a way that feels plausible for character animation.

For artists, the main controls are still very familiar ones. Poses and timing matter the most, by far. If you change the key poses or the spacing between them, the result changes immediately. That’s where most of the artistic control lies.

In Cascadeur there is also the option to add simple labels, for example saying “this should be a walk” rather than a run. That helps in cases where the same poses can be interpreted differently. Right now, those labels have less influence than poses and timing, but we’re actively looking at making them more meaningful.

Even though AI is involved, the idea is that animators remain in charge. You don’t tweak neural network parameters. You animate, and the AI adapts to what you’re telling it through poses and timing.

DP: Considering the plethora of “Animation Libraries”, which, like the Stock Photo Libraries of ancient times (Or, 2019), have a giant, very specific set of premade animations: Is that necessary when Inbetweening is available in Cascadeur? 

Alexander Grishanin: Animation libraries are still very relevant. Inbetweening and Unbaking solve different problems, and they don’t make libraries obsolete. At least not today.

Our Unbaking works very well with ready-made animations, including clips from animation libraries. You can import them, unbake them, and then edit or adapt them much more easily. Inbetweening, on the other hand, creates new motion between poses. It works best for relatively simple or well-defined movements. When animations become very complex, it’s often hard to describe them purely through poses, and in those cases libraries are still the more practical option.

Right now, Inbetweening doesn’t replace animation libraries; it complements them. That said, it does point in an interesting direction. In the future, if you combine Inbetweening with tools such as text-to-motion or more advanced motion generation, libraries could become less central. At that point, searching a library by keywords might be replaced by simply describing the motion you want and letting the system generate it.

But we’re not there yet. Today, animation libraries, Unbaking, and Inbetweening all have their place. Inbetweening is mainly about assembling and refining motion, not about replacing large collections of finished animations.

The future

DP: With the improved viewport, do you see a future where artists animate directly in final-quality scenes?

Alexander Grishanin: Yes, definitely. That’s very much the direction we’re moving in. The improved viewport is an important step toward allowing animators to work much closer to final-quality visuals while they animate.

That’s also why we invested in a more advanced renderer. With Cascadeur 2026.1 we will completely shift to Filament, a physically based rendering system originally developed by Google. The idea is not to replace final offline rendering, but to give animators a visual result that is much closer to what they’ll see at the end, while they’re still working on motion.

Looking further ahead, there are a couple of possible paths. One is tighter integration with high-end rendering systems or real-time engines. Another is using AI-based upscaling or enhancement, where you work with a simpler representation and let the system automatically improve visual quality. It’s hard to predict exactly which direction will dominate.

What we are already actively working on, though, is better live connectivity. For example, we’re improving live links between Cascadeur and other software, including Unreal Engine. That’s a concrete step toward workflows where animation occurs in Cascadeur, allowing artists to immediately see the result in a final or near-final environment. So yes, animating directly in scenes that feel close to final quality is absolutely something we believe in – whether that happens inside Cascadeur itself or through tight integration with other tools.

DP: What does an ideal animation workflow look like to you?

Alexander Grishanin: Looking ahead, I think the biggest room for improvement comes from how input works. In an ideal world, an animator can use many different types of input: posing with controllers, of course, but also video references, maybe voice input, maybe text prompts. The key point is that all of this input produces a single, fully editable output. Nothing should become a black box.

In my “dream pipeline,” you can bring in any reference you want, create motion quickly with minimal input, and then dive into any part of the animation and refine it manually if needed. Whether that input comes from controllers, video, or text is secondary. What matters is that everything remains controllable.

DP: How do you imagine animation pipelines in 2030 or 2040? And what do you imagine Cascadeur will look like in the year 2050?

Alexander Grishanin: If we look ten, twenty or even twenty-five years ahead, I think the most honest answer is that a lot is still open. Not everything depends on animation tools like Cascadeur. We’re in a phase right now where content creation is changing very quickly, and it’s hard to draw clean lines that far into the future.

What’s very clear already is that 2D image and video generation is moving extremely fast with AI. One reason is that it’s much easier to collect data on it. 3D is lagging behind at the moment, but it’s definitely catching up. We’re seeing more tools that can automatically generate meshes, skeletons, and even basic animation. But as soon as you want to actually use those assets in a meaningful way, you still need a proper animation tool to refine and control motion. That’s where Cascadeur fits in.

On a more personal note, I believe 3D will become increasingly important over the long term. Even many 2D AI systems seem to rely on some internal 3D understanding of the world. Making that structure explicit, with meshes, joints and motion, is simply a more consistent way to build believable worlds. AI can help a lot here by lowering the barrier to entry.

If we push this idea further, I hope we end up in a world where creating 3D worlds and animated stories becomes as easy as writing text or drawing images today. Right now, far more people can paint, write or make music than create something in 3D, simply because 3D is still very complex. If that complexity goes away, content creation could change dramatically.

That would also affect who creates stories. Instead of a few large studios targeting large audiences, we might see many more creators building highly specific worlds for smaller communities. Animation and 3D would no longer be just about large productions, but also about personal expression, much like photography or music today.

At the same time, I can imagine tools for generating worlds, environments, or even basic scene setups becoming more integrated into animation workflows. Whether those systems live inside Cascadeur or connect to it seamlessly is an open question. What matters is that, once a world or scene is generated, you can step in and precisely shape how characters move and behave inside it.

The post Cascadeur on physics, AI and control first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Kangaroo Builder is a character rigging toolkit for Autodesk Maya used to build body and facial rigs, manage skinning and author blendshapes. It sits squarely in character TD land and complements Maya’s rigging tools without pretending to replace them. It is developed by Thomas Bittner and integrates directly into Maya-based pipelines.

A familiar problem, now inside the rig

Transferring facial blendshapes between meshes with different topologies remains one of the more time-consuming and error-prone tasks in character production. It usually appears late in the process, just when schedules are already tight. Artists either rebuild shapes by hand, rely on wrap-based deformation tools, or accept compromises in deformation quality. Kangaroo Builder’s latest update introduces a feature explicitly designed to address this gap from inside the rigging toolset itself.

Kangaroo Builder now includes a new topology transfer workflow called “Landmark Warp”. The tool is included in version 5.19 and later and is designed to warp one mesh onto another using user-defined landmarks, even when the two meshes have different vertex counts and edge flow. This is not a general retopology solution, nor is it presented as one.

What Landmark Warp actually does

Landmark Warp works by letting users place corresponding markers on a source mesh and a target mesh. These markers define spatial relationships rather than relying on shared topology. Once enough landmarks are placed, the system computes a deformation that warps the source mesh to match the target mesh’s overall shape. The warped result can then be used to transfer existing facial blendshapes via Kangaroo Builder’s Shape Editor.

The key point is that this process operates on shape deformation rather than topology matching. The meshes do not need identical structure, only a reasonably comparable form. This makes the tool applicable to character variants, cleaned-up scan data, or iterative design changes where topology has drifted but proportions remain recognisable.

The developer notes that Landmark Warp relies on SciPy, a Python scientific computing library, which must be installed and accessible in Maya’s Python environment. This dependency is documented but may be overlooked in locked-down studio setups, which is worth flagging early in any evaluation.

Intended use, and what it is not

Nobody would describe Landmark Warp as a fully automatic solution. The quality of the result depends heavily on landmark placement and mesh preparation. Internal geometry such as teeth, tongues, or inner mouth surfaces can interfere with the warp unless managed carefully. This is stated explicitly in the documentation.

It is also not intended to replace dedicated wrap deformers or offline retargeting tools. Instead, the value proposition is convenience and context. Landmark Warp lives inside the same environment used to build and edit the rig. For many teams, that maybe matters more than absolute automation.

Why this matters in production

Topology drift is a fact of life in character production. Directors ask for changes. Scans get cleaned. Game and film assets diverge. Facial rigs, however, tend to be built once and guarded carefully. Any tool that reduces the cost of reusing that work deserves attention.

By embedding topology transfer directly into a rigging toolkit, Kangaroo is addressing a real and persistent problem. The approach is conservative rather than flashy. It assumes skilled users, manual setup, and informed judgement. That will suit experienced character TDs more than newcomers, which aligns with the tool’s existing audience.

It also reflects a broader trend of rigging tools absorbing tasks that used to live in separate utilities. Whether this is desirable depends on pipeline philosophy, but it does reduce context switching, which is often where errors creep in.

Compatibility and licensing

Kangaroo Builder runs on Autodesk Maya. At the time of writing, version 5.19 supports Maya 2023 and later on Windows and macOS, and Maya 2024 and later on Linux. Landmark Warp is included in the standard distribution and does not require a separate licence.

Licensing remains unchanged. Kangaroo Builder is free for non-commercial use, including students and personal projects. Commercial licences are available for indie users and studios. Pricing is published on the official website and may change, so readers should check the current terms directl.

At the time of writing, these are the prices: (Copied from the site)

Indy Perpetual – 220 USD
For freelancers making less than 85k USD per year in revenue

Single Perpetual – 400 USD
Recommended for or small studios with only one rigger

3 Seats Perpetual – 1000 USD
Recommended for small studios

6 Seats Perpetual – 1800 USD

Unlimited Seats Perpetual – 4000 USD

What is still unclear

No public information is available on how Landmark Warp behaves on extreme topology differences or highly stylised characters. There is also no data on performance with dense meshes or very large blendshape libraries. These gaps do not invalidate the feature, but they do mean that due diligence is required before deployment.

As with any rigging or deformation tool, results will depend on mesh quality, landmark placement, and user expertise. Early adopters should expect iteration, not miracles. Anyone hoping for a one-click solution will be dissapointed. s always, new tools and workflow changes should be tested thoroughly on representative assets before being introduced into active production.

The post Kangaroo Builder learns to move faces between meshes first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: BlendShape Monitor is a lightweight diagnostic plugin for Autodesk Maya that sits squarely in character rigging and facial setup, focusing only on inspection rather than deformation authoring, and does not overlap with Autodesk’s own rigging tools or third-party rig builders.

Why blendshapes still go wrong

Blendshapes remain one of the most common deformation methods for facial animation in Maya, particularly for FACS-based rigs and corrective shapes layered on top of joint systems. Despite their ubiquity, debugging blendshapes once a rig grows beyond a few dozen targets remains largely manual and error-prone. Maya’s native interface presents blendshape nodes as long, alphabetical lists of target names with numeric weights. That abstraction works when rigs are small and well documented. It breaks down quickly when shapes overlap, are reused across multiple regions, or are indirectly driven by other systems, such as RBF solvers.

This problem is compounded in production environments where rigs are inherited, shared, or modified over time. In many cases, artists are asked to fix deformation issues without knowing which blendshape is responsible, or whether multiple shapes are contributing simultaneously. The result is a familiar cycle of muting targets, scrubbing weights, and guessing.

What BlendShape Monitor actually does

BlendShape Monitor is a diagnostic plugin for Autodesk Maya that attempts to replace that guesswork with direct visual feedback. Instead of relying on target names and numerical weights, the tool visualises the influence of individual blendshapes directly on the mesh using colour-coded vertex heatmaps. These heatmaps update in real time, including during animation playback, reflecting the current evaluated weight of each shape.

The plugin reads the deformation data from existing blendShape nodes. It does not modify the rig, create new targets, or alter evaluation order. According to the developer, its sole purpose is inspection. This distinction matters, as the tool is intended to be safe to use on production rigs without changing scene data.

The visualisation highlights which vertices are affected by a given blendshape and to what extent. Areas with stronger deformation are shown in higher-intensity colours, making it immediately obvious whether a shape is localised, overlaps with others, or extends into unintended regions of the mesh.

Managing clutter in dense rigs

One of the stated goals of BlendShape Monitor is to make large blendshape sets manageable. The plugin includes filtering options that hide inactive targets, allowing artists to focus only on shapes that currently contribute to the deformation. This is particularly relevant when blendshapes are driven indirectly by other systems, where weights may be non-zero even if no animator is directly adjusting them.

The tool also allows individual targets to be solo-ed. When a shape is soloed, other blendshapes are temporarily hidden from the visualisation, making it easier to inspect its isolated effect. Global visibility toggles let you enable or disable the heatmap overlay without removing the plugin from the scene.

Weight values are synced live with Maya’s evaluation during playback. This means the visualisation reflects the rig’s actual state at each frame, rather than a static snapshot. For troubleshooting animation issues that only appear in motion, this real-time aspect is central to the tool’s design.

Origin in production reality

BlendShape Monitor was developed by Johnson Lee, an artist and tools developer whose work as Art Director at Reallusion directly informed the tool’s focus on large-scale facial rigs. According to the developer, the plugin emerged from internal production needs rather than as a speculative product idea.

At Reallusion, facial rigs for characters such as those used in Character Creator workflows can exceed one hundred blendshapes. These include expression shapes based on FACS conventions, as well as numerous corrective shapes used to address secondary deformation. In such setups, identifying which shape is responsible for an artefact using Maya’s default UI is time-consuming and unreliable. The plugin reflects that context. It is narrowly scoped, avoids adding new rigging concepts, and addresses a specific bottleneck encountered when maintaining and debugging existing rigs rather than building new ones.

Compatibility and scope

BlendShape Monitor is compatible with Autodesk Maya 2022 and later. No support is claimed for earlier versions. The plugin runs inside Maya and does not require external dependencies according to the product listing. Installation and licensing are handled via Gumroad.

The tool does not claim to support other DCC applications, nor does it attempt to abstract blendshape concepts across platforms. It is explicitly Maya-specific, relying on Maya’s native blendShape node behaviour. It is also not positioned as a teaching tool. Users are expected to understand blendshape workflows, vertex-level deformation, and Maya’s rig evaluation. The plugin provides visibility, not validation.

Pricing and licensing

BlendShape Monitor is sold via Gumroad. At the time of writing, pricing is listed at approximately USD 20 for a freelance licence and USD 70 for a studio seat. The exact terms of these licences are defined on the Gumroad page and should be reviewed before purchase. No subscription model is indicated.

What it does not solve

While the plugin makes deformation issues easier to see, it does not resolve them automatically. Poor topology, conflicting targets, and incorrectly authored shapes still need to be fixed at the source, by you. BlendShape Monitor does not rank shapes by quality, detect errors, or suggest corrections.

It also does not address performance issues caused by excessive blendshape counts or inefficient evaluation. Its visual overlays are for inspection, not optimisation. Artists should be cautious when using any viewport overlay in heavy scenes and test performance impact in their own environments.

Production considerations

As with any new tool, BlendShape Monitor should be evaluated under controlled conditions before being deployed to production. Its read-only approach reduces risk, but pipeline teams should still test compatibility with existing rigs, scripts, and viewport configurations.

In teh final analysis, BlendShape Monitor addresses a narrow but persistent pain point in Maya character rigging, offering visibility where the host application still relies heavily on lists and numbers. Whether it becomes a standard part of rig debugging workflows will depend on how well it holds up wiht the messier rigs found in long-running productions.

// BlendShape Monitor Gumroad product page
// https://johnsonlee529.gumroad.com/l/bs-monitor-maya/

The post BlendShape Monitor puts Maya rigs under a heat lamp first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The Blender add-on CamKeys, developed by BeyondDev (Tyler Walker), automates ShapeKeys according to camera or viewport angles. It enables an object to deform differently depending on how it is viewed, a method commonly used in stylised animation, anime-inspired facial rigs, or forced-perspective effects. Formerly known as CamShapeMatic, CamKeys 3.0 introduces a redesigned interface, multilingual documentation, and expanded animation baking tools.

ShapeKeys with eyes

CamKeys connects one or more ShapeKeys (Blender’s morph targets) to the relative angle between a camera and an object. When the camera moves, the mesh interpolates between ShapeKeys based on the configured angular falloff. Each “CamKey” entry defines a camera angle, target ShapeKey, and blending range. Updates occur in real time during playback, scrubbing, or rendering. For rigged characters, the effect can also be driven by bone rotation instead of the entire object’s orientation, allowing deformation of specific body parts such as heads or torsos.

What’s new in version 3.0

Version 3.0 adds refined bone tracking, improved multi-object handling, and support for linked assets. sers can employ CamKeys to imitate per-object field-of-view (FOV) shifts, producing perspective distortion variations between characters or props. However, the official Beyond-3 documentation does not describe any FOV modification feature. Technically, CamKeys does not alter Blender’s projection system. It drives ShapeKeys by camera angle, which can visually approximate FOV changes but does not constitute a real optical override. Artists may creatively repurpose it for such effects, but this behaviour is not documented or officially supported.

Inside the interface

The CamKeys panel is divided into three areas:

• Select Camera – Defines the active camera or viewport. Baking requires an actual camera.
• Mesh Objects – Lists meshes affected by CamKeys, each optionally tied to a bone.
• Camera Angles & ShapeKeys – Captures current view angles, assigns ShapeKeys, sets blending width, enables or disables entries, and bakes driven animation curves into keyframes.

All parameters update live, and tooltips in multiple languages (English, Japanese, Spanish) are provided throughout the interface.

Pricing and licensing

CamKeys is sold via Gumroad with three pricing tiers: Indie (1 user) at 19.99 USD, Studio (3–5 users) at 69.99 USD, and Studio (6+ users) at 199.99 USD. Purchases include lifetime updates. Redistribution or modification of the add-on is prohibited, but commercial use is permitted with credit to the creator.

Typical use cases

According to the official documentation, CamKeys is suited for:

• 2D/3D hybrid animation and stylised facial deformation
• Perspective “cheat” effects without rig scaling
• Real-time mesh updates during playback
• Automatic deformation across camera switches
• Baking ShapeKey-driven animation for export

BeyondDev’s examples show anime-style characters that morph smoothly between front and side views, preserving proportions through angular interpolation.

Production caveats

No independent tests have yet confirmed how CamKeys behaves with advanced setups such as depth-of-field, motion blur, or multi-camera rigs. Blender’s dependency graph can behave unpredictably when properties depend on camera-driven transformations. While users label CamKeys 3.0 as enabling “per-object FOV,” BeyondDev’s own documentation explicitly describes ShapeKey automation by camera angle only. This difference is important when planning for camera-matched compositing or depth-based rendering workflows. Artists should run small validation tests before deploying the add-on in production pipelines or automated rigging setups.

Final frame

CamKeys remains a technically clear, niche utility: it automates mesh deformation relative to viewing direction, offering stylised animators precise control over how geometry reads from different angles. Whether it truly supports “per-object FOV” depends entirely on user interpretation, not on the add-on’s code.

For those seeking controlled, angle-driven morphs without complex rig logic, CamKeys provides a practical and well-documented solution that Blender still lacks natively. As always: test before production.

The post Shapekeys: The angle on your mesh first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Reallusion has released Video Mocap, an online AI motion-capture service integrated into iClone. The feature was developed with AI mocap firm QuickMagic and arrives alongside iClone 8.63, a minor update focusing on plugin support and FBX export fixes. Video Mocap extracts actor movement from uploaded footage and generates editable animation directly inside iClone. Unlike standalone online services that export FBX data, the new plugin connects the AI pipeline to iClone’s animation system, allowing users to clean up artefacts such as foot slippage using iClone’s native tools.

Capture options and limitations

The service offers full-body or upper-body capture, including finger tracking. Facial motion capture is not supported and remains a separate paid add-on in the iClone ecosystem. Each motion-generation task processes up to 60 seconds of video for a single character and costs 250 DA Points, equivalent to $2.50. DA Points are Reallusion’s digital currency, sold with a minimum purchase of $10. Video processing takes place entirely online, and users can submit multiple clips in a batch. Up to ten motion files can be generated per batch if a video contains several performers.

Compatibility and pricing

The Video Mocap plugin is available as a free download for iClone 8.63 and Windows 10+. iClone itself remains a paid application with a $599 perpetual licence. Video Mocap operates on a pay-per-use model. Each clip must be trimmed to a maximum of 60 seconds, though source videos up to 15 minutes can be uploaded. Supported formats include .mp4, .mov, .avi, .mkv, and ten others. Reallusion recommends a minimum resolution of 720p, while 4K and 8K files may reduce performance.

Recording recommendations

Reallusion advises recording footage with a static, eye-level camera, ensuring the performer’s full body or upper body remains visible, depending on the capture type. AI tracking may fail if the subject leaves the frame, wears clothing similar to the background, or performs rapid or occluded motions such as flips or combat. The firm also recommends removing empty video sections before upload to improve motion-tracking accuracy. These and other technical notes are detailed in the iClone Video Mocap Online Manual.

Context: AI mocap enters production tools

Video Mocap joins a growing field of AI-based motion capture systems that interpret human movement from standard video footage. Reallusion’s implementation distinguishes itself by integrating this functionality directly into a production-ready 3D animation platform, avoiding intermediate export steps.

As with any AI-driven system, actual performance and accuracy will depend on recording conditions, motion complexity, and camera quality. Artists should test the service with their own material before integrating it into production pipelines.

The post Video Mocap: Reallusion’s AI Gets Moving first appeared on DIGITAL PRODUCTION and was written by Bela Beier.