Photomontage lives or dies on perspective. If the camera does not match the photograph, everything downstream becomes a negotiation with angles, scale, and taste. CameraMatch AutoSetup v6 targets that first domino by generating an aligned 3D camera from a single photo, then setting up supporting scene items that normally take a few manual passes.

What CameraMatch AutoSetup v6 does

CameraMatch AutoSetup v6 is an automated camera-matching tool for photomontage work. It detects vanishing points and lines in photographs and uses that information to create a 3D camera aligned to the plate, aimed at architectural visualisation and general 3D scene setup.

Once the camera alignment happens, the tool also covers a set of setup chores that tend to get skipped until they break a comp. It can calculate and display the horizon line. It can create a physical camera with an accurate field of view. It can match the render output resolution to the background image resolution. It can set a viewport background overlay that shows vanishing point lines and the horizon. It can also export cameras using the FBX format so the camera can travel to other applications.

The overall pitch reads like a checklist of common photomontage necessities, bundled into a single automated pass. That pitch also includes marketing claims about ease and straightforwardness, which remain marketing claims.

Host apps today, and what is promised next

The currently available versions work with 3ds Max and Blender. A version for Maya is described as planned, and additional host versions are described as coming next week.

Camera matching tools often stumble on the unglamorous details of units and output sizing, so it is notable that the material calls out unit setup dialogs and scene unit contexts as part of the broader setup conversation. That framing keeps the tool squarely in production reality rather than demo land.

Why this matters for post and VFX

A good plate match is not just about placing geometry. It is about making every downstream decision cheaper. When the camera and horizon are consistent, the layout behaves. Lighting behaves. Shadow direction behaves. Reflections behave. Even simple matte work becomes more predictable because perspective lines agree across layers.

For photomontage-heavy teams, the time sink is usually not the final render. It is the first 20 minutes of making sure the camera is believable, the frame matches the plate, and the viewport does not lie. CameraMatch AutoSetup v6 positions itself as a shortcut through exactly that part of the day, with its strongest promise being camera alignment plus the surrounding setup steps in one go. If you have ever watched a project drift because two artists picked two slightly different horizons, you already know whcih argument this tool wants to prevent.

Availability, docs, and pricing reality

Documentation exists as a free manual hosted on Google Drive. The manual is covering the script for 3ds Max, Blender, and Maya. Distribution is offered through two storefront channels: Gumroad and Patreon. A one off purchase option for the Gumroad of 45USD, or through a

The download description also references a full script with files for 3ds Max and Blender, and it mentions direct contact as an option. The complete contents of the downloadable package are not listed in the provided material beyond that.

Practical notes before you point it at a deadline

Automation shines when you can trust the inputs. This tool relies on reading vanishing points and lines from photographs, so images with heavy lens distortion, weak straight line cues, or ambiguous architecture may still need human judgment and cleanup.

As always, new tools and innovations should be tested before use in production. Run it against known plates, compare results to your established camera match method, and confirm the exported camera behaves as expected in your pipeline before you bet a delivery on it. And yes, it can be both fast and correct, but only after teh boring validation pass that everyone wishes they could skip.

https://jamiecardoso.gumroad.com/l/boqjtv?layout=profile

The post CameraMatch AutoSetup v6 speeds photo matches first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Re: Novation is now open for submissions from March 24, 2026 through June 9, 2026, with the submission cutoff set at 15:00 GMT. Judging starts June 10, 2026, and the winners are scheduled for announcement on June 24, 2026.

The core setup stays delightfully unforgiving: Everyone starts from the same base 3D building model. The job is to transform it into a finished scene that sells an idea through architecture, environment, and lighting. That can mean changing the purpose of the building, reshaping the facade, adding or removing floors, and building a world around it. The original structure still needs to remain recognizable, so this is a renvoation, not a witness protection program. There are great prizes and strong sponsor support: multiple prize categories, a cash component for top placements, and additional sponsor awards.

The rules focus on process, not just pixels

Participation starts with process proof. Artists are asked to publish a work in progress thread on a personal website, blog, portfolio, or social media page that clearly identifies them as a 3D artist. The first post needs to include the participation tag text for the challenge and a clickable link to the contest page or an at mention on social platforms. The intent is to show the work began during the challenge window and to support originality checks. The base model comes via a short form used to request the download. The model arrives in multiple formats: FBX, OBJ, 3DS, C4D, MB, and LWO. No premade Gaussian Splats, yet.

