radi2025/slides.md

---
theme : "simple"
customTheme : "slides"
width : 1920
height: 1080
showNotes: false
controls: false
progess: true
fragmentInURL: true
enableMenu: false
autoPlayMedia: true
enableTitleFooter: false
slideNumber: true
logoImg: "src/logosmall.png"
title: "Enquêter sur les pipelines : une approche scientifique des organisations de production"
---


# Enquêter sur les pipelines

## une approche scientifique des organisations de production

<!-- .slide: data-state="hide-menubar" -->

---

## À propos


<div id="left">

![](src/swann.png){.portrait}

### Dr. Swann Martinez 

</div>

<div id="right">

![](src/remy.png){.portrait}

### Dr. Rémy Sohier

</div>

note:
⏭️

<!-- .slide: data-state="hide-menubar" -->

--

## Our jobs
<div id="left">
<img src="./src/xilam.png" width=40%><br>
<img src="./src/cube_nb.png" width=40%>
</div>

<div id="right">
<img src="./src/p8_logo.png" width=50%><br>
<img src="./src/inrev.png" width=30%>
</div>

note:
Swann is an R&D Engineer at Cube/Xilam and worked part-time on the project as a research engineer at INREV.  
Rémy is a professor and researcher at INREV, overseeing the Art & Technology of Image program at Paris 8 University.

<!-- .slide: data-state="hide-menubar" -->

--

## Paneurama
<img src="./src/paneurama.png" width=10%/>
<img src="./src/funded_eu.png" width=25%/>
<br>

<img src="./src/Paneurama-partners-schools.png" width=70%/>
<br>

<img src="./src/Paneurama-partners-industry.png" width=90%/>
<br>

<img src="./src/Paneurama-partners-associated.png" width=90%/>

<br><br>


note:
This study was co-funded by Europe as part of an Erasmus+ project.<br>
BRIDGE THE GAP BETWEEN SCHOOLS AND STUDIOS<br>
Educational institutions<br>
Industry partners<br>
Associated partners in the Paneurama network<br>
BREDA -> Netherlands, Breda<br>
THE ANIMATION WORKSHOP -> Denmark, Viborg<br>
ANIMATIONINSTITUTE -> Germany, Stuttgart<br>
QVISTEN -> Norway
RISE FX -> Germany, Stuttgart  
Workshop, research, reports...

<!-- .slide: data-state="hide-menubar" -->

---


## Sommaire


1. Introduction général / Motivations du projet {.fragment}
2. Démarche de recherche {.fragment}
3. Axes d'analyses{.fragment}
4. Limites & Futures{.fragment}

<!-- .slide: data-state="hide-menubar" -->

note:
Aujourdhui, nous allons parler des pipelines !

---

<!-- .slide: data-stack-name="Motivations" -->

# Introduction générale

<!-- .slide: data-auto-animate data-transition-speed="slow"-->


--


## Motivations du projet

- Aider les étudiants et les écoles à mieux comprendre **comment fonctionne réellement l'industrie** <br>
- Partager des **connaissances ouvertes** sur les workflows de pipeline et de production <br>

note:
Aider les étudiants et les écoles à comprendre comment les studios fonctionnent vraiment — et pas seulement la version idéalisée des manuels. <br>
Combler le fossé entre l'éducation et l'industrie : une meilleure formation facilite l'intégration des nouveaux artistes. <br>
Promouvoir la connaissance ouverte — partager les schémas de pipeline au lieu de les garder comme des « secrets de studio ». <br>
Construire une cartographie collective des pratiques de production que d'autres peuvent utiliser, enrichir ou remettre en question. <br>

---

<!-- .slide: data-stack-name="Méthode de recherche" -->

# Méthode de recherche


<!--  Comment on a mené cette recherche
-->

--

## Contraintes

- Culturelle: pipeline = **secret professionnel** 
- Temporelle: 6 mois

note:
Tout d'abord,  
Nous avons été confrontés à deux contraintes majeures...  
- Secrets professionnels : beaucoup considèrent le pipeline comme un avantage concurrentiel  
- Temps : nous avions 6 mois de financement pour cette étude initiale

--

## Problèmes

- Comment **visualiser** un pipeline ?
- Comment **comparer** les pipelines entre studios ?
<br>
<img src="./src/compare_studios.png" width="100%">

--

## Hypothèse

- Il existe quelque chose de **plus profond que le workflow**.
- Avec un **modèle de visualisation standard**, nous devrions pouvoir comparer les pipelines.<br>
- Le pipeline pourrait être **non transférable** d'un studio à l'autre.

--

## Périmètre de l'étude

- Studios français (alumni)
- Animation 3D
- Studio avec un état d'esprit opensource


note:
Ces contraintes nous ont amenés à restreindre le périmètre de notre recherche.
Pour mener une étude comparative, nous nous sommes concentrés sur l'animation 3D.
Pour faciliter l'accès aux données et contourner les problèmes de confidentialité, nous avons privilégié les entreprises ayant une culture open source.

