Le jour où nos shaders ont disparu du build

Dans l'éditeur Unity, tout était parfait. Dans le build final : des surfaces roses et des effets manquants. Bienvenue dans l'un des pièges Unity les plus vicieux — et chez quelques-uns de ses cousins.

Le shader stripping. Au moment du build, Unity jette tout ce qui ne semble servir à rien — shaders compris. Le problème : si on charge des shaders à l'exécution via Shader.Find() (comme nous avec nos plus de 20 shaders maison pour l'eau, l'atmosphère, les hologrammes et bien d'autres), Unity ne voit aucune référence à eux dans aucune scène. Résultat : le shader est là dans l'éditeur et disparaît dans le build. La solution n'a rien de spectaculaire, mais elle est indispensable : chacun de ces shaders doit figurer dans la liste Always Included Shaders des paramètres graphiques. Depuis, chez nous, la règle est simple : nouveau shader ? On l'ajoute tout de suite.

Le layer qui valait -1. Même catégorie : on récupérait un layer physique dans le code via son nom. Dans l'éditeur : ça marche. Dans le build en mode batch sur le serveur de build : le layer n'existe pas, la recherche renvoie -1, et tout ce qui repose sur ce layer se comporte de travers, sans le moindre bruit. Depuis, on référence les layers par leur index fixe, et non par leur nom.

La morale : l'éditeur Unity et le build final sont deux mondes différents. L'éditeur est clément — il a tous les assets, tous les noms, tous les shaders sous la main. Le build est impitoyable. C'est pourquoi, chez nous, chaque modification du client s'accompagne d'un vrai test de build en local, pas seulement du bouton Play dans l'éditeur. Ça prend plus de temps. Mais ça nous a déjà évité bien des versions embarrassantes.