[:arrow_left:](/WQum2tYYSXGaBjnU2wMxzQ) to main Dashboard
[:arrow_left:](/47WdGvYKSueLiNqSQP_VFw) to Texturing Dashboard

# Mise en place Confo Shading

###### tags: `Texturing` `Shading`

#### Document en lien avec le document "Rebuild Departement Shading". Détail pour chaque step evoqué > constat, résultat, solution.

## Step 1 : Recupérer les maps des anciennes scenes

-Opération toujours en cours, la plupart des fichiers (maps et scenes) ont été retrouvé. Certains des assets demandent une recherche plus approfondie.

## Step 2 : Créer une scène de rendu complète > constat de la base

Cette étape a pour but d'établir un constat sur la situation actuelle, au niveau des assets (uvs, textures, shaders) et du rendu (temps de rendu, problèmes rencontrés, visuels avt/après)

### **Setup de la scene**

On est partis des 2 shots tests prévus initialement.

Dans une scène vierge > “Shots > ep001_sq001_sh093 > Rendering”

- Import en réf des Assets:
>Pirata01_Classic
>Capitano01_Classic
>Ananas01_Ananas01Wilson01
>BarracudaIslandSet01
>Pinkskull01_Classic
>Seaplane01_Classic
>Ocean01_Classic

(Aucun changement au niveau, uvs, shader, maps.)

- Setup Lighting:

Le set de light récupéré > set de présentation, pas forcément représentation du ligthing scene.
Le set de light des prés’ est trop complexes: 4 lights rien que pour avoir une directionnelle, une area teintée, et une backlight (bleue…?)

Création d’un set de light plus simple qui reprend l’ambiance général vu dans les anciens sets.

- Setup Caméra:

Premier test de rendu sur une séquence d’images > fixe (fr1-15)
(plans larges et gros plans)
Deuxième test rendu sur une séquence d’images > animées (fr16-....)
(traveling avant et pan)

- Setup Lights:

Area Light directional [teinte orangée]: samples de shadows à 64; softness à 1
Dome light [bleuté] : samples 128

- Setup Render:

Min samples : 4
Max samples 64
Denoise engine : OptiX
Primary Engine GI: Brute Force
Secondary Engine GI: Brute Force

**Constat:**

-Pas trop de grain
-Pas de flick

- Temps de calcul:

-Images Fixes: 2min environ avec plans moyen, 3min et+ sur gros plan (sur le seaPlane).
-Images Animées: Idem

- Esthétique des Assets:

Test locaux:
P:\PIRATA&CAPITANO2\10_TEMPS\SophieC\RENDERS
Test scene render:
P:\SHOTGUN\Pirata2\episodes\ep001\ep001_sq001\ep001_sq001_sh093\RDR\work\maya\images
-SSS
-Disp: présent que sur le “Seaplane” > utilité à démontrer !

- Problème de rendu:
Pas pour l’instant.

### **Etat de base des Assets**

### - Wilson:


**Les Uvs:**

-Si on extrait des éléments en l’état, comme les lunettes, les assets n’auront pas leur uvs dans les bonnes coordonnées.

-L’asset est répartit sur 10 udims

-15 maps loadées dans le node de file
> dont 9 maps faisant 8x8 pixels
> dont 5 qui ne correspondent à aucun uvset.

-L’utilisation des uvSets, peut être compliquée à gérer par la suite.
Ici, les uvSets sont utilisés pour intégrer les yeux sur le body > cette map de “Facial” servira-t-elle pour le rig ?
>Oui cette map rassemble une séquence d'image qui est intégrée au shader et projetée par la suite
>-Essayer de trouver une solution aux Maps d'uvSet

-Le layout d’uvs ne pourra pas forcément être modifié.

**Les Shaders:**

-Point positif: Chaque ensemble possède son propre shader. Aucun blend material

Il y a 5 shaders sur l’asset:
> 5 RedshiftMat (sss + spec)
>> 1 shader avec du sss > “leaves”

**Conclusion:**

Le layout d'Udim sera refait. Chaque ensemble d'Udims sera remit sur les coordonnées de base (1001,1002,1003).
Le sss étant présent que sur les feuilles, il sera surement conservé, à voir tout de même si les réglages ne sont pas à revoir.

Gros point d'interrogation sur la map d'uvSet pour les yeux.