--

## Protocole de collecte des données

*- Comment récupérer et visualiser les informations sur les pipelines ? -*

note:
Le principal défi était de trouver un moyen de récupérer et de représenter les données des pipelines des studios ! Voyons comment nous avons procédé ⏭️

--

### Step 1: <span class="fragment" data-fragment-index="0">Entretients semi-dirigés</span>

<div class="twocolumncenter">
<div>

- Cartographie des DCCs<sup>[1]</sup> {.fragment data-fragment-index="1"}
- Cartographie du workflow {.fragment data-fragment-index="2"}

<font size=50em color=red>**= Pourquoi**</font> {.fragment data-fragment-index="4"}
</div>
<div class="fragment" data-fragment-index="3">

![](./src/workflowdcc_carto_flavio.png)
*Schéma simplifié des départments & DCCs, Flavio Perez, 2017*
</div>

</div>

<div class="fragment footnote" data-fragment-index="1" >

- [1] Digital Content Creation tools
</div>


note:
La première étape consistait à comprendre la finalité du pipeline au sein de l'entreprise et à en obtenir une vue d'ensemble macro.<br>
Pour cela, lors de l'entretien, nous avons recensé les logiciels et les étapes de production, puis les avons cartographiés dans un schéma de base, inspiré des diagrammes de Flavio Perez dans son mémoire de master.<br>
Cela nous donne le "**POURQUOI**" du pipeline. ⏭️

--

<div class="schema">
    <img data-id="workflowcube" src="./src/chicky_workflow.svg" style="position:relative;" />
</div>

Résultat de l'interview semi-dirigée pour Cube Creative.

note:
Nous avons terminé le premier entretien avec des schémas comme celui-ci pour Cube Creative. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"-->

--

<div class="schema">
    <img data-id="workflowcube" src="./src/chicky_workflow.svg" style="position:relative;height:2000px;bottom:700px;right:-100px; max-width:none;" />
</div>

Une représentation simplifiée du workflow depuis l'écriture...

note:
Comme vous pouvez le voir, cela cartographie les étapes et logiciels, qu'ils soient intégrés ou non au pipeline, depuis l'écriture... ⏭️
<!-- .slide: data-auto-animate data-transition-speed="slow"-->

--

<div class="schema">
    <img data-id="workflowcube" src="./src/chicky_workflow.svg" style="position:relative;height:2000px;bottom:1300px;right:120px; max-width:none;" />
</div>

jusqu'à la fabrication des assets...

note:
jusqu'à la fabrication des assets... ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"-->

--

<div class="schema">
    <img data-id="workflowcube" src="./src/chicky_workflow.svg" style="position:relative;height:2000px;bottom:600px;right:2200px; max-width:none;" />
</div>

jusqu'à la fabrication des plans...

note:
jusqu'à la fabrication des plans... ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"-->

--

<div class="schema">
    <img data-id="workflowcube" src="./src/chicky_workflow.svg" style="position:relative;height:2000px;bottom:600px;right:3800px; max-width:none;" />
</div>

... jusqu'à la livraison des images 🚀 !

note:
... jusqu'à la livraison des images ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"-->

--


### Step 2: <span class="fragment" data-fragment-index="0">Directed interviews</span>

<div style="text-align: center;">
<div class="fragment" style="display:inline;" data-fragment-index="1">Retrieve 
 <img style="vertical-align: middle;" width=4% src="./src/accolades_o.svg"></div>
<ul style="list-style-type: none; margin: 0; vertical-align: middle;text-align:center;">
<li data-fragment-index="2" class="fragment" >infrastructure levels </li>
<li data-fragment-index="3" class="fragment">processes </li>
<li data-fragment-index="4" class="fragment">versionning </li>
<li data-fragment-index="5" class="fragment">assets & shot composition</li>
<li data-fragment-index="6" class="fragment">file formats</li>
</ul>
<div class="fragment" data-fragment-index="7" style="display: inline;">
<img style="vertical-align: middle;" width=4% src="./src/accolades_c.svg">
to find out <font color=red> <b>HOW</b></font> the pipeline is made.
</div>
</div>

note:
The goal of the 
Data collection process:<br>
1.We aim to get a general overview of the pipeline's motivations <br>
2.We define more precisely its data management<br><br>
This will give us "how" the pipeline is modeled 
==>  However, which representation should we use to map this information?? ...

--

## Step 3: dataflow mapping methodology

--

### Pipeline Patterns <font size=6.6em><sup>[1][2]</sup></font>

<span data-id="pipeexplanation"><span class="fragment" data-fragment-index="0">Visualize how pipeline <font color=red>**data**</font></span> <span class="fragment" data-fragment-index="1"> changes accross <font color=red b>**processes**</font></span></span> <span class="fragment" data-fragment-index="2">over time and <font color=red> **infrastructure** </font>.</span>