Scene freedom comes with a few hard stops. The rules allow third party assets such as vegetation, furniture, human figures, kitbash elements, and other asset library content. Post-production is allowed, but photobashing and paintovers are not. The final image must not show third party advertising, watermarks, or branding other than the provided sign that needs to appear visibly in the scene. The rule set also bans adult content, including blood, violence, eroticism, and politics.

The competition bans AI. The image must be created with 3D modeling software, and the rules also frame the work in progress requirement as part of verifying entries are original and not AI-generated.

Animation arrives, with guardrails

This edition introduces a dedicated Animation Category. Animation is optional, but entering it requires a still render submission as the main entry. Animation entries must run at least 15 seconds and must show the architectural scene, meaning the building and its environment.

The submission method routes animation through hosting platforms. Artists publish the final video on YouTube or Vimeo and provide the link with their submission. The minimum resolution is 1080p.

The animation must match the same scene as the still render. Work in progress recordings, timelapses, and screen captures do not qualify as animation entries. The animation rules also tighten the no AI stance further by banning AI-generated animation, motion capture from AI tools, and AI-assisted camera paths.

Animation judging criteria include camera work, pacing, lighting and mood transitions, storytelling, and technical quality. The broader judging criteria for the overall contest include visual appeal, concept originality, presentation, technical complexity of the model and scene, and overall execution quality.

Deliverables, specs, and the stuff that gets you disqualified

A finished submission needs a final render plus a clay or wire render of the scene. The render must be at least 1500 pixels on the longest side and must be delivered as JPG or PNG. File size should not exceed 5 MB.

The rules reject single-color background renders, test renders, unfinished work, pixelated or low-quality renders, screenshots, and models placed on wallpaper or photos. The rule text also states the contest model is for contest purposes only and cannot be used for other projects beyond the Re: Novation entry.

Entries can be updated during the contest, but the idea cannot change or be modified drastically, with only reasonable changes allowed. Artists can also correct the description and the tools list after submission by contacting the team.

One extra procedural detail matters for anyone trying to game the calendar. After sending the work via the contact form, a confirmation email is expected within one business day and includes a link to the gallery page. If that email does not arrive, participants are instructed to contact support.

Prizes and what is actually specified

The prize structure spans multiple categories: three main winners, one Animation Category winner, plus special sponsor award winners.

The top placements include cash prizes. First place lists a $1000 cash prize. Second place lists a $500 cash prize. Additional prizes include software licenses, subscriptions, training access, and render credits, along with challenge-time bonuses and discounts tied to participating sponsors. Some prizes may not be available in all regions.

The full details, rules, and sign-up sit on the official page at Re: Novation, and the organiser is 3DModels.org.

The post Re: Novation ArchViz Challenge opens first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

Unity Studio is now officially released after a beta that started last autumn. The product sits inside a browser and targets teams that want interactive real time 3D outcomes without turning every review cycle into a software install party.

The tool frames itself as a simplified counterpart to the Unity Editor. The split reads like this. Unity Studio focuses on quick creation and sharing of interactive 3D applications in a web-based workspace. The Unity Editor covers advanced development for complex applications.

Unity Studio is designed for people who work with 3D data but do not necessarily live in code all day, including designers, artists, training and marketeers, industrial engineers, and sales teams. That audience definition matters because it shapes almost every feature choice, from visual logic blocks to one click publishing.

The interface aims for familiar, not fearless

The day to day experience centers on a canvas with panels that list project contents and expose settings and controls for building and sharing. The tutorial material breaks the UI down into a Hierarchy panel, a Project panel, a Scene view, and an Inspector panel, plus a Camera Preview for framing the final view.

Navigation and inspection are built in so you can look at scenes, models, and assets from different angles. Lighting controls exist for mood and readability, which helps when you need to communicate intent rather than chase photoreal.

Unity Studio also supports building drafts as an initial working state. Drafts and projects live in the cloud and are accessible within an organization. The asset pipeline stays tightly connected to Unity Asset Manager, which stores uploaded assets, tracks versions of drafts, and keeps a version history you can browse.

Import and formats, with a cloud converter doing extra work

Asset ingest starts with upload and import flows that pass through Unity Asset Manager. The supported formats story splits into two layers.

On the direct import side, Unity Studio supports 3D model file formats including glTF in GLB form, FBX, and OBJ, plus supported image types like PNG and JPEG and supported audio types like WAV, MP3, AIFF, AIF, and OGG.

On the conversion side, the Asset Manager can convert additional formats into supported formats. The conversion list includes CAD oriented extensions such as STEP variants, and it includes OpenUSD variants such as USD, USDA, USDC, and USDZ, plus glTF, GLB, PXZ, and others.