---

### - Pirata:


**Les Uvs:**

-Comme pour Wilson, si on extrait des éléments en l’état, comme le “Hat”, les assets n’auront pas leurs uvs dans les bonnes coordonnées.

-L’asset est répartit sur 25 udims
> 25 maps loadées dans le node de file (25x3 dif/bump/spec +msk)
> dont 10 maps faisant 8x8 pixels

-Présence d’uvs overlapés et flippés. Garder des uvs flippés n’a aucun intérêt sauf si ils sont superposés sur d’autres uvs identiques.
>Les maps non overlapés ont parfois aucune différence de maps voire une map de 8x8 pixels pour injecter une simple couleur.

Ex: Body de Pirata > éparpillé sur 12 udims
> seuls les udims 1001 et 1011 ont une map (Visage de Pirata)
> les udims 1002-1006 et 1012-1016 ont tous une map de 8x8 avec seulement 1 aplat de couleur.

-Présence d’uvs non dépliés > les yeux de Pirata
Comment est géré le rig facial sur les persos ? N’ont ils pas besoin des uvs dépliés ?
>Réponse de Romain à cette question > séquence d’image intégrée au shader et projetée par la suite. Les modés sont présentes pour donner un peu de volume.

-La découpe des uvs en plein milieu, peut potentiellement créer des coutures
> Attention donc si jamais utilisation du transfert map (Note à moi même)

**Les Shaders:**

Il y a 20 shaders sur l’ensemble de Pirata !
>13 ReshiftMaterials > Fresnel
>> Belt Buckle (sss)
>> Bracelets (sss)
>> Hat (sss)

> 4 shader de SSS
>> Body
>> Ears
>> Belt
>> Hair

> 4 material blend
>> Cloth blend > 3 shaders redshiftMat > (no sss, + bump + spec)
>>> 1 pour le pantalon (arbo 2 CC + 1 CL + 1 Frl)
>>> 1 pour le Tshirt (arbo 2 CC + 1 CL + 1 Frl)
>>> 1 pour les rayures du Tshirt (arbo 2 CC + 1 CL + 1 Frl + 1 blendColor)

>> Body blend > 2 shader Redshift SSS > (sss + spec + bump (scale 0.010))
>>> 1 pour le body
>>> 1 pour les oreilles
Les 2 shaders sont connectés dans un Blend et des mask sont injectés pour determiner les zones impactées par chaque shader….Présence d’artefact sur le body.


Artéfact dû aux maps de mask.


>Hat > 2 shaders redshiftMat > (sss, + bump + spec)
>> 1 pour le Chapeau (arbo 2 CC + 2 BC + 1 CL + 1 Frl)
>> 1 pour le Logo (arbo 2 CC + 2 BC + 1 CL + 1 Frl)

> HatEars > 2 shaders redshiftMat > (no sss; bump, spec)
>> 1 pour l’intérieur des Oreilles (arbo 1 CC)
>> 1 pour l’extérieur des Oreilles (arbo 2 CC + 2 BC + 1 CL + 1 Frl)

**Conclusions:**

Après ce constat, il me semble préférable de refaire totalement l'asset. Des choses peuvent être récupérées, mais le shading et le layout d'Udims ne peuvent pas être laissés dans cet état, et les uvs du corps seraient aussi à refaire.
Le layout d'Udim sera refait. Chaque ensemble d'Udims sera remit sur les coordonnées de base (1001,1002,1003).

---

### - Capitano:


**Les Uvs:**

-Comme pour Wilson, si on extrait des éléments en l’état, comme les “Glasses”, les assets n’auront pas leurs uvs dans les bonnes coordonnées.

-L’asset est réparti sur 23 udims > Les lunettes ont 2 versions/positions et ne partagent pas les mêmes uvs donc pas les mêmes textures.


-Présence d’uvs overlapés et flippés. Garder des uvs flippés n’a aucun intérêt sauf si ils sont superposés sur d’autres uvs identiques.

-La découpe des uvs en plein milieu, peut potentiellement créer des coutures
> Attention donc si jamais utilisation du transfert map (Note à moi même)

**Les Shaders:**

Il y a 10 shaders sur l’ensemble de Capitano.
> 8 shader RedshiftMat
>> Body (sss)
> Clothes (sss)
> GlassesRim (sss)
> Glasses Temple (sss)
> Hand (sss)
> Shoes (sss)
> Hair Tip (sss)
> Hair (sss)

