HyperFrames 分镜下游预演适配

Adaptation de prévisualisation en aval des storyboards HyperFrames

Version d'adaptation 0.4.0. Entrée STORYBOARD_PREVIS_ADAPTER_V1, validation d'état JSON SCOPED_STATE_V2 ; identité de rendu PREVIS_RENDER_CONTENT_V2. Compile le script-maître livré par script-to-storyboard-prompts en une prévisualisation 3D éditable et révisable, en conservant les numéros de segments, le script-maître et la version budgétaire d'origine. Three.js gère les scènes et les animations, HyperFrames exporte image par image.

Démarrage

Lisez d'abord references/upstream-adapter.md pour localiser le projet upstream explicite de l'utilisateur, les segments formels, la version valide du script-maître et la version budgétaire ; lisez le texte réel, l'analyse des scènes, les assets des personnages/décors/accessoires et les états textuels de début et fin. L'entrée peut être un fichier projet ou une livraison session localisable, et ne peut pas exiger de l'upstream de produire une feuille de storyboard indépendante supplémentaire.

Héritez du cadre, du style complet, de la durée maximale des segments, de la durée calculée réelle, de l'ordre des plans, de la taille en centimètres, de la version du modèle, de l'orientation spatiale, des dialogues d'origine, des responsabilités audio et des points de révélation déjà confirmés. Ne demandez pas à nouveau les éléments déjà confirmés, et n'utilisez pas le 16:9/12 secondes des anciennes démonstrations comme valeurs par défaut du projet. Si la résolution de rendu et le fps ne sont pas spécifiés, vous pouvez choisir une taille paire adaptée au cadre et 24 fps, et les enregistrer comme paramètres techniques de prévisualisation ; cela ne doit pas modifier le budget ni ajouter d'éléments narratifs. Ne demandez de manière centralisée que les éléments manquants qui affectent cette adaptation.

Les sept étapes upstream et la couverture des segments formels continuent d'être gérées par l'upstream. Cet adaptateur lit l'état faisant autorité, écrit ses propres fichiers dans <projet>/previs/<ID_formel>/<version_prompt>, et ne modifie pas next_required, le curseur, la couverture, le script-maître ou le budget de l'upstream. Lorsque l'utilisateur dit simplement « continuer », exécutez l'objectif courant de l'upstream ; n'intervenez que si la demande courante inclut une prévisualisation ou si l'utilisateur a clairement choisi une livraison de prévisualisation. Dans le cadre d'une demande de prévisualisation autorisée, la lecture, la construction, la vérification et l'exportation peuvent être effectuées en continu.

Prend en charge les livraisons textuelles existantes (état 1.8/V3) et les projets JSON (état 1.9/V4). Pour le JSON, utilisez scripts/intake_storyboard.py en lecture seule ; pour le texte libre / session, l'agent lit et organise réellement, utilise scripts/finalize_manual_intake.py pour sceller les preuves réelles, et ne migre pas automatiquement ni ne devine l'analyse des anciens états. Le déroulement normal des autres segments n'invalide pas automatiquement le segment cible ; une nouvelle adaptation est effectuée lorsque la version de ce segment, les assets associés, les états de début/fin ou le texte source choisi changent. Pour l'ancien intake STATE_JSON, si les données de portée nécessaires manquent, demandez une nouvelle extraction explicite, sans mise à niveau silencieuse.

Utilisez la géométrie la plus simple suffisante pour vérifier la composition, le positionnement, les obstructions et le timing. Les codes couleur stables correspondent aux personnages upstream ; l'environnement ne conserve que les espaces et les points de repère pertinents. Si des actions détaillées sont nécessaires, utilisez des modèles sous licence. Les responsabilités d'image, d'action et de caméra sont séparées ; l'adaptateur ne promet pas qu'une prévisualisation simplifiée forcera le modèle aval à suivre chaque pixel.

Réalisation et modification

1. Réception et mappage. Conservez formal_id, prompt_version, budget_version, l'ID des assets, l'ID des plans et les intervalles de temps upstream. Traduisez « échelle de plan / position de caméra », « mouvement de caméra / sujet filmé », « composition » et « contenu de l'image » en échelles géométriques, caméra, point de visée et échantillonnage temporel absolu ; marquez les coordonnées non spécifiées comme « à compléter par exécution » sans re-réaliser. Tous les plans et actions sont relatifs à la seconde 0 du segment formel courant ; une phase continue sans coupe n'est pas divisée en coupes multiples.
2. Construction de l'espace unifié. Utilisez le système métrique, Y vers le haut, avec indication des orientations. Créez la scène, l'ID stable des personnages, l'appartenance des accessoires, les portes/fenêtres comme structures dynamiques. L'apparence des personnages est distinguée par des codes couleur clairs ; fournissez des échelles géométriques pour éviter de deviner les proportions uniquement par l'image.
3. Création d'animations à évaluation déterministe. Les poses, positions, caméras et états des portes à n'importe quelle image doivent être déterminés uniquement par t. N'utilisez pas de déplacement cumulatif, de nombres aléatoires non fixés ou d'état de l'image précédente pour piloter l'exportation. Les animations utilisent AnimationMixer.setTime(t) ou un échantillonnage absolu similaire. Le minuteur du navigateur ne peut appeler que le même renderAt(t).
4. Vérification et ajustement. Vérifiez plan par plan le script-maître, les points de coupe et les états de début/fin ; utilisez la sélection d'images, la ligne de temps, l'observation libre, l'édition du FOV/caméra et des points clés de trajectoire. Le template ne prévisualise que la trajectoire du plan courant, sans modifier le nombre de plans ni le budget. Les plans/positionnements confirmés peuvent être verrouillés explicitement ; l'annulation locale ne revient qu'à la modification conservée la plus récente de la cible correspondante. Les changements impliquant des faits photographiques réels, des éléments narratifs, la durée, les dialogues ou les révélations sont renvoyés à l'upstream pour révision, et ne peuvent pas être remplacés par un template qui remplace l'intention du réalisateur. Voir Édition et retour d'image.
5. ** Vérification et exportation. ** Effectuez des vérifications des données et des sources, un échantillonnage spatial de l'agent, une exportation image par image réelle, et vérifiez les spécifications vidéo, les états de début/fin et les points de coupe. Ne vérifiez la présence à l'écran que pour les framing.requiredActors explicitement indiqués ; les avertissements spatiaux doivent être confirmés visuellement ; ne remplacez pas la validation du média par un programme sans avertissement. Les annotations incluent le PNG réel, le timecode dans le segment, l'ID des objets, les coordonnées et la source ; si la source change, marquez comme obsolète, séparez le traité du validé.
6. Retour du produit d'adaptation. Livrez la vidéo propre, le projet source, le mappage des sources, une copie textuelle du script-maître original, les instructions supplémentaires sur les assets de référence et l'accusé de réception de vérification réelle. Le script-maître upstream ou les adaptations existantes des modèles continuent d'être la source des prompts ; ne les remplacez pas par des prompts courts générés automatiquement par un template. L'accusé de réception ne représente que la vérification locale de la prévisualisation ; la soumission finale du modèle et la capacité de génération restent traitées par l'adaptation du modèle correspondant.

Point de départ réutilisable

assets/starter/ est un exemple d'exécution, contenant une page de révision, un échantillonnage temporel absolu, la sauvegarde et l'exportation. Les couloirs, les personnages, les accessoires, les trois plans et l'événement d'ouverture de porte sont des démonstrations ; lors de la réception des données upstream, remplacez la géométrie et les actions par l'entrée réelle, sans réutiliser automatiquement ces éléments narratifs. S'il n'y a pas d'image, vous pouvez utiliser des codes couleur comme placeholders basés sur le texte valide, en vérifiant uniquement l'espace et le timing.

node <dossier-skill>/scripts/create_project.mjs <dossier-projet>
python -X utf8 <dossier-skill>/scripts/intake_storyboard.py --state <état upstream JSON> --budget <budget upstream JSON> --formal-id FORMAL_1 --out <dossier-projet>/upstream-intake.json
cd <dossier-projet>
npm install
npm run prepare-libs

Après avoir lu le script-maître complet, matérialisez d'abord les assets, plans et actions réels sous forme de scene.json et de code de scène, écrivez assetBindings, sourceAssetIds et adaptationMap. Exécutez ensuite les liaisons et vérifications suivantes, sans sauter la liaison qui ferait régresser le projet vers une branche de démonstration :

npm run bind-upstream
npm run validate
npm run studio

sourceAssetIds.scenes/props liste explicitement les ID des assets réellement utilisés dans ce segment ; écrivez [] s'il n'y en a pas. Les personnages sont liés via assetBindings avec la version LOOK/STATE et la taille en centimètres. Les vérifications numériques, de version et de dépendances ne remplacent pas la vérification sémantique de l'histoire, des dialogues et de la photographie.

studio.html pour la révision, index.html pour l'exportation propre. Cliquez sur un personnage pour le sélectionner ; cliquez sur une zone vide pour sélectionner un plan. La sauvegarde d'un seul plan/point clé n'incorpore pas d'autres ébauches ; les conflits sont clairement signalés. Le verrouillage est imposé par le serveur ; l'annulation locale conserve 100 historiques ; les conflits dus à des modifications externes sont refusés. Pour la capture, sauvegardez ou annulez d'abord l'ébauche de la caméra, revenez à la caméra formelle, masquez la boîte de sélection et alignez-vous sur la trame vidéo.

npm run lint
npm run spatial-check
npm run snapshot
npm run render
npm run handoff
npm run feedback
node scripts/bundle.mjs --project . --out <nouveau répertoire de livraison hors projet>

Les commandes ci-dessus sont définies dans le package.json du template. Les dépendances sont figées sur HyperFrames 0.9.10 et Three.js 0.187.0 vérifiés ; un nouvel environnement peut les mettre à jour, mais vérifiez d'abord l'API officielle actuelle, puis répétez l'exportation avec vérification, sans seulement modifier le numéro de version.

Voir Contrat de scène pour les champs, Adaptation upstream pour les sources/révisions, Édition et retour d'image pour le verrouillage/annulation/annotations/vérification spatiale. Consultez si nécessaire Exécution du rendu, Livraison de retour et Livraison portable. Les conceptions adoptées et reportées sont détaillées dans Fondements de conception ; aucun besoin d'utiliser des dépôts externes comme précurseurs de production.

Critères de livraison

• Les actions narratives sont reconnaissables, et les personnages/caméras/accessoires ont une continuité justifiée entre les plans. Vérifiez réellement l'axe, les obstructions et les artefacts de modélisation ; si un changement d'axe est intentionnel, expliquez quels plans établissent la direction.
• Le même instant donne le même état en lecture séquentielle, en saut direct et en saut arrière ; vérifiez au moins un échantillonnage non séquentiel, par exemple 8 → 2 → 8.
• Les dialogues et le temps audio originaux sont entièrement conservés dans le mappage et l'accusé de réception ; si l'audio n'est pas mixé, les lèvres non synchronisées ou les actions complexes non implémentées, mentionnez explicitement ces éléments non vérifiés. L'état des prompts d'assets, de la présence des images, de la lecture des images et de la liaison des modèles sont enregistrés séparément.
• Les segments formels sont exportés indépendamment par défaut ; pour les assemblages inter-segments ou les décalages, une demande correspondante est nécessaire, et le mappage de décalage est enregistré séparément. Les limites de fichiers ne deviennent pas automatiquement des coupes, les événements des segments précédents ne sont pas répétés, et le budget n'est pas prolongé ou arrondi ; les résidus non entiers doivent enregistrer explicitement le mappage entre l'horloge source et l'horloge de la vidéo finale.
• L'exportation utilise les données de plan après sauvegarde. La première image est entièrement chargée, sans image noire, ressource manquante, interface de révision ou rémanent de point de coupe.
• L'exportation est d'abord mise en cache et vérifiée avant d'être publiée ; en cas d'échec, conservez l'ancienne vidéo réussie. Le verrouillage, l'écriture de l'historique et les annotations ne modifient pas l'identité de l'image ; seuls les changements substantiels de caméra, de trajectoire, de modèle ou de code rendent les preuves de l'image ancienne obsolètes. La révision nécessite toujours la cohérence des quatre aspects. L'annotation VERIFIED signifie seulement que l'utilisateur a enregistré une preuve distincte, et ne remplace pas la validation du média par le modèle final.
• La génération du modèle réinterprète les matériaux, les membres et les détails. Indiquez clairement « l'intention de composition et d'action à conserver impérativement » et « la performance et la texture à naturaliser », sans promettre un contrôle au niveau du pixel ou du squelette.
• Le rapport final indique le périmètre réellement réalisé et vérifié. Si les références de personnages ne sont pas fournies ou si le modèle aval n'est pas exécuté, ne décrivez pas les personnages en blocs de couleur comme une vérification de la cohérence des personnages, et ne décrivez pas la sortie de la prévisualisation comme le rendu final.