feat: conclusion refacto

slides.md

@@ -802,21 +802,21 @@ note:
 
 --
 
-## Sudied aspects
+## Aspects étudiés
 
-Scene building strategies {.fragment}
+Stratégies de construction de scène {.fragment}
 
-<span data-id="worktitle">Asset update propagation patterns</span>{.fragment}
+<span data-id="worktitle">Schémas de propagation de mise à jour asset</span>{.fragment}
 
-Infrastructure architecture {.fragment}
+Achitecture d'infrastucture {.fragment}
 
-Standard file formats implications {.fragment}
+Implications de formats standards {.fragment}
 
 Resource libraries{.fragment}
 
-Work versionning strategies{.fragment}
+Stratégies de versionning{.fragment}
 
-Software environment{.fragment}
+Environement logiciel{.fragment}
 
 ... {.fragment}
 
@@ -863,283 +863,6 @@ note:
 -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"  -->
 
 --
 
@@ -1246,7 +969,7 @@ note:
 
 <!-- .slide: data-stack-name="Final thoughts" -->
 
-## Final thoughts
+## Limites et futures de l'étude 
 
 note:
 **Unfortunately,** we won't have time today to go further into the details of the data we collected.  
@@ -1257,11 +980,31 @@ note:
 
 --
 
-### Mapping methodology limits
 
-- Validation data
+### 🗺️ Méthode cartographique
-- Attributes overrides
+
-- Production tracker
+<div class="twocolumn">
+
+<div>
+
+**🔒 verroux identifiés**
+
+- ~~Overrides d'attributs~~
+- ~~Interactions avec le production tracker~~
+- Données de validation
+</div>
+<div>
+
+**🗝️ Propositions**
+
+- 
+- Interactions avec le production tracker
+- Données de validation
+
+
+</div>
+
+</div>
 
 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.  
@@ -1271,47 +1014,81 @@ We plan to share a library of shapes for drawio/diagram.net to make it easier to
 
 --
 
-### Data sample limits
 
-- Only french studios
+### 🧫 Échantillons
-- Only TV Show projects
+
+<div class="twocolumn">
+
+<div>
+
+**Limites**
+
+- Studios français
+- Format de série d'animation
+</div>
+<div>
+
+**Futur**
+
+- Élargir les formats de projet
+- Élargir aux autres studios européens
+
+
+</div>
+
+</div>
+
 
 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
+### Publication sur <img src="./src/hal.webp" style="width:280px;position:relative; top:75px;"/>
 
-- Interview european studio's {.fragment}
+<div class="twocolumn">
-- Map other project formats (movies, VFX, games) {.fragment} 
+<div>
-- Bring interactive online visualisation of studied pipelines {.fragment}  
 
-note:
+**En cours**
-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. ⏭️
 
+- Publication des cartographies en ligne sur HAL
+
+![alt text](./src/halmoderation.png) 
+
+
+- Rédaction d'un article de synthèse sur le premier volet
+
+</div>
+
+<div>
+
+**Future**
+
+- Mise a disposition des template de diagrammes
+- Ouverture d'une collection HAL dédiée au études cartographie pipeline
+
+</div>
+</div>
 
 --
 
-## Thanks you !
+## Merci !
 
 <div id="left">
 
-### 📧 Participate to the study
+### 📧 Participer à l'étude
 
 ![](./src/mail.svg){width=300}
 </div>
 
 <div id="right">
 
-### ❤️ Thanks to the contributors
+### ❤️ Merci aux contributeurs
 
 - Félix David (Normaal)
-- Christophe Seux (ADM)
+- Christophe Seux (Autour du Volcan)
-- Florentin Luce (ADM)
+- Florentin Luce (Autour du Volcan)
-- Axel Tillement (Cube)
+- Axel Tillement (Cube Creative)
 
 
 </div>