- 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>
<imgsrc="./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é ⏭️
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>
<spandata-id="pipeexplanation"><spanclass="fragment"data-fragment-index="0">Visualise comment <fontcolor=red>**les données**</font></span><spanclass="fragment"data-fragment-index="1"> changes à travers des <fontcolor=redb>**processus**</font></span></span><spanclass="fragment"data-fragment-index="2">à travers le temps et <fontcolor=red>**l'infrastructure**</font>.</span>
- [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.
On observe que Blender est utilisé pour cette étape de production. Sans surprise, la scène de travail ne contient que des informations de géométrie du point de vue du pipeline. Depuis Blender, les artistes exportent des playblasts à l'aide du processus *Tournette* (un addon interne) et modélisent les LODs via un *push*. ⏭️
Comme vous pouvez le voir verticalement, ces éléments exportés sont synchronisés avec le serveur. Cependant, seuls le playblast et le fichier de travail sont versionnés ; les LODs ne le sont pas. ⏭️
**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. ⏭️
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**<fontcolor=red>**overwritten**</font> during the publish {.fragment .current-visible data-fragment-index="6"}
Layout and Animation scene <fontcolor=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 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.
**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.
Updates are made <fontcolor=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... ⏭️
All assets from **animation** to **rendering** with link & overrides
</div>
<divclass="fragment">
{.portraitsquared}
Character and Props in **all steps** with links
</div>
<divclass="fragment">
{.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. ⏭️
**À 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
<divclass="twocolumncenter">
<divclass="fragment">
<spanstyle="font-size:2em;">**+**</span>
Support asset's fast iteration
Reduce development effort
<spanstyle="font-size:2em;">**-**</span>
Less control over updates propagation
Require a good communication
</div>
<divclass="fragment">
<spanstyle="font-size:2em;">**+**</span>
Update control granularity
Better history tracking
<spanstyle="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 ⏭️
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 !
<divid="left">
### 📧 Participate to the study
{width=300}
</div>
<divid="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!