> 1 shader Blend
>> Hair Blend > 2 shaders
> 1 pour la base des cheveux (arbo Multiply/Divide, Clamp, CC, CL, sampler info)
> 1 pour l'extrémité des cheveux

> 2 Shader de SSS
>> Scarf (arbo Multiply/Divide, Clamp, CC, CL, sampler info)
>> Scarf Tips (arbo Multiply/Divide, Clamp, CC, CL, sampler info)

**Conclusions:**

Après ce constat, il me semble préférable de refaire en partie l'asset. Des choses peuvent être récupérées, mais le shading et le layout des Udims ne peuvent pas être laissés dans cet état, et les uvs du corps seraient aussi à refaire.
Le layout d'Udim sera refait. Chaque ensemble d'Udims sera remit sur les coordonnées de base (1001,1002,1003).

---

### - Le PinkSkull:


**Les Uvs:**

-L’asset est réparti sur 46 udims.
> 48 maps > 2 maps existantes mais il n’y a pas d’uv sur les uvsets attitrés
> 12 maps > 64x64

-Il y a 1 uvShell overlapé et 1 msh avec des uvs flippés

-Certains éléments peuvent être overlapé, d’autres pourtant symétriques ne peuvent pas l’être > Dépliage différent.

**Les Shaders:**

Il y a 41 shaders réparti sur l’ensemble de l’asset.
> 40 RedshiftMat > 5 shaders avec du SSS
> 1 shader SSS

**Conclusions:**

Vu l'ampleur de l'asset, cela prendrai du temps de le refaire entièrement, le layout d'uv serait à refaire totalement, ce qui impliquerait de refaire les maps et du coup de refaire le shading.
On peut donc effectuer en premier lieu, un réageancement du layout d'Udim, et ensuite cleaner les shaders pour essayer de retrouver une cohérence et faire en sorte que les assets soient propres une fois le split en sub asset effectué.

Le layout Uv de l'asset ont été totalement refait et certains uvs ont été modifié > Bake + Transfert Maps à faire sur cet asset.

---

### - Le Seaplane:


**Les Uvs:**

L’asset est réparti sur 59 Udims
> 58 maps de loadées.
> 25 maps > couleur unie 64x64

-La moitié de l’asset a été déplié puis une symétrie a été appliquée pour avoir des uvs identiques.
Mais par la suite ils ont été éparpillés > dans ce cas, garder des uvs flippés est inutiles. Cette méthode peut etre valable si dans les textures, il y a une volonté des variations ou de différences entre des meshs symétriques. Sur cette série c’est très peu le cas.

Exemple sur une partie des ailes:


Les maps correspondantes: 2 maps de 64x64


-Il y a des soucis de dépliages d’uvs sur certains meshs:
Ces problèmes de dépliages peuvent empêcher une déclinaison de texture
Dans le cas du Seaplane ce n’est pas visible puisqu’encore une fois la map correspondant à ces uvs est un aplat.


-Des ratios d’uvs différents.


Les différences de ratio entre un même ensemble d'uvs, peuvent empêcher l'utilisation de texture procédurale par exemple, ou simplement rendre la déclinaison plus compliquée. L'ajout d'un motif sur les 3 meshs qui composent l'aile, par exemple, n'aura pas la meme définition.

**-Les Shaders:**

Il y a 13 shaders sur le Seaplane.
> 3 Shaders Blend qui appellent 5 Shaders Redshift


> 1 shader pour le moteur (displace)
> 1 shader pour les parties rose du Seaplane (sss)
> 1 shader pour le manche (displace)
> 1 shader pour le siege (displace)
> 1 shader pour les vitres (displace)

Le displace sur ces assets entrainera des pénétrations avec Capitano. Le résultat du displace n'étant pas visible par les animateurs, ils ne peuvent pas anticiper le placement des mains ou de Capitano sur son siège.

**Conclusions:**

Les problèmes de dépliages d'uvs sont à cleaner impérativement.
Il est possible d'overlapper la plupart des uvs > à voir si les maps ne diffèrent pas trop et si cela ne crée pas de couture.
Le layout d'Udim sera refait. Chaque ensemble d'Udims sera remit sur les coordonnées de base (1001,1002,1003).
Concernant le shading, les blends de shaders sont à enlever, cela implique une refonte du shading.
Il a été vu aussi via les tests de rendu, que le sss était très peu visible, donc sa présence dans les shaders est vraiment remit en question.
Concernant le displace, présent sur le siège, le manche, le moteur et les vitres, il est totalement inutile, il sera donc enlever.

---

### **Bilan clean SSS et Displace**

Tous les comparatifs d'images sont disponible dans un nuke:
P:\PIRATA&CAPITANO2\10_TEMPS\SophieC\comparatif.nk

- Plan large:

**ACTUEL:** 6min51
**CLEAN:** 1min47
**GAIN :** 3.8x
**CHANGEMENT ESTHÉTIQUE:** Peu notable. Se situe surtout au niveau du bloc du Pinkskull (couleurs plus foncées sur le rendu avec SSS).


---

- Plan moyen:

**ACTUEL:** 8min29
**CLEAN :** 2min9
**GAIN :** 4x
**CHANGEMENT ESTHÉTIQUE:** Bien plus visible. Toutes les parties SSS sont sombres



---

- Plan serré:

**ACTUEL:** 6min13
**CLEAN :** 2min
**GAIN :** 3.1x
**CHANGEMENT ESTHÉTIQUE:** Bien plus visible. Toutes les parties SSS sont comme de la cire. Cela fake une GI. Rattrapable avec une color?



**Render:**

Séquence d'images sh093 > 250 frames

Assets en l'état:
P:\SHOTGUN\Pirata2\episodes\ep001\ep001_sq001\ep001_sq001_sh093\RDR\work\maya\images\ep001_sq001_sh093_RDR.v002

---

## Step 3 : Remettre à niveau les uvs + Bake et Tranfert Map.

### **Test Transfert Map**

Test transfert map sur l’asset “Bark01”

### **Test du tool**

Maps Asset:


**Cas 1: Uvs modifiés + Layout Uvset modifié**

Cas_1_01:

Le modèle test:
- il n’y a plus d’udim, l’asset est divisé en 2 zones “base” et “up”, chaque zone est sur 1 uvset en 1001.
- chaque zone est assignée à un lambert.

Le modèle origine:
- Les uvs n’ont pas changés, toujours sur 2 udims (1001,1002) > file code udim
- Plusieurs shaders sont assignés > shaders Redshift

Test sur la coque en mode ObjectSpace


Il transfert la couleur de l'hardwareShader

Cas_1_02:

Le modèle origine:
- Les uvs n’ont pas changés, toujours sur 2 udims (1001,1002) > file code udims
- Plusieurs shaders sont assignés > shaders Redshift > map diffuse assignée dans l’hardwareShader de la coque


Il applique une map qui ressemble à la map 1003 de l’origine.

Cas_1_03:

Le modèle origine:
- Les uvs n’ont pas changés, toujours sur 2 udims (1001,1002) > pas de code Udims dans le file.
- Plusieurs shaders sont assignés > shaders Redshift > map color assignée dans l’hardwareShader de la coque


Il transfert la map 1001 originelle sur mon mesh.
Cependant, l’intérieur de la coque étant sur l’udim 1002, sur le model d’origin et sur l'udim 1001, sur le model test, il a transferé aussi la 1001, sur l'intérieur de la coque > ce qui est logique !
L’intérieur de la coque a donc exactement la meme texture que l’extérieur.

Pour avoir la bonne texture sur l’intérieur il faut que la map 1002 soit settée sur l’origine.


Il faudra donc assembler les 2 maps dans le PSD.


Cas_1_04:

Le modèle origine:
- Les uvs n’ont pas changés, toujours sur 2 udims (1001,1002) > pas de code Udims > map 1001 settée.
- Plusieurs shaders sont assignés > shaders Redshift > map color assignée dans l’hardwareShader de la coque/bords
- Transfert sur 2 meshs > coque et les bords de la coque
>chaque mesh a ses uvs séparés sur 2 udims

Le model test:
- Ces 2 meshs sont rassemblés sur un même udim (1001) et les uvs des bords ont été refait et sont superposés > les numeros de vertex ont donc changé.


Clairement ca ne fonctionne pas sur les bords.

Cas sur les "Borders":

Pour ce mesh, la modé a été coupée en deux, permettant de déplier les uvs sur la moité, puis la symétrie a été refaite. Les uvs sont ainsi superposés, (gain de place, gain de tps en texture).


Ce cas extrême de rtk d'uvs, ne semble pas possible.

Cas_1_05:

Le modèle origine:
- Les uvs n’ont pas changés, toujours sur 2 udims (1001,1002) > pas de code Udims > map 1001 settée.
- Plusieurs shaders sont assignés > shaders Redshift > map color assignée dans l’hardwareShader de la coque/bords
- Transfert sur 3 meshs > coque, les bords de la coque et le siège
>chaque mesh a ses uvs séparés sur 2 udims
> la coque et les bords ont le meme shader
>le siège a un autre shader

Le model test:
- Ces 3 meshs sont rassemblés sur un même udim (1001) et les uvs des bords ont été refait et sont superposés.


Meme constat que pour la coque, il applique sur tout le mesh le resultat de la map settée sur le mesh d’origine (ici la 1001). Pour avoir les autres parties du mesh il faudra refaire la manip avec l’udim 1002 et tout rassembler dans un fichier Ps.

**Conclusions:**

-Le maps doivent être pluggées sur un lambert > soit l’hardware shader soit un nouveau.
-Les codes udims ne sont pas prit en compte > donc transférer une map à la fois.
-Refaire les uvs et les superposer n’est pas possible. Les vertex doivent avoir les memes numeros > donc pas de modification possible du mesh pour redéplier les uvs.

**Cas 2: Uvs pas modifiés + Layout Uvset modifié**

Chaque mesh a ses uvs sur le meme uvSet. Chaque ensemble a son shader propre.

Cas_2_01:

Le modèle origine:
- Les uvs n’ont pas changés, toujours sur 2 udims (1001,1002) > pas de code Udims > map 1001 settée.
- Plusieurs shaders sont assignés > shaders Redshift > map color assignée dans l’hardwareShader de la coque/bords
- Transfert sur 2 meshs > coque et les bords de la coque
>chaque mesh a ses uvs séparés sur 2 udims

Le modèle Test:
- Les uvs de la coque sont sur l’udim 1001
- Les uvs des bords sont sur l’udim 1001
- Ils ont des shaders différents


-Il a superposé les 2 alors qu’ils ont un shader différent
-Les meshs qui se trouvaient déjà en 1001 ont bien la map mais il faudra refaire le transfert avec la map 1002 pour récupérer les infos des autres uvs.

Cas_2_02: Transfert sur 1 ensemble de meshs qui n’a pas était modifié.

Le modèle origine:
- Les uvs n’ont pas changés, ils sont sur l’udim 1003 > pas de code Udims > map 1003 settée.
- Plusieurs shaders sont assignés > shaders Redshift > map color assignée dans l’hardwareShader du sh “wood” et “hinge

Le modèle Test:
- L’uvSet qui était en 1003 se trouve maintenant en 1001 avec 1 shader


Conclusions:
- Il se base vraiment sur les meshs.
- Ne prend pas en compte les shaders assignés
- Si un uvSet a simplement changé de coordonnées d’udim, en sélectionnant le bon udim d’origine ca fonctionne.

---

**Conclusions Globales:**

-Il faut que les maps soient pluggées dans un Lambert. Ne fonctionne pas sur les shaders Redshifts.
-Il ne prend pas en compte le fait que plusieurs meshs peuvent avoir des shaders différents > logique on transfert un map mais c’est bon à savoir ^^.
-Ne pas avoir d'action sur les meshs > Voir cas "Borders".
-Les codes udims ne sont pas prit en compte > donc transférer une map à la fois.
-Le changement de coordonnées d’udims ne pose pas de problème seulement si l’ensemble des uvs à l’intérieur de l’uvSet ne change pas.
-Il faut traiter les meshs séparément si ceux là ont leurs uvs divisés sur plusieurs uvSets.
-Il faut effectuer le transfert plusieurs fois, si à l’origine le mesh a ses uvs sur 2 udims et que la nouvelle version du mesh a ses uvs sur le même uvSet. 1 transfert par Udim d’origine.
-Se mettre en ObjectSpace.

---

### **Application sur l'asset "Bark01"**

Prenons le cas 2, où seul le layout D'uvs et d'udim a été modifié.

- Chaque mesh a ses uvs réuni sur un même uvSet.
- Les ensembles d'uvs ont été à peu près conservés.
- Chaque ensemble est indépendant, sur l'udim 1001.
- Chaque ensemble a son propre shader, aura ses propres nodes de files et sa propre arborescence.


**Pour la coque:**

Mode Object Space
Map 2K
PNG
File > 0 code udim

- Faire un premier transfert pour récupérer la texture (dif) de l'extérieur de la barque.
- Faire un deuxième transfert pour récupérer la texture (dif) de l'intérieur de la barque.
- Faire à nouveau ces 2 transferts pour les maps de bump et de spec.

Au total, il y a **6 transferts** à faire.

Une fois les maps créées, dans Ps, faire le patchwork pour assembler les 6 maps et créer les 3 maps finales.


**Pour les Borders et le seat:**

- Faire un premier transfert pour récupérer la texture (dif) de la premiere partie des uvs des 2 meshs > via la map 1001.
- Faire un nouveau transfert pour récupérer la texture (dif) de la deuxième partie des uvs des 2 meshs > via la map 1002.
- Faire à nouveau ces 2 transferts pour les maps de bump et de spec.

Au total, il y a **6 transferts** à faire.

Une fois les maps créées, dans Ps, faire le patchwork pour assembler les 6 maps et créer les 3 maps finales.


**Pour les meshs de l'intérieur, la proue et le gouvernail:**

Ces différents meshs l'intérieur, la proue, la charniere) étaient déjà rassemblés sur un même uvSet, en 1003.
Cet ensemble a été conservé et déplacé en 1001.
Le gouvernail lui était assemblé avec la coque en 1001, je l'ai rajouté.

- Faire un premier transfert pour récupérer la texture (dif) du gouvernail > via la map 1001.
- Faire un nouveau transfert pour récupérer la texture (dif) de l'ensemble des autres mshs > via la map 1003.
- Faire à nouveau ces 2 transferts pour les maps de bump et de spec.

Au total, il y a **6 transferts** à faire.

Une fois les maps créées, dans Ps, faire le patchwork pour assembler les 6 maps et créer les 3 maps finales.


**Conclusion:**

- Création de 18 maps (18 transferts) > qui donneront 9 maps finales, 3 pour chaque uvSet (3 diffuses, 3 bump, 3 spec).
- 4 shaders
- 1 PSD

**Test de Rendu:**

Toujours cette question du "Color Space" à discuter.
Pour l'instant les maps de Diffuse doivent être en Raw pour matcher à l'original.

Les shaders n'ont pas été modifiés > même arbo que l'original.





---

### **Baking Redshift**

**Test sur l'asset "Bark01"**

Le bake de redshift passe par le système d'AOV.
Après plusieurs tests de choix d'AOV, c'est l'AOV "Diffuse Filter" qui permet de retrouver le visuel des maps originelles.

Première remarque/problème:

Le bake fonctionne sur certains meshs comme le "sol", ou le gouvernail, mais pas sur d'autres meshs comme la proue ou la coque.
Le bake ne fonctionne pas si plusieurs meshs sont sélectionnés.

**Sur la coque:** splitée sur 2 udims.

Setup:

- File > Code Udims
- Bake tool > Code Udims (U1V1)
- File Origin > Raw
- AOV Diffuse Filter (png)


Après plusieurs tests, les uvs n'étaient pas la cause, le fait de refaire la symétrie de l'objet entraînait un changement mais les maps étaient toujours dans cet état là.
Le fait d'exporter en .obj ne changait rien.
Des test sur un cube et cylindre ont eu des resultats positifs.

Le dernier test à été de combiner puis décombiner le mesh problématique avec un autre mesh comme un cube.


On retrouve bien nos 2 maps. Toute fois la colorimétrie ne match pas à l'originale.

- File Origin > Raw
- File Bake > SRGB
- File Bake > Raw


Pour palier ce problème il faut être sûr que le color management de Maya soit en linear avant de baker.
Ainsi on obtient ces maps là:


Ce qui une fois connectée dans un node de Gamma Correct donne ce ci:


Il y a une légère différence de teinte mais avec l'ajout du fresnel dans le shader cela devrait permettre de retrouver un visuel quasiment identique.

**Test sur la Barque entière**

Ce processus a été appliqué (manuellement) sur tout l'asset.
Le bake a été appliqué mesh par mesh.

Il y a au total 16 trasnferts à effectuer.
16 maps à combiner dans un psd pour recréer les 3 maps initiales.


Le problème remarqué sur la coque, c'est avéré présent sur d'autres meshs. Parfois très visible, comme les artéfacts sur la totalité de la map, par exemple sur le mesh "proue":


Parfois plus subtile, visible principalement au rendu, comme sur le gouvernail.
Sur certains ensembles d'objets combinés comme le sol, le siège, le gouvernail, il a fallut séparer les meshs combinés pour obtenir des maps sans artéfacts.
Mais après l'action de "Combiner et Décombiner", on obtient un bake propre de la map d'origine:


Au final, après avoir rajouté le fresnel on arrive à obtenir un rendu similaire à l'origine.


Avec le LightingNeutral.


Au niveau de l'arborescence


---

### **Test Baking sur Pirata:**

Questions:

-Est ce que le bake va prendre en compte les blends materiaux ? **Oui**
-Comment vont être appliqués les msk ? **ca applique ^^**
-Combine à faire ? **Oui**
-Est ce que les uvs en V seront pris en compte ? > **Oui**

Obligation de faire le combine avt de faire le baking.

Si baking de tout l’ensemble du shader:


Remarques:

- Bake des msk et des teintes apportées par les shader “Ears”
>Donc bake des pbs de msk
>Teintes plutot respectées

- Le fait qu’il n’y ait des maps avec qu’une info de couleur sur les udims 1002-1006 et 1012-1016, il a donc baké les infos des msk sur ces udims.

Si dans le blend on enlève les shaders ajoutés et qu’on laisse que le base color.


Remarques:

- Les oreilles ne sont plus pris en compte > normal
>Color respectée
>0 artefact vu qu’il n’y a plus de msk

- Solution simple pour les oreilles > refaire les msk propre pour eviter tout artefact sur le reste du corps.

- Solution plus avancée > Retoucher la diffuse pour intégrer les teintes des oreilles directement dans la diffuse.

**Rendu Pirata Baking + clean shaders**

- Bake de toutes les maps de Pirata.
- Clean de l'arborescence color des shaders.
- Les meshs "Bracelet" et "BeltBuckle" n'ont plus de sss dans leurs. shaders
- Le mesh "Belt" n'a plus de shader SSS mais un simple RedshiftMatérial.
- Ajout du Fresnel.


On peut constater une différence au niveau de la combi:
- Sur l'original, il y a 3 shaders de SSS avec fresnel, pluggées dans un blend
- Sur le test, il n'y a qu'un shader de SSS avec du fresnel.

Si on veut retrouver un vert plus clair le plus simple est de retoucher la map de diffuse.

**Avec le LGT Neutral.**




- La différence sur la combi est visible et due au shader, pour les autres petites différences, elles sont dues au fresnel qui n'est pas appliqué de la même manière.
Les paramètres de facing ratio sont utilisés et non l'IOR.
- Il y a, toute fois, un gain au niveau du shader



:::info
- Les différences sont dues donc aux **shaders** et non aux **maps**> le bake reproduit parfaitement les maps d'origine.

:::

---

### **Rendu Pirata Baking + Transfert Map**


---

### **Liste des étapes pour l'automatisation du Baking des maps.**

:::info
* Les maps de bump et spec n'ont aucun impact, les files peuvent être gardés.*
* Sur le mesh source > ne pas changer l'assignation des shaders.

:::

Setup des paramètres Maya:

- Output color management de Maya > Linear :heavy_check_mark:
- Aov > DiffuseFilter :heavy_check_mark:
- Aov > PNG 16bits :heavy_check_mark:
- No Animation :heavy_check_mark:
- RedShift Load :heavy_check_mark:
- Définir le nom de la map : {obj}.{UDIM}.png :heavy_check_mark:

Setup paramètres de bake:

- En mode "Selected" :heavy_check_mark:
- Définir size map : 4096x4096 :heavy_check_mark:
- Code Udim : "Mari" :heavy_check_mark:
- Unsmooth all meshes : :heavy_check_mark:

Pour chaque mesh:

- Effectuer un Combine/Separate + delete history sur chaque mesh. :heavy_check_mark:
- Selectionner le mesh :heavy_check_mark:
- Détecter les UDIMS :heavy_check_mark:
- Isolate mesh: :heavy_check_mark:
- Bake : `/TMP_BAKE/{AssetName}_{VariationNAme}_{ShaderName}_{Objet}_{Padding}_{File}_{DiffuseFilter}.{UDIM}.png` :heavy_check_mark:
- Bake maya avec un ramp blanc et un lambert :heavy_check_mark:
- Déplacer le bon UDIM dans `/OUTBAKE/` :heavy_check_mark:
- Supprimer le contenu du dossier `TMP_BAKE` :heavy_check_mark:

Setup de Shader:

~~Le file de diffuse doit être en mode Udim.~~
- Si fresnel: overrider le fresnel de l'arborescence en noir (perpendicular color). :heavy_check_mark:
~~> le color correct de la diffuse doit être directement pluggé dans la color du shader~~

Après bake: dans Maya:
- Duppliquer shader de base, rajouter "BAKE_" dedans en prefix :heavy_check_mark:
- Import arbo fresnel nouvelle :heavy_check_mark:
- Réinjecter nouveau file dans l'arbo (udim), raw :heavy_check_mark:
- Connecter dans la color :heavy_check_mark:

:::info
La personne doit rerégler le fresnel.
Dans le cas d'un shader complexe (type blend), la personne doit retrouver le bon shader.
:::

Puis > créer un PSD qui regroupe les UDIMS similaires.

### **Etapes Photoshop Post Bake:**

**Patchwork à faire au niveau des maps bakées:**

- Setter le document
- Set taille en 2048
- Setter en lineaire (vérifier profil)
- Pour chaque file du dossier udim:
- Importer file
- Importer son masque
- Sélectionner la couleur blanc
- Créer un masque à partir cette couleur sur le file
- Delete le masque
- Save Psd.
- Save PNG 16bits.

### **Liste des étapes pour l'automatisation du Transfert Map.**

Scene de l'asset dont les uvs ont été refait.
Importer l'asset référence.

Renommer le top node en "SRC".

- Détecter l'objet source en fonction du target.
- Pour chaque objet, src, dst:
- pour chaque UDIM src:
- Déplacer les udim en 1001 sur la src, puis dst
- Pour chaque Passe du shader de l'objet src:
- Set File (de la passe) Node (UDIM en cours) dans un lambert
- Setup transfert map:
> Type of map : {passe}
> Output fileName : `{AssetName}_{VariationNAme}_{ShaderName}_{TM}_{Objet}_{Padding}_{File}_{Dif}.{UDIM}.png`
> File format : exr
> Assign new shader : True
> Object space : True
> Sampling quality : High
> Size : 4k
- Maya message récapitulatif : Nb de transfert effectués, Nb de transferts non effectués

### **Etapes Photoshop Post Transfert Map:**

- Profil à setter en Lineaire.
- Profil document à setter en Lineaire.

Une fois le patchwork terminé:

- Document à passer en 16bits.
- Save en PNG.

### **Etapes Maya Post Transfert Map:**

- Relink des maps (Raw).
- Clean shader + ajout fresnel.

---

### **Liste SC Template Ps:**

- ~~Checker le Color Profil > doit etre linéaire~~ // ne marche pas
- Checker le doc en 16bits :heavy_check_mark:
- Checker la résolution du doc > uniquement 1024-2048-4096 autorisés :heavy_check_mark:
- Checker les nomenclatures des dossiers CamelCase > "ExtraName", "Map", "Padding". :heavy_check_mark:
- Checker les nomenclatures des udims > (pas d'udims en 1011-1021 etc)
- Checker si la nomenclature des maps correspond aux dossiers > spc avec spc :heavy_check_mark:
- Si le dernier groupe possède plus d'un enfant, passe ps le validate :heavy_check_mark:

### **Liste build Template Ps:**

- ~~Check/set cas échéant le Color Profil > doit etre linéaire~~ La fonction ne marche pas sur shotgun.
- Set le doc en 16bits :heavy_check_mark:
- Set doc format 2048k :heavy_check_mark:
- Créer la hierarchie 4 niveaux (EXTRANAME/UDIM/TEXTURE/PADDING) :heavy_check_mark:
- Setter le layer importé en layer dynamique :heavy_check_mark: