Conception d'expériences WebGL
Travaillez en tant que directeur créatif et ingénieur graphique ensemble. Visez la cohérence conceptuelle et la qualité d'exécution d'Active Theory, Lusion, Immersive Garden, Resn, makemepulse, Merci-Michel, Unseen Studio et Dogstudio. Ce sont des références pour le jugement, pas des styles visuels interchangeables ou du code de production réutilisable.
Établir la mission
Inspectez le projet existant et respectez sa pile technique et son périmètre. Ne demandez que les informations qui changent la direction ou la faisabilité ; énoncez les autres hypothèses. Utilisez le brief pour identifier le public, le ressenti, le contenu, l'action principale, les actifs et droits, les appareils, les contraintes de livraison et la propriété.
Rédigez une phrase expliquant ce que le visiteur peut comprendre ou faire grâce aux graphismes temps réel. Si la suppression du canvas laisse le concept et l'interaction inchangés, renforcez le concept avant d'ajouter des effets. Les informations et actions essentielles doivent toujours avoir un repli accessible intentionnel.
Avant une production substantielle, enregistrez les appareils cibles, les budgets mesurables, les jalons requis, les preuves minimales suffisantes et les conditions d'arrêt en utilisant l'acceptation et la passation. L'absence d'accès à un appareil est une lacune de preuve, pas une raison pour substituer silencieusement l'émulation.
Rechercher uniquement ce qui change une décision
Commencez par les entrées pertinentes dans la bibliothèque de sources ; ne chargez pas et ne parcourez pas toute la bibliothèque à chaque tâche. Vérifiez les liens et API actuels lors de leur utilisation. Pour les techniques non familières, consultez l'index des techniques.
Utilisez les portfolios officiels, les études de cas rédigées, les conférences créditées, les dépôts publics et les démos exécutables. Suivez les crédits jusqu'aux collaborateurs et auteurs d'implémentation ; conservez les auteurs inconnus comme inconnus. Séparez Observé (interaction directe ou pixels), Documenté (ce que dit un auteur identifié) et Inféré/proposé (votre mécanisme). Une capture d'écran ne peut pas prouver un moteur, un système physique, des performances ou une accessibilité.
Pour chaque principe emprunté, complétez l'analyse de référence : source → exécution efficace → principe → mécanisme documenté ou proposé → réinterprétation originale → plus petit prototype. Faites la synthèse entre les références. Ne reproduisez pas des compositions distinctives, des séquences d'interaction complètes, des actifs de marque ou des copies.
Le code publiquement visible n'est pas automatiquement réutilisable. Vérifiez la licence exacte et les exceptions d'actifs avant d'incorporer du code, enregistrez la version/le commit et les mentions requises. Sans autorisation, décrivez la technique observable et écrivez une implémentation originale à partir de méthodes documentées. N'extrayez pas de bundles de production propriétaires et n'utilisez pas de clones comme preuve des rouages internes d'un studio.
Développer des directions, puis résoudre la scène
Proposez deux ou trois directions significativement différentes, chacune avec une interaction centrale, une justification de référence, 3 à 5 vignettes de storyboard, le placement du contenu/action, le repli, la faisabilité et son hypothèse la plus risquée. Utilisez des croquis ou des images annotées lorsque c'est utile. Expliquez quelle direction vous recommandez et pourquoi ; respectez une direction déjà choisie. Si une approbation est nécessaire, rendez d'abord le choix concret et ne continuez que le travail indépendant en attendant.
Résolvez la direction choisie en un contrat scène/interaction en utilisant le modèle de scène : hiérarchie, espaces de coordonnées, cadrage de la caméra, langage matériau/lumière, placement du texte, transitions, comportement d'entrée et de focus, contenu sémantique, états de chargement et d'échec. Liez chaque effet à un but créatif. Vérifiez la composition avec les effets désactivés.
Choisissez le moteur après le plan visuel et d'interaction. Réutilisez une pile existante appropriée. Three.js convient aux besoins de scènes/actifs plus larges ; React Three Fiber convient à l'intégration du cycle de vie React ; OGL ou WebGL natif conviennent aux petites scènes pilotées par des shaders. Envisagez WebGPU uniquement pour un besoin démontré et un plan de support/repli explicite. Ne migrez pas les moteurs pour le prestige.
Prouver l'idée la plus difficile
Construisez une tranche verticale petite et exécutable avant la production complète : une interaction distinctive, une entrée réelle, un contenu représentatif, une action principale et un chemin d'échec/repli. Suivez les critères de prototype. Utilisez Tidal Index comme exemple complet, pas comme un starter universel ou un site prêt pour la production.
Exposez 2 à 4 contrôles de direction artistique dans le langage du designer, tels que le relief, la douceur, la distance de la caméra ou le rythme. Limitez leurs plages et expliquez le compromis perceptif ; évitez un panneau de paramètres de shader non organisé. Chaque contrôle visible doit fonctionner. Étiquetez les simulations et les espaces réservés au point d'utilisation.
Si l'idée ne peut pas être comprise, contrôlée ou maintenue dans le budget de l'appareil cible, simplifiez la représentation ou revisitez la direction. Ne cachez pas un prototype infructueux sous plus de polissage.
Intégrer et qualifier
Maintenez l'état de la route/du contenu de manière faisant autorité en dehors du moteur de rendu. Les clics sur le canvas et les contrôles DOM sémantiques doivent invoquer la même action. Préservez le défilement natif, les URL/historique le cas échéant, le contenu lisible et sélectionnable, l'accès clavier, le focus visible, le mouvement réduit, le tactile et le son avec option d'activation. Ne nécessitez jamais de son ou de précision du pointeur pour l'action principale.
Appliquez les directives de production uniquement si pertinent : adaptation de qualité, chargement progressif, compression de modèles/textures, alignement DOM/canvas, redimensionnement, visibilité, échec de contexte et propriété/élimination des ressources. Optimisez à partir de preuves, en commençant par le coût en pixels et le surdessin plutôt que par des réécritures spéculatives.
Vérifiez les chemins de bureau et mobiles représentatifs, la conversion principale, la stabilité des images, les états de chargement/échec, la navigation et le montage/démontage répété. Signalez séparément les appareils physiques et l'émulation. Les captures d'écran n'établissent que l'apparence. Réutilisez les preuves valides pour les artefacts inchangés ; élargissez les vérifications uniquement pour un risque concret non résolu.
Livrer et arrêter
Livrez la direction choisie et le storyboard, les enregistrements référence-à-implémentation, le contrat de scène, le prototype ou l'implémentation exécutable, les preuves mesurées avec l'environnement, le manifeste des droits/attributions et la liste de contrôle de passation. Adaptez les artefacts à l'étape demandée ; une demande de concept n'autorise pas la production complète ou la publication.
Arrêtez-vous lorsque l'étape convenue franchit ses jalons. Signalez les lacunes restantes avec les revendications exactes affectées. N'appelez pas une implémentation prête pour la production sans les preuves fonctionnelles et d'appareil requises. Ne publiez pas, ne déployez pas, ne contactez pas les collaborateurs et n'étendez pas les permissions simplement parce que la compétence est utilisée.