<div class="r-stack">

<div>
<img src="./src/pipelinepatternlegend_elements.drawio.svg" class="fragment" data-fragment-index="0" width=900> 
<img src="./src/pipelinepatternlegend_relation.drawio.svg" class="fragment" data-fragment-index="1" width=800> 
</div>
<div>

![](./src/pipepattern_explanation.drawio.svg){.fragment data-fragment-index="2" height=600}

</div>
</div>

<div class="footnote">

- [1] B. Polson, « A conceptual framework for pipeline », in Proceedings of the 2015 Symposium on Digital Production, in DigiPro ’15. p. 51‑52. doi: 10.1145/2791261.2791272.
- [2] B. Polson, « CG pipeline design patterns », in Proceedings of the Fourth Symposium on Digital Production, in DigiPro ’14.p. 29. doi: 10.1145/2633374.2637729.
- More at https://www.pipelinepatterns.com/

</div>

note:
To do this, we followed the methodology outlined by Bill Polson on **pipelinepatterns.com**.  
This approach consists of representing the fundamental elements of a pipeline and their relationships... ⏭️
So basically how data is modified by process accross time and infrastructure 
And this happens in two dimensions! Vertically, we have the infrastructure, and horizontally, we have time.<br>
Let’s look at an example from Cube Creative’s pipeline ⏭️

<!-- .slide: data-auto-animate -->

--

<div class="schema">
    <img data-id="pipecube" src="./src/dataflow_cube_chicky.drawio.svg" style="position:relative;" />
</div>

*Cube Creative pipeline datadlow.*

note:
With this methodology, we can represent the complete dataflow of a pipeline.<br>
Let’s take a closer look at the asset modeling workspace ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"-->

--


<div class="schema">
    <img data-id="pipecube" src="./src/dataflow_cube_chicky_mask.drawio.svg" style="position:relative;height:2000px;bottom:1000px;right:400px; max-width:none;" />
</div>

*Asset modeling workspace*

note:
We observe that Blender is used for this production step. Without surprises, the working scene contains only geometry information from the pipeline’s perspective. From Blender, artists export playblasts using the *Tournette* process (an internal addon) and modeling LODs via a *push*. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"-->

--

<div class="schema">
    <img data-id="pipecube" src="./src/dataflow_cube_chicky.drawio.svg" style="position:relative;height:800px;right:-450px; max-width:none;" />
</div>

*Asset modeling workspace*

note:
As you can see vertically, these exported elements are synchronized with the server. However, only the playblast and the working file are versioned; the LODs are not. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"-->

--

<div class="schema">
    <img data-id="pipecube" src="./src/dataflow_cube_chicky.drawio.svg" style="height:800px; position:relative;right:300px; max-width:none;" />
</div>

*Asset shading workspace*

note:
Next comes the shading step... Unfortunately, it would take too long to explain each step's dataflow in detail.  
Just remember that this methodology was used to model the pipelines of all participating studios from the start... ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow" -->


--


<div data-id="pipecube" class="schema">
    <img src="./src/dataflow_cube_chicky.drawio.svg" style="height:800px; position:relative;right:4900px; max-width:none;" />
</div>

*Shot compositing workspace*

note:
..to the end of its scope in the production.  

<!-- .slide: data-auto-animate data-transition-speed="slow" -->

---

<!-- .slide: data-stack-name="Participating studios" data-auto-animate data-transition-speed="slow"  -->

## Participating Studios 

<div class="threecolumn">

<img data-id="cubetrans" src="./src/cube.png" width=90% class="fragment"/>
<img src="./src/autour-de-minuit.jpg" width=90% class="fragment"/>
<img src="./src/Normaal.jpg" width= 90% class="fragment"/>


</div>

note:
Thank you remy !    
Let's introduce the studios who kindly agreed to open their doors and share their pipelines:  
Cube Creative, Autour de Minuit, and Normaal Animation. ⏭️

--

<img data-id="cubetrans" src="./src/cube.png" width=30% />



<hr>

<div class="twocolumncenter">
<div>
<img src="./src/affiche_ATH.jpg" height=400px/>
<img src="./src/affiche_CKY.png" height=400px/>
<img src="./src/affiche_KAE.jpg" height=400px/>

More at https://www.cube-creative.com/

</div>
<div>
Github link 👇

![](./src/cube_github.svg){width=300px .roundedcorner}

</div>

</div>

note:
**Cube Creative** is a studio within the Xilam group,  **known for IPs** such as *Kaeloo*, *Athléticus*, and *Where's Chicky?*<br>
They specialize in tv shows and short films.   
Many of their production tools are available on GitHub, which you can see here ;)   
Every year, they participate in the Blender Conference to present various aspects of their pipeline or productions. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  data-background-video="./src/showreel_cube.mp4" data-background-video-loop data-background-opacity=0.2 data-background-video-muted -->