The asset optimization angle hooks into Unity Asset Transformer. The Asset Manager uses that tool to optimize complex industry files, including CAD assets, so you can visualize and interact with them in a web browesr without extra software installs.

There is also a size related behavior worth knowing early. When an asset exceeds 200 MB, Unity Studio uses a preview GLB file instead of the original GLB, OBJ, or FBX file for that content.

Animation and UI, built for explanation

A lot of industrial and training content needs motion because motion explains behavior. Unity Studio includes animation tools that cover individual object animation and more complex sequences. The feature overview material describes an animation director that coordinates movements on a shared timeline using keyframes, with examples like fluid flows or mechanical sequences.

UI authoring sits on a UI canvas so you can place functional interfaces directly over the 3D scene. The feature set explicitly calls out buttons, readouts, and text, and the tutorial content includes creating UI text elements as part of an interaction example. That pairing matters because a lot of review workflows depend on guided UI, not just orbit and zoom.

Material work also shows up in the tutorial path. You can create new materials and edit existing ones, and you can duplicate an imported material into an editable copy so changes apply only to a specific object.

Logic, the no code promise in one word

Interactivity in Unity Studio centers on a visual scripting system called “Logik”, uhm, no. logic. Relax, Flame-Users! The Logic editor uses a node library and a builder area where you drag and connect building blocks. The goal is to create interactive behaviors without writing code.

Publishing and sharing: the review link is the deliverable

Publishing is built into the workflow. Unity Studio publishes applications to the web, and web is currently the only available platform option. The publish flow includes selecting Publish, choosing Web, entering a title, and optionally entering a password to restrict access. Publishing generates a Project Web URL you can share.

Sharing a published project is essentially sharing that link. Anyone with the link can access the application. Updating a published application pushes the latest changes to the live version via an Update action. Unpublishing takes the application offline so it is no longer accessible via the web link.

That set of actions lines up neatly with design review reality. You send one link, you iterate, and you do not play whack a mole with new attachments every time a stakeholder asks for a different camera angle.

Use cases: HMI, configurators, simulations, training

The product messaging and documentation focus on industrial and enterprise style scenarios that benefit from fast iteration.

The tool targets HMI prototyping for automotive and industrial dashboards. It targets product configurators where teams adjust colors and swap components in real time. It also targets step by step demonstrations of machine behavior in a browser. Training apps for operators are also in scope, and the product page calls out building 3D training experiences with assets, UI instructions, and live updates.

The docs also describe building configurators, designing HMI layouts, creating step by step training scenarios, and exporting work as a web application for customers or external partners to review. Across those tasks, the common thread stays the same: interactive review, short loops, and fewer handoffs.

Pricing and quotas, with the cloud meter clearly visible

Unity Studio is priced at $799 USD per seat, per year. There is a 30 day free trial with no credit card required.

Each seat includes 120 GB of cloud storage for assets and content in Unity Asset Manager. Each organization also gets 10 GB per month of bandwidth for deployed Studio applications for Studio app hosting. Additional storage can be purchased at $0.75 per GB per month and additional bandwidth at $0.50 per GB per month.

Deployment builds and hosts the application in the company cloud so teams can access it on the web without server management. Hosting uses bandwidth, so treat published links like any other hosted deliverable and keep an eye on how widely they travel.

A production minded reality check

Unity Studio aims to shrink the distance between a 3D idea and a clickable decision. It does that with browser delivery, visual Logic, and built in publishing. Those are strong levers for review and training pipelines where time disappears into coordination rather than creation.

Still, every new tool belongs in a staging lane first. Test it with representative assets, representative reviewers, and the same network conditions you expect in the real world. New tools and innovations should always be tested before use in production.

https://unity.com/products/unity-studio// Requirements and compatibility, browser versions, WebGPU notes, mobile browser limitation

The post Unity ships Unity Studio for in-browser 3D first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

For those who don’t know the tool: Blender is the free all in one DCC for modeling, animation, rendering, and export tasks like USD, with Eevee for realtime previews, Cycles for finals, and a Compositor that keeps quietly expanding its job description.

The release vibe: refine, then refine again

Blender 5.1 arrives with a clear theme: make everyday work feel lighter. The focus sits on quality of life improvements, stability, and polish, following a “Winter of Quality” push that solved 350 important issues and also cleaned up code to make future improvements easier.

That mindset shows up everywhere. Some changes are the sort you notice instantly. Others only reveal themselves after a week, when you realize you have not sworn at a dialog box even once. Progress comes in many forms. It is still the same familiar toolset. The difference is how often it gets out of your way.

Raycast: a shader node that likes to ask questions

A new Raycast shader node lands in the material system, built around a simple idea: shoot a ray, get useful surface information back, and use it to drive looks. That unlocks effects that rely on the closest point on a surface from the ray source, or the distance to it. There are demo files showing setups like toon shading and an X ray render effect.

There is also a practical warning: Raycast can be computationally expensive, and baking its output is suggested as a way to improve render times when needed.

Rendering: faster compiles, leaner memory, quicker frames

On the realtime side, Eevee speeds up material compilation by pre processing shader sources. In the standard Barbershop text scene benchmark, GPU shaders compile 25 to 50 percent faster across operating systems. Memory also gets attention. Eevee reduces texture memory use via texture pooling, helping scenes fit into less VRAM.

Cycles picks up performance gains too. GPU rendering improves by about 5 to 10 percent for many scenes, and HIP RT ray tracing is enabled by default on AMD GPUs. If your day includes lots of lookdev iteration, the combined effect is straightforward: fewer pauses between decisions.

Animation and rigging: the biggest speed win in the room

If you care about playback, Blender 5.1 comes with a headline worthy improvement: actions and shape keys evaluate significantly faster, with reported gains ranging from 4 percent to 304 percent in frames per second depending on the file. For cleanup work, the Graph Editor adds a Gaussian smoothing modifier that smooths curves non destructively. It is also explicitly described as resource heavy, with guidance not to use it on too many curves at once.

There are also small but practical timeline and editor touches that help animation feel less fiddly, like interpolation line colors indicating interpolation type in the Dope Sheet and menus.

Compositing and editorial: nodes that earn their keep

The built in Compositor adds a Mask to SDF node. It converts a mask into a Signed Distance Field by computing the distance of each pixel from the mask edges. That supports effects like edge glows, eroding or dilating mask edges, and distance based effects like procedural blurs.

The compositor also gains utility nodes including Boolean, Integer, Vector, and Index Switch, plus support for the existing Radial Tiling node. Speed matters here too. Several key nodes are faster, including Blur, Directional Blur, Vector Blur, Glare, Lens Distortion, and Anti Aliasing, described as 1.2x to 2x faster.

In the Sequencer, the Blade tool adds a box gesture that supports ripple editing, aimed at quicker cutting. Taken together, the message is clear: the VFX and video toolsets are being treated like first class citizens, not the side quest you only visit when your shot count gets scary.

Modeling and sculpt: a pile of small wins

Modeling sees a mix of performance and wrokflow tweaks. Filling for text objects improves, expanding the types of fonts that behave well as 3D text. Filling in general is up to five times faster, especially for n gons with many sides. Snapping adds an option to snap to the center of faces. In sculpt and paint, one visible addition is a Blur brush for blurring surface colors in Sculpt mode.

Grease Pencil: holes, at last

Grease Pencil gets notable workflow improvements, including better handling of strokes and fills and new ways to cut holes in shapes. Holes in fills can be created either via new operators that perform Boolean style operations or via the SVG importer. The draw here is practical: importing SVG and PDF content becomes easier to integrate without the same fill weirdness described in the feature overview. If you have ever built a workaround stack just to preserve negative space, this one lands with a satisfying thud.

Geometry Nodes: more rig friendly, more volume friendly

Geometry Nodes adds a Bone Info node that makes it possible to access bone position data. There are also new nodes for working with volume grids, including nodes for dilating, eroding, and clipping volume grids.

UI, file I O, and pipeline glue

The UI picks up just under 100 fixes and feature improvements, including the ability to search for controls by name in Preferences. Other practical UI touches include resizing quad views interactively by dragging the center point, and copying and pasting nodes between separate instances. On file formats, new options include AVIF export. Updates also land for USD, glTF, and FBX, with FBX files now including Shape Key normals for better compatibility with game engines like Unity.

For pipeline integration, support includes Python 3.13 and OpenColorIO 2.5, matching the CY2026 spec for the VFX Reference Platform. For virtual reality projects, the arc teleportation system is described as completely rewritten, and OpenXR is supported on macOS.

Availability and licensing

Blender 5.1 is a free download. The source code is available under the GPLv3 license. That free and open model is not new, but it still matters. It shapes how fast features get tested in the wild, how quickly workflows spread through studios, and how often a random late night fix becomes a shared win by morning.

The only remaining job is the boring one: install, test, validate, and only then roll it into serious work. Even a tool with a good mood still deserves a proper pipeline check. And yes, the Blender Foundation clearly wants this release to feel like a calm upgrade, not a reinvention.

https://www.blender.org/press/blender-5-1-release/

The post Blender 5.1 is here first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

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.