unity-technologies/migrate-birp-vers-urp

Classez la demande, inspectez l'état actuel du projet, choisissez le bon chemin de migration et validez soigneusement le résultat de la migration de BiRP vers URP.

Référence d'exécution obligatoire

Pour toute migration ou réparation réelle, lisez references/implementation-patterns.md avant le premier appel eval qui modifie les paramètres du projet, les matériaux, le post-processing, l'éclairage, les sondes ou les scènes. Ceci est obligatoire même pour des invites courtes comme "migrer ce projet vers URP" lorsque la sécurité de restauration est déjà confirmée.

Si cette ressource ne peut pas être chargée, utilisez les règles intégrées de ce SKILL.md et réduisez votre niveau de confiance : n'affirmez pas la conversion PPv2, l'actualisation de l'éclairage/des sondes ou l'achèvement de la migration à partir de l'intention ou des seuls journaux d'outils.

Valeur par défaut critique

Pour des demandes simples comme "migrer ce projet Built-in vers URP" ou "transférer ce projet vers URP", démarrez ou reprenez le workflow de migration sécurisé plutôt que de passer directement à la conversion.

Une invite de mise à niveau générique ne doit pas obliger l'utilisateur à mentionner tous les risques de migration. Inspectez et gérez les dépendances Built-in courantes telles que PPv2, l'éclairage/lightmaps cuits, les sondes de réflexion, les matériaux particules/brouillard/fumée, les niveaux de qualité, le post-processing des caméras et la validation de scènes représentatives.

Le résultat par défaut est basé sur des phases :

1. Détectez si le projet est Built-in, partiellement migré, déjà URP ou HDRP.
2. Classez la demande comme URP 3D standard, URP 2D, conversion de matériaux sélectionnés, planification uniquement ou dépannage.
3. Inspectez les risques de migration avant de recommander des modifications : matériaux opaques, matériaux particules/VFX, shaders personnalisés, post-processing, effets de caméra, éclairage/lightmaps/sondes de réflexion cuits, niveaux de qualité et scènes représentatives.
4. Arrêtez-vous avant tout travail de mutation du pipeline jusqu'à ce que l'utilisateur confirme un point de restauration tel qu'une branche, une sauvegarde, une archive ou une copie jetable. Le travail de mutation du pipeline comprend l'installation d'URP, l'affectation d'un asset URP dans les paramètres Graphics/Quality, l'exécution des convertisseurs et la modification des matériaux ou des scènes.
5. Choisissez la phase de migration suivante, exécutez cette phase, sauvegardez/requérez ses sorties et rapportez son statut de phase.
6. Traitez les shaders personnalisés, GrabPass, les Surface Shaders, OnRenderImage, les shaders de remplacement et les shaders appartenant à des packages comme un travail de suivi limité, et non comme un travail de conversion automatique.
7. Validez les scènes représentatives, la sortie Console, le rendu de la caméra, l'état de l'éclairage/GI cuite, les matériaux, la persistance du post-processing et les affectations des niveaux de qualité avant de déclarer le succès complet de la migration.

Phases par défaut :

• Phase 0 : Inspectez et planifiez. Détectez l'état du pipeline, les scènes représentatives, la sécurité de restauration, PPv2, les risques matériaux/shaders, les niveaux de qualité, l'état de l'éclairage/lightmap/sonde et le code de rendu personnalisé.
• Phase 1 : Configuration URP et conversion de matériaux prise en charge. Installez/réutilisez URP, créez/affectez des assets URP dans Graphics/Quality, convertissez les matériaux opaques et particules/effets pris en charge, et vérifiez qu'aucun matériau pris en charge ne reste sur des shaders Built-in.
• Phase 2 : Migration du post-processing et de la caméra. Créez des profils Volume URP persistants, connectez les Volumes de scène/le post-processing de la caméra, désactivez le PPv2 hérité pour la validation URP, et classez les effets PPv2 non pris en charge comme SSR.
• Phase 3 : Éclairage, lightmaps et sondes de réflexion. Résolvez l'état d'éclairage Built-in obsolète, configurez les paramètres d'éclairage/sonde URP, recuisez/actualisez lorsque c'est faisable, ou marquez clairement l'éclairage/les sondes comme partiels.
• Phase 4 : Validation finale et rapport. Sauvegardez/rechargez/requérez l'état du projet, capturez les scènes représentatives, vérifiez la Console et rapportez les éléments complets/incomplets/manuels.

Un seul tour peut terminer plusieurs phases si le projet est petit et qu'Unity reste stable, mais ne forcez pas toutes les phases en une seule réponse. Privilégiez une limite de phase honnête plutôt qu'un résultat "complet" exagéré.

Posez des questions de configuration uniquement lorsque l'état du projet ou l'intention de l'utilisateur laisse une décision réelle non résolue. Si l'utilisateur dit "ne pas modifier les fichiers", restez en mode audit/planification et n'effectuez pas de conversion ou de modification d'assets.

Contrat de mise à niveau générique

Lorsque l'utilisateur donne une demande de migration générique et autorise les modifications, pilotez la phase suivante à partir de l'état du projet :

1. Ne demandez pas à l'utilisateur d'énumérer les fonctionnalités Built-in connues avant l'inspection. Découvrez-les.
2. Si PPv2, l'éclairage cuit, les sondes de réflexion, les matériaux particules/brouillard/fumée ou plusieurs niveaux de qualité existent, incluez-les automatiquement dans la migration.
3. Préférez l'achèvement de phase à l'achèvement tout-en-un. Chaque phase doit sauvegarder/requérir ses propres sorties et se terminer par Phase complete, Phase partial ou Blocked.
4. Si la compilation Unity, l'installation du package, le rechargement de domaine ou une longue cuisson d'éclairage interrompt la passe, signalez l'interruption comme une limite de phase et reprenez à partir de l'état partiel sauvegardé au tour suivant plutôt que de recommencer.
5. Ne comptez pas sur l'utilisateur pour écrire une invite de liste de contrôle détaillée pour obtenir un comportement correct. La liste de contrôle détaillée est destinée aux tests de performance ou aux tests de stress ; les invites utilisateur normales doivent toujours déclencher ce contrat par phases.
6. Une demande de migration générique donne la permission d'inspecter et de planifier, mais elle ne prouve pas la sécurité de restauration. Si aucun point de restauration n'est confirmé, arrêtez-vous avant l'installation du package ou l'affectation URP et demandez une confirmation. Ne laissez pas le projet dans un état magenta partiel juste pour atteindre la question de sauvegarde.
7. Si la sécurité de restauration est déjà confirmée ou si l'utilisateur dit que le projet est une copie jetable, continuez dans la phase actuelle sans redemander pour le travail de routine.
8. À la fin d'une phase, donnez une invite concise pour la phase suivante ou dites quelle phase doit s'exécuter ensuite. Demandez une confirmation avant la phase suivante uniquement lorsqu'elle introduit une nouvelle opération coûteuse ou risquée, comme une longue cuisson d'éclairage, la suppression/nettoyage d'assets hérités ou une réécriture de shader personnalisé.
9. Si la sécurité de restauration a été confirmée et que le travail ordinaire dans la phase active reste incomplet, ne demandez pas "souhaitez-vous que je continue ?" Continuez à réparer cette phase jusqu'à ce que sa porte passe, une limite d'outil/rechargement de domaine interrompe l'exécution, ou une nouvelle décision vraiment risquée apparaisse.

Porte de succès de migration générique

Avant de dire qu'une migration générique est "réussie", "complète" ou "entièrement migrée", vérifiez l'état sauvegardé du projet, pas seulement les journaux d'outils :

1. Les paramètres graphiques et chaque niveau de qualité pertinent pointent vers l'asset URP prévu.
2. L'asset URP a un renderer par défaut valide dans l'état sauvegardé, et la sortie Console actuelle ne contient pas d'erreurs de pipeline de rendu non résolues telles que "Default Renderer is missing". Si une erreur de renderer apparaît après l'affectation, reconsultez la liste des renderers sauvegardés/l'index par défaut, effacez la sortie Console obsolète lorsque c'est possible, déclenchez une nouvelle validation de scène/caméra et continuez la réparation au lieu de vous arrêter à "configuration URP terminée".
3. Les matériaux Built-in pris en charge, y compris les matériaux particules/brouillard/fumée, ont des shaders compatibles URP ou sont explicitement répertoriés comme des cas de shaders personnalisés/package non résolus. Les matériaux sources texturés/colorés doivent conserver leurs textures/couleurs sources ; une affectation de shader URP avec _BaseMap manquant ou _BaseColor tout blanc est incomplète si la source _MainTex ou _Color avait du contenu. Les matériaux d'effets particules, brouillard, fumée, vapeur, decal, VFX, additifs et transparents ne doivent pas être forcés aveuglément à Universal Render Pipeline/Lit ; préférez les shaders particules/effets URP tels que Universal Render Pipeline/Particles/Unlit lorsque c'est approprié.
4. Si la scène source utilisait PPv2, un profil Volume URP sauvegardé doit exister, connecté au Volume global de la scène, et les effets PPv2 non pris en charge (par exemple, Depth of Field, SSR) doivent être marqués comme manuels ou supprimés de la configuration.