--

<img src="./src/Normaal.jpg" width=30% /> 

<hr>

<div class="twocolumncenter">
<div>
<img src="./src/normaal_barba.png" height=300px/>
<img src="./src/normaal_peanuts.png" height=300px/>
<img src="./src/normaal_zouk.png" height=300px/>

More at https://normaal.fr/
</div>
<div>
Stax Toolsuite link 👇

![](./src/stax_link.svg){width=300px .roundedcorner}

</div>

</div>

note:
**Normaal Animation** is a studio specialized in 2D/3D series, known for many licenses such as Barbapapa, among others.  
**The studio's pipeline lead** is the developer behind Stax, an amazing production-ready review solution based on Blender and open source !  
I've included the link on the right ⏭️

<!-- .slide: data-background-video="./src/normaal_showreel.mp4" data-background-video-loop data-background-opacity=0.2 data-background-video-muted-->

--

<img src="./src/autour-de-minuit.jpg" width=30% /> 

<hr>

<div class="twocolumncenter">
<div>
<img src="./src/adm_caribou.jpg" height=400px/>
<img src="./src/adm_nonnon.png" height=400px/>
<img src="./src/adm_unicornwars.jpg" height=400px/>

More at https://blog.autourdeminuit.com/

</div>

<div>
Public Gitea instance 👇

![](./src/adm_gitea.svg){width=300px .roundedcorner}

</div>

</div>

note:
**Autour de Minuit** is a French studio, well known for projects like the movie "Unicorn Wars" and the TV show "Non-Non."  
**They** are specialist in blending 2D and 3D techniques in blender with unique storytelling.  
They also host their own Gitea instance, where they share productions-ready  awesome addons such as a character picker ! ⏭️

<!-- .slide: data-background-video="./src/adv_showreel.mp4" data-background-video-loop data-background-opacity=0.2 data-background-video-muted -->

---

## Comparative study

note:
**Now that** the introductions are done,  let's dive into the study 

<!-- .slide: data-stack-name="Comparative study" -->

--

## Studied Projects

note:
**And we will firstly introduce** the projects that served as the basis for our pipeline mapping survey. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--


## Studied Projects

<div class="threecolumn">

<div class="fragment">
<img src="./src/cube.png" width=50%/>
<img height=600 src="./src/where-s-chicky.jpg" />
</div>

<div class="fragment">
<img src="./src/autour-de-minuit.jpg" width=50%/>
<img height=600 src="./src/ohlala_adv.avif" />
</div>


<div class="fragment">
<img src="./src/Normaal.jpg" width=50%/>
<img height=600 src="./src/whooly_whooly.png" />
</div>

</div>

note:
**For Cube Creative**, we studied the pipeline of *Where's Chicky?*.  
**For Autour de Minuit**, we mapped their new show in **pre-production**, *OhWow !*  
**And for Normaal**, we documented the pipeline used for the tv show Wooly Wooly.  
**A few notes** on the format of these projects ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

## Studied Projects

<div class="threecolumn">

<div>
<img src="./src/cube.png" width=50%/>
<img height=400 src="./src/where-s-chicky.jpg" />

- format: **52x1" episodes**
- style: 3D animation

</div>

<div>
<img src="./src/autour-de-minuit.jpg" width=50%/>
<img height=400 src="./src/ohlala_adv.avif" />

- format: **52x7"  episodes**
- style: 3D animation

</div>


<div>
<img src="./src/Normaal.jpg" width=50%/>
<img height=400 src="./src/whooly_whooly.png" />

- format: **51x11" episodes**
- style: 3D animation

</div>

</div>

