At the Kitsu Summit, Félix David, head of pipeline at Normaal Studio, shared how they built a production-grade 3D pipeline from scratch inside a studio that had never made a 3D series before.
His talk covered the tools, the philosophy, and the hard lessons that shaped the pipeline for "Woolly Woolly," a 52-episode animated series.
Animation studios looking to scale their production processes will find his experience worth studying closely!
About The Speaker
Félix David has worked as a pipeline TD for several years, previously at Super Prod before joining Normaal Studio as lead pipeline developer.
Normaal Studio is a French animation studio with deep roots in 2D production. When the studio decided to produce "Woolly Woolly", a stop-motion-inspired 3D series with 52 episodes of 11 minutes each, it had no existing 3D infrastructure.
Félix was brought in to build that infrastructure from the ground up, with a team that eventually grew to five pipeline TDs working alongside roughly 80 animators spread across three facilities in Angoulême, Paris, and Québec.
The Core Challenge: A 2D Studio That Expected 3D To Feel Like 2D
The production brief Félix received contained an unusual requirement.
Because Normaal Studio's directors and supervisors came from 2D backgrounds, they expected to see something close to a final render at every stage of production.
In 2D animation, what you draw is essentially what you see.
In 3D, that is rarely true: there are shading passes, lighting setups, camera corrections, rendering queues... the difference between an animator's work and a final frame can be day and night.
As Félix explained: "They wanted a pipeline to display previews as close to final renders as possible, at all the time."
To solve this, the team embedded a low-definition but fully lit render directly into the animation publish step.
When an animator submitted their work, the pipeline automatically triggered not just a playblast (a quick viewport preview) but a real render, using the lights already built into the set.
Because "Woolly Woolly" used a flat, front-facing visual style inspired by theater staging, the lights were always keyed to the set and did not need to move between shots. This meant the low-def render was both cheap to produce and genuinely representative of the final look.
The Pipeline Philosophy: Automate Without Adding Pain
Before choosing any specific software, Félix established a guiding principle for the entire pipeline: automation should remove steps, not add them.
Studios that build pipelines without this constraint often end up forcing artists to click through extra dialogs, fill in metadata forms, or wait for processes they do not understand before they can get back to work.
"The main philosophy is to avoid adding more pain to the process," Félix said. "Freedom from the constraints that the computer is adding to the production."
That framing shaped every technical decision that followed.
Why They Chose Open-Source Tools: Kitsu and AYON
For production tracking, the team chose Kitsu. For pipeline management, they chose AYON (OpenPype), an open-source pipeline framework that handles file publishing, version management, asset loading, and synchronization across multiple sites. Blender served as the primary DCC (digital content creation) application for 3D work.
Félix was deliberate about the decision to use existing open-source tools rather than building custom scripts: "You cannot anticipate all the needs you will encounter. Using something which has already been tested and developed helps you, because most of the use cases you will have to deal with have already been solved."
For a studio making its first 3D production, that argument carries significant weight. Building a proprietary pipeline from scratch means spending months solving problems that other studios have already worked through. Open-source tools like AYON and Kitsu come with solutions to many of those problems built in.
One of Normaal Studio's contributions to AYON during production was a synchronization system between Kitsu and AYON, allowing production tracking data in Kitsu to automatically inform the pipeline state in AYON. That contribution was submitted back to the main AYON codebase.
Félix described this process of contributing back as slower but ultimately more reliable: "When it's accepted and merged and used in the main codebase, you know that it's been tested. It will remain there a long time, so it forces you to design your code with care."
Non-Destructive Publishing & Path-Based Data Access
Two principles shaped how data moved through Normaal Studio's pipeline.
The first is non-destructive publishing: once data has been published, it is never modified. If something needs to change, a new version is published. This guarantees that any shot can always be traced back to the exact asset versions it used, and that no published data can be silently broken by a later edit.
The second principle is path resolution rather than data transfer. Rather than serving files through a central server, AYON resolves file paths on request: when an artist or automated process needs a file, AYON returns the path to where that file lives on the filesystem. The actual data transfer happens through standard file sync mechanisms instead of using the slower pipeline server.
Félix described the practical benefit in terms of infrastructure: "If you only ask for a path to something, it's much lighter and doesn't need a large and heavy infrastructure to run your production." An added benefit was resilience. Each workstation cached its own data locally, meaning that if the server went down, artists could continue working on their local copies until it came back.
Asset Workflow vs Shot Workflow
One of the most valuable insights from Félix's talk was his distinction between how assets and shots should be treated in a pipeline, because the two behave very differently.
An asset is composable by design. A character, for example, might consist of separate published products for geometry, shading, and rig. The rig references both the geometry and the shading, but you can also load the geometry alone, which is useful when placing a character in the background without the overhead of a full rig.
Félix described how the shot workflow initially mirrored this composable approach, scattering geometry, rigs, and camera data across separate published products at each stage.
That approach did not hold up in practice: "It could work, but it's useless, because the animation is right after the layout and it uses the same configuration for most of the things."
The shot workflow they settled on was incremental rather than composable. Each stage in the shot pipeline builds directly on the work file from the previous stage. Layout produces a work file that becomes the starting point for animation. Animation produces a work file that becomes the starting point for effects and rendering. Nothing is split apart and rebuilt at each step.
Keeping Shots Up To Date As Assets Evolve
One problem that cannot be avoided on a long-form production is asset evolution.
Characters get better shaders. Rigs get corrected. Sets get redesigned. On "Woolly Woolly," the production team regularly asked for updated assets to be applied to shots that were already animated but not yet approved.
Normaal Studio solved this with a concept called hero versions.
A hero version is not a specific numbered version of an asset; it always points to the most recently published version. Layout scenes referenced the hero version of each character rather than a specific numbered version.
This meant that when a new shader was published for a character, any layout scene using that character's hero reference would automatically incorporate the update the next time it was opened.
For shots already in animation, the team built a Blender-based automation tool that could open work files, swap updated rigs or assets, preserve existing animation transforms and modifiers, and republish a new version of the animation automatically. This tool ran across many shots at once without requiring individual artists to manually update each scene.
File Dependencies & Pre-Syncing For Remote Artists
With artists working across three cities, keeping everyone's local file caches up-to-date was another challenge. Large production scenes in Blender depend on many linked files (characters, sets, props, etc.) and waiting for those files to sync on demand wastes time.
Normaal Studio's solution was a background sync service that used data from Kitsu's breakdown feature. When a shot was assigned to an artist, the pipeline could read the breakdown to determine which characters and sets appeared in that shot, then pre-sync all the relevant files to that artist's workstation before they even opened the task.
By the time the artist clicked to start work, everything they needed was already there.
The same pre-build logic applied to work files. Rather than requiring a layout artist to click a "build" button and wait for the system to assemble their starting scene, the pipeline built that work file in the background as soon as the task was assigned. Opening a task meant opening a fully prepared file.
Rendering Without A Render Farm
Normaal Studio did not have the budget for cloud rendering or a dedicated render farm.
Instead, the team used OpenCue, an open-source render management tool developed by Google and Sony Pictures, to distribute rendering across artist workstations during idle time.
Every minute a workstation was not in use by an artist, OpenCue could put it to work on a render job or an automated build task.
Key Takeaway
Félix closed his talk with a reflection that applies well beyond his specific technical choices: "You cannot have your perfect universal pipeline that everyone could use. But you can build a good one which fits the studio culture and helps to add fluidity to the production."
For Normaal Studio, fitting the studio culture meant accepting that a 2D-trained director would need to see lit renders, not OpenGL playblasts. It meant building automation that removed technical burdens from artists without changing how they thought about their work. And it meant choosing tools like Kitsu and AYON that had already absorbed years of community knowledge, so the pipeline team could focus on the problems that were actually unique to their production.