note:
**All three** projects are pre-school 3D animated TV shows.  
**The project's format** varies slightly between productions, espetially for *Wheres' Chicky*.   
**One thing to note** is that the Chicky pipeline was also used for their new series, Piggy Builders (52x11"). 
**We will** know slowly dive into pipeline details of each production ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

## Productions steps

note:
**Please note** that we will focus only on production details and skip pre-production & post-production, **as they are outside the pipeline scope**..    
**Let's Start** with production steps .  ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

## Productions steps: assets

| | |
|-|-|
| ![](./src/where-s-chicky.jpg){.portraitsquared} | <font class="fragment" size=50>Modeling ➡️ Shading ➡️ Rigging ➡️ Animation Bank (Characters)</font>  |
| ![](./src/ohlala_adv.avif){.portraitsquared} | <font class="fragment" size=50>Modeling ➡️ Surfacing ➡️ Setup</font> |
| ![](./src/whooly_whooly.png){.portraitsquared} |  <font class="fragment" size=50>Modeling ➡️ Surfacing ➡️ Setup</font> |

note:
**At Cube**, asset frabrication starts with...  
**The animation bank** step consists of creating facial expressions and animation cycles, which are then reused during shot animation.   
At Autour de Minuit...  
**And finally,** at Normaal...  
**As you can see,** all three studios have similar asset production steps. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

## <span data-id="test">Productions steps :</span> Shots

| | |
|-|-|
| ![](./src/where-s-chicky.jpg){.portraitsquared} | <font class="fragment" size=50>Layout ➡️ Animation ➡️ Rendering ➡️ Compositing </font>  |
| ![](./src/ohlala_adv.avif){.portraitsquared} | <font class="fragment" size=50>Layout ➡️ Animation ➡️ FX ➡️  Lighting </font> |
| ![](./src/whooly_whooly.png){.portraitsquared} |  <font class="fragment" size=50>Layout ➡️ Animation & FX ➡️ Rendering ➡️ <span class="fragment highlight-red">Compositing</span> ➡️ <span class="fragment highlight-red">editing</span></font> |

note:
For shot construction:  
**We have** ... for Chicky  
For OhLala: ...  
For Wooly Wooly: ...
Please note that compositing and editing are off-pipeline scope for *wooly wooly*.  
**The main difference** here is that, at Cube, FX are built as reusable assets instead of being created per shot.    
At ADM and Normaal, some FX are made directly in the shot.  
**Now,** which software is used for these steps? ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

## Production softwares

<div class="threecolumn">

<div>

<img height=400 class="portraitsquared" src="./src/where-s-chicky.jpg" />

--- 
<div class="fragment">
<img src="./src/blender-icon-256x256-1.png" height=80/>
<img src="./src/logo-kitsu.de716c4b.png" height=80 />
<img src="./src/python-logo.png" height=80 />
<img src="./src/app-nuke-192x192.png" height=80/><br>
<img class="bw" src="./src/storyboard-pro-logo.png" height=80/>
</div>
</div>
<div>

<img height=400 class="portraitsquared" src="./src/ohlala_adv.avif" />

--- 
<div class="fragment">
<img src="./src/blender-icon-256x256-1.png" height=80/>
<img src="./src/logo-kitsu.de716c4b.png" height=80 />
<img src="./src/python-logo.png" height=80 /><br>
<img class="bw" src="./src/storyboard-pro-logo.png" height=80/>
</div>

</div>

<div>

<img height=400 class="portraitsquared" src="./src/whooly_whooly.png" />

--- 
<div class="fragment">
<img src="./src/blender-icon-256x256-1.png" height=80/>
<img src="./src/logo-kitsu.de716c4b.png" height=80 />
<img src="./src/python-logo.png" height=80 />
<img src="./src/ay-symbol-blackw-full.png" height=80 /><br>
<img class="bw" src="./src/storyboard-pro-logo.png" height=80/>
<img class="bw" src="./src/logo-adobe-after-effects-png_optimized-768x768.png" height=80/>
<img class="bw" src="./src/1200px-Adobe_Premiere_Pro_CC_icon.svg-1842527822.png" height=80/>
</div>
</div>

note:
**All three productions** use similar software environments, with some differences.     
**To improve clarity**, DCCs beyond the pipeline scope are shown in gray.   
On *Where's Chicky* ...  
On *OhWow* ...  
On *Wooly Wooly* ...        
**Storyboard Pro** is used in all three cases for storyboarding during pre-production.    
**For post-production**, Nuke and the Adobe suite are also used.   
**However**, Blender is the main 3D production tool for all three, and Kitsu is used for production tracking.   ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### Simplified workflow Recap'

- Same project format{.fragment data-fragment-index="0" }
- Similar production steps{.fragment data-fragment-index="1" }
- Similar DCC's<sup>[1]</sup>{.fragment data-fragment-index="2" }

<br>

<font color=red size=30 class="fragment">**But what about the dataflow ?**</font>

<div class="fragment footnote" data-fragment-index="2" >

- [1] Digital Content Creation tools
</div>

note:
**To summarize** the details we just covered,  
we have three projects with similar formats, as well as similar production steps and DCCs.  
**But what** about the underlying dataflow? ⏭️

--

### Dataflow insights

![](./src/underthehood.gif){width=700}

note:
What is fascinating about this study is that the mapped pipelines show some similarities, but above all, many differences. Especially in dataflows ⏭️

--

![](./src/dataflow_adv_holala.svg)

![](./src/dataflow_cube_chicky.drawio.svg)

![](./src/dataflow_normaal_wooly_wooly_retakes.svg){width=1200}

note:
**I know** it's hard to see everything here ^^<br>
**But even from a distance**, you can visualize three **very** different dataflows! ⏭️

--

## Sudied aspects

Scene building strategies {.fragment}

<span data-id="worktitle">Asset update propagation patterns</span>{.fragment}

Infrastructure architecture {.fragment}

Standard file formats implications {.fragment}

Resource libraries{.fragment}

Work versionning strategies{.fragment}

Software environment{.fragment}

... {.fragment}

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

note:
**These mappings allowed us** to study many aspects of the audited pipelines!<br>
**Among these**, we have...<br>
**As we won't** have time to cover all these points in detail, we've selected the most significant one for this presentation. The full details will be published in an upcoming article. ⏭️

--

<span data-id="worktitle" style="font-size:1.8em;">Asset update propagation patterns</span>

*How update propagate through the fabrication ?*

note:
**Work propagation** is one of the most interesting aspects to study.  
In a pipeline, this term refers to how update propagate through the fabrication process. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

## Tow mecanisms used
<div class="twocolumn">

<div class="fragment">

### ⬆️ Push{data-id="push"}
**Automatic** updates when an asset is published  
</div>

<div class="fragment">

### ⬇️ Pull
Updates applied **manually** from shots 
</div>
</div>

note:
**In the three pipelines studied,** we identified two main assets propagation patterns:<br>
-The Push, where updates are automatically propagated<br>
-The Pull, where updates are manually retrieved<br>
**Let’s take a closer** look at how this is modeled in a Blender dataflow... ⏭️

--

### ⬆️ Push : how ?

<div class="r-stack">

![](./src/push_0.drawio.svg){width=1600 .fragment current-visible data-fragment-index="0"}

![](./src/push_1.drawio.svg){width=1600 .fragment current-visible data-fragment-index="1"}

![](./src/push_2.drawio.svg){width=1600 .fragment current-visible data-fragment-index="2"}

![](./src/push_3.drawio.svg){width=1600 .fragment current-visible data-fragment-index="3"}

![](./src/push_4.drawio.svg){width=1600 .fragment current-visible data-fragment-index="4"}

![](./src/push_step_2_1.drawio.svg){width=1600 .fragment current-visible data-fragment-index="5"}

![](./src/push_step_2_2.drawio.svg){width=1600 .fragment current-visible data-fragment-index="6"}

![](./src/push_step_2_3.drawio.svg){width=1600 .fragment current-visible data-fragment-index="7"}

</div>

<div class="r-stack">

Asset latest state saved{ .fragment .current-visible data-fragment-index="2"}

Asset **hero version** linked in the layout scene during the **build**  {.fragment .current-visible data-fragment-index="3"}

Asset **hero version** linked in the animation scene during the **build**  {.fragment .current-visible data-fragment-index="4"}

Asset **hero version** <font color=red>**overwritten**</font> during the publish  {.fragment .current-visible data-fragment-index="6"}

Layout and Animation scene <font color=red>**automatically updated**</font> on loading.{.fragment .current-visible data-fragment-index="7"}


</div>

note:
**To simply explain** the push mechanism:  
**Imagine you have** an asset shading step, followed by layout and animation steps for shots.  
**The shading artist** works on the v1 version of the asset's shading.
**As the work progresses**, they publish (save as) the latest version in the "push zone / hero version."  
**Then** Layout and animation scenes are built by creating a **link** to this hero version.  
**With this setup,** whenever the shading artist creates a new version and updates the hero version, it is automatically propagated to all layout and animation shots using it !  
**This method is very convenient** for automatically updating scenes and fast iterations.    
**However,** automatic updates are not always desirable, as they can modify shots that have already been artistically approved.  
**But Where** is this mechanism used in the studied productions? ⏭️

--

### ⬆️ Push : Where ?

<div class="twocolumncenter">
<div class="fragment">
<img class="portraitsquared" src="./src/where-s-chicky.jpg"/><br>

- Method: Link 
- Scope: **Background** props assets, all steps

</div>

<div class="fragment">

<img class="portraitsquared" src="./src/whooly_whooly.png" /> <br>

- Method: Link & Overrides 
- Scope: All assets, Layout only
</div>

</div>

note:
**Push is used** by only two productions, and only partially.  
**In the case of Chicky**, the push is applied throughout the entire production chain, but only for one asset type: background components.  
**For Wooly Wooly**, the push is used for all assets up to the layout stage. Pull becomes the preferred method after layout, at the start of animation.  
**It's intersting** to see **where** but most of all to see **how** each studios implemented the method.
I will only show you a simplified view of it. 

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### ⬆️ Push : Implementations

<div class="twocolumntext">
<div>
<img class="portraitsquared" src="./src/where-s-chicky.jpg"/><br>
</div>
<div>

![](./src/push_chicky.svg){width=1000}

Chicky push example (*simplified*)
</div>

</div>

note:
**For Chicky,** the initial step of the push mechanism is still the publishing step. However, here, several versions of the same aspect of the asset are exported—these are called Level of Details (LODs).  
**As previously shown**, these LODs are then directly linked into the shot scenes.  
**The linked LOD version** is chosen based on the production step or the asset's distance from the camera.

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### ⬆️ Push : Implementations

<div class="twocolumntext">
<div>
<img class="portraitsquared" src="./src/whooly_whooly.png" /> <br>
</div>
<div>

![](./src/push_woolywooly.drawio.svg){width=1000}

Wooly Wooly push example (*Simplified*)

</div>

</div>

note:
**On Wooly Wooly**, the push mechanism is closer to the initial example we saw.  
**However, as you can see**, it’s not just a single hero version that gets published from the asset task.  
**Each publish iteration** is saved in the publish area,  
**but with every publish**, the hero version at the bottom is overwritten.  
**The published versions** are then used for the pull mechanism, which we’ll discuss next.  
**Now**, let's take a look at the *Pull* mechanism... ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### <span data-id="pull">⬇️ Pull :</span> How ?

<div class="r-stack">

![](./src/push_0.drawio.svg){width=1600 .fragment current-visible data-fragment-index="0"}

![](./src/push_1.drawio.svg){width=1600 .fragment current-visible data-fragment-index="1"}

![](./src/pull_0.drawio.svg){width=1600 .fragment current-visible data-fragment-index="2"}

![](./src/pull_1.drawio.svg){width=1600 .fragment current-visible data-fragment-index="3"}

![](./src/pull_2.drawio.svg){width=1600 .fragment current-visible data-fragment-index="4"}

![](./src/pull_3.drawio.svg){width=1600 .fragment current-visible data-fragment-index="5"}

</div>

<div class="r-stack">

Asset's **version** directly linked.{ .fragment .current-visible data-fragment-index="2"}

Updates are made <font color=red>**individually** in **shots** files</font> {.fragment .current-visible data-fragment-index="4"}

</div>

note:
**As usual,** the artist will start by creating a first version of an asset.
**The main difference with** the pull mechanism is that shot scenes have a specific asset version linked, rather than a single "hero" version that is regularly overwritten.    
**What does this** mean in practice? It simply reverses the update process !    
When a new version is published, each shot must be updated individually to point to the new asset version.  
**This process can be very tedious** to do manually, so studios often develop custom tools to automate it   
**Speaking of this,** lets see where the studio's used this mecanism... ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### <span data-id="pull">⬇️ Pull :</span> Where ? 

<div class="threecolumn">
<div class="fragment">

![](./src/whooly_whooly.png){.portraitsquared}

All assets from **animation** to **rendering** with link & overrides
</div>
<div class="fragment">

![](./src/where-s-chicky.jpg){.portraitsquared}

Character and Props in **all steps** with links
</div>
<div class="fragment">

![](./src/ohlala_adv.avif){.portraitsquared}

All asset in **all steps** with links + overrides
</div>

</div>

note:
**In the case of Wooly Wooly**, assets are "frozen" to the latest published version starting from the animation step. From that point on, asset updates are applied individually for each shot.<br>
**At Cube,** for Chicky, all animated assets use the pull mechanism from layout to rendering!       
**Finally,** for OhWow!, every production step relies on the pull approach. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### ⬇️ Pull : Implementations

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

note:
**But how** the pull is implemented by each pipeline ? ⏭️

--

### ⬇️ Pull : Implementations

<div class="r-stack">
<img class="portraitsquared" src="./src/whooly_whooly.png" style="position:absolute;right:1500px;top:50%"/> <br>

![](./src/pull_woolywooly.drawio.svg){width=1000}
</div>

*Wooly Wooly* pull example (*Simplified*)


note:
**As see previously**, on *Wooly Wooly*, during asset publishing,   
the new asset version get's copied into the publish area and the hero one is overwritten.   
On their side, the main difference with the push lies in the linked blendfile: 
**Instead of pointing to the hero version**, it's points to the versionned file. ⏭️


<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### ⬇️ Pull : Implementations

<div class="r-stack">
<img class="portraitsquared" src="./src/where-s-chicky.jpg" style="position:absolute;right:1500px;top:50%"/> <br>


![](./src/pull_chicky.svg){width=1000}

</div>

*Where's chicky* pull example (*Simplified*)

note:
**In *Where's Chicky*,** the pull implementation doesn't use any links because library overrides wheren't trusted enough by the production.   
**So, instead of linking assets** in the shot scene as in the pull approach, assets are directly appended.     
**It means that** the assets lives directly in shot scenes, and a new append is neeeded for each update. 

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### ⬇️ Pull : Implementations

<div class="r-stack">
<img class="portraitsquared" src="./src/ohlala_adv.avif" style="position:absolute;right:1500px;top:50%"/> <br>

![](./src/pull_ohlala.drawio.svg){width=1000}


</div>

*Ohlala!* pull example (*Simplified*)

note:
**Finally, on Ohlala,** asset working versions are directly linked into shot scenes.  
**This requires artists** to be highly disciplined in organizing their scenes, as there is no the safety margin of the publish area.    
**On the other hand,** this approach greatly reduces disk space usage since data is not duplicated. ⏭️

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

## Assets updates propagation : Recap'

*Three strategies to do it*

<div class="threecolumn">

<div class="fragment">

![](./src/where-s-chicky.jpg){.portraitsquared}

--- 
- **Push** for static assets.
- **Pull** for animated assets 

---
<font color=red> = Per-asset type strategy</font>

</div>

<div class="fragment">

![](./src/ohlala_adv.avif){.portraitsquared}

--- 
- **Pull** accross all the production

---
<font color=red> = Global strategy</font>

</div>
<div class="fragment">


![](./src/whooly_whooly.png){.portraitsquared}

--- 
- **Push** for all asset until Layout
- **Pull**  from Animation

---
<font color=red> = Per-step strategy</font>

</div>
</div>

note:
**À quick recap of** propagation strategies per production  
**On Chickies,** the push is mainly used for static assets, pull for animated assets    
**On holala,** the pull is used everywhere    
**And finally,** we have an hybrid strategy per shot step for wooly wooly. ⏭️

--


### Push 🆚 Pull 

<div class="twocolumncenter">

<div class="fragment">

<span style="font-size:2em;">**+**</span>

Support asset's fast iteration

Reduce development effort

<span style="font-size:2em;">**-**</span>

Less control over updates propagation

Require a good communication

</div>

<div class="fragment">

<span style="font-size:2em;">**+**</span>

Update control granularity

Better history tracking

<span style="font-size:2em;">**-**</span>

Require tools developments

Slow asset iteration
 
</div>

</div>

note:
**Let's briefly** look at some advantages and disadvantages of these two complementary methods.<br>
**On one hand,** the push supports fast asset iteration, but it does not allow for granular control over updates in shot files—pull is preferable here.     
**On the other hand pull makes it easier** to respect a validation chain.<br>
**From a purely technical perspective**, the pull requires more development effort, since updating references means opening scenes and changing links.  
**The Push pattern relies entirely on Blender's** native mechanisms and therefore requires very little development from the pipeline team.<br>

---

<!-- .slide: data-stack-name="Final thoughts" -->

## Final thoughts

note:
**Unfortunately,** we won't have time today to go further into the details of the data we collected.  
**However,** feel free to come see us after the presentation if you would like more information.   
**Before we finish,** let's look at the limitations and future directions of this study ⏭️

--

<div data-id="pipecube" class="schema">
    <img src="./src/paint-icerberg.png" style="height:3200px; position:relative; right:1800px;top:150px;max-width:none;"/>
</div>


note:


<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

<div data-id="iceberg" class="schema">
    <img src="./src/paint-icerberg.png" style="height:3200px; position:relative; right:1800px;top:-500px;max-width:none;"/>
</div>

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

<div data-id="iceberg" class="schema">
    <img src="./src/paint-icerberg.png" style="height:2200px; position:relative; right:900px;top:-700px;max-width:none;"/>
</div>

<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

<div data-id="iceberg" class="schema">
    <img src="./src/paint-icerberg.png" style="height:2000px; position:relative; right:900px;top:-1300px;max-width:none;"/>
</div>


<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--


<div data-id="iceberg" class="schema">
    <img src="./src/paint-icerberg.png" height=800/>
</div>


<!-- .slide: data-auto-animate data-transition-speed="slow"  -->

--

### Mapping methodology limits

- Validation data
- Attributes overrides
- Production tracker

note:
First of all, it's important to note that the mapping methodology we used for dataflow did not provide a way to represent Blender's override mechanism.  
It also did not address the role of the production tracker.  
We therefore extended the set of our diagrams to include these two elements.  
We plan to share a library of shapes for drawio/diagram.net to make it easier to create these diagrams. ⏭️

--

### Data sample limits

- Only french studios
- Only TV Show projects

note:
Initially, the study focused on a small group of companies to explore the project's feasibility. Additionally, we only examined TV series projects. ⏭️

--

### Futures

- Interview european studio's {.fragment}
- Map other project formats (movies, VFX, games) {.fragment} 
- Bring interactive online visualisation of studied pipelines {.fragment}  

note:
In the future, we hope to broaden the scope of this study by surveying European studios to understand how socio-economic factors in different countries impact pipeline structures.<br>
We also aim to map pipelines used in other project formats to compare their structures.<br>
Improving the accessibility of these mappings is another major focus. ⏭️


--

## Thanks you !

<div id="left">

### 📧 Participate to the study

![](./src/mail.svg){width=300}
</div>

<div id="right">

### ❤️ Thanks to the contributors

- Félix David (Normaal)
- Christophe Seux (ADM)
- Florentin Luce (ADM)
- Axel Tillement (Cube)
- Dorothée Lanchier (Xilam)


</div>

note:
Thanks a lot for listening !
If you represent a studio and are interested in participating, feel free to come talk to us directly or send an email to this address!  
Don't hesitate to reach out if you have any questions!