immersive-3d-site

Que fait immersive-3d-site ?

Une page où la 3D est en direct, pas une vidéo de 3D. Le défilement du visiteur est la chronologie et son curseur est une seconde caméra. Le vrai texte se trouve au-dessus, lisible et sélectionnable ; le canevas WebGL se trouve derrière.

Ce que vous rendez : un dossier de build avec BRIEF.md, un vrai index.html, les fichiers du moteur à côté, et une série de captures d'écran depuis desktop, téléphone et mouvement réduit, plus un court rapport de ce que vous avez vérifié et de ce que vous n'avez pas pu vérifier.

Ce qui fait échouer ces pages

La plupart des "sites Web 3D" ne reposent que sur un seul effet pour toute la page : un modèle qui tourne avec du texte qui apparaît par-dessus. Dès la troisième section, le visiteur a tout vu et arrête de défiler. Quatre règles empêchent cela :

1. Chaque acte fait quelque chose de différent. Utilisez au moins quatre dispositifs scéniques différents parmi references/scene-kit.md, jamais le même deux fois de suite.
2. Un seul sommet. Un acte est le moment que quelqu'un décrirait à un ami. Il obtient le plus d'espace de défilement, la meilleure scène, et un acte plus calme avant lui pour que l'impact soit maximal.
3. La 3D sert le message. Chaque scène montre quelque chose de vrai sur le sujet : de quoi il est fait, comment il fonctionne, ce qu'il procure. Une scène qui n'est que décoration est supprimée.
4. Le texte reste lisible à chaque position de défilement. Si une ligne est difficile à lire sur la scène à une image donnée, c'est la scène qui bouge, pas le texte.

Étape 0 : Le brief

Réutilisez ce que l'utilisateur vous a déjà donné. S'il a fourni un brief complet ou a dit "utilisez votre jugement", écrivez BRIEF.md vous-même, marquez-le Rédigé sous délégation créative, répondez vous-même à chaque question ci-dessous dans la voix de la marque, et lancez-vous. Sinon, posez les huit questions en un seul message, comme de vraies questions, jamais un menu que vous avez inventé :

1. Qu'est-ce que c'est, à qui cela s'adresse-t-il, et que doivent-ils faire à la fin ? Une action, un libellé utilisé partout.
2. L'ambiance en trois à cinq mots, plus jusqu'à trois références venant de tout sauf de sites Web : un film, un jeu, une pochette d'album, un magasin. Citer des sites Web est ainsi qu'une page finit par en copier un.
3. Le parcours dans leurs mots : ce que le visiteur voit en premier, ensuite, en dernier.
4. Où cela doit être calme et où cela doit être intense.
5. Comment quelqu'un doit se sentir à chaque étape, et le moment unique dont il doit se souvenir. Voir references/feel.md.
6. Une chose que ce site doit faire qu'aucun site qu'ils ont vu ne fait. La graine du geste signature. Insistez pour une vraie réponse ; "être mémorable" n'en est pas une.
7. À quel point s'éloigner du premium-minimal : proposez la gamme dans references/structures.md.
8. Un monde continu, ou des scènes séparées ? La plus grande fourche structurelle, et leur décision. En plus : ce qu'ils ont déjà (logo, couleurs, polices, photos de produits, modèles 3D en .glb).

Écrivez BRIEF.md dans le dossier de build avec leurs réponses dans leurs mots, puis ajoutez :

• Le parcours : quatre à sept temps forts, chacun un changement dans ce que le visiteur sait ou ressent.
• La courbe des sentiments : une ligne par temps fort, le sentiment et ce qui à l'écran le provoque. Pas deux voisins identiques.
• Le sommet : la phrase qu'un visiteur dirait à son sujet, et dans quel acte il se trouve.
• C'est le site où ___ : complété par une expérience, pas une technique.
• Le geste signature : une interaction qui n'existe que sur ce site, codée dans la page. Un dispositif de kit avec de nouveaux chiffres ne compte pas.
• Tout silence délibéré, marqué, pour que les vérifications puissent le distinguer d'un défilement mort.

Étape 1 : Structure, journal, puis notation

Trois choses, dans cet ordre. Toutes les trois avant tout code.

Choisissez une structure parmi references/structures.md : un monde, chapitres, étape produit, exposition, terrain de jeu, éditorial avec inserts, diffusion. La navigation, l'ouverture et la fermeture en découlent. Écrivez dans BRIEF.md pourquoi celle-ci et pas les autres.

Exécutez le journal d'empreinte. Lisez FINGERPRINTS.md dans le dossier qui contient vos builds (créez-le s'il manque ; il commence vide). Le plan doit différer de chaque ligne existante sur au moins quatre des éléments : structure, navigation, dispositif d'accroche, séquence d'actes, fermeture, geste signature. S'il échoue, changez le plan, pas le journal.

Notez-le. Courbe des sentiments d'abord, puis un dispositif par temps fort, sous forme de tableau dans BRIEF.md :

Temps fort	Acte	Sentiment	Dispositif	Portée	Pourquoi ce dispositif
Reconnaissance	accroche	curiosité	objet en verre + travelling	2	Le produit, vivant, avant même qu'un mot soit lu
Virage	morph	anticipation	morphing de particules	3	Le bruit devient une forme devient le nom
Sommet	rail	émerveillement	rail de caméra	3.5	Voyager à travers lui dit qu'il y a beaucoup à l'intérieur
Preuve	explosion	confiance	vue éclatée	2.5	Montre les pièces, ce qui est l'affirmation
Engagement	fermeture	calme	tenue calme	1.5	La page s'arrête et attend le clic

Vérifications avant de builder :

• Les interdictions de la structure tiennent.
• Quatre familles de dispositifs ou plus de references/scene-kit.md, jamais deux fois de suite.
• Aucun deux temps forts voisins ne partagent un sentiment.
• Le sommet a la plus grande portée, et l'acte avant lui est plus calme.
• La fermeture termine et tient au lieu de s'estomper dans un pied de page.
• Les portées sont en hauteurs d'écran. Une page cinématographique fait environ 8 à 14 ; les pages éditoriales et de terrains de jeu peuvent être plus courtes. Ne rembourrez jamais pour atteindre un nombre.

Étape 2 : Builder

mkdir -p <build> && cp <skill>/engine/stage.js <skill>/engine/stage.css <build>/

Partez de templates/starter/index.html pour la structure (import map, canvas, sections, un script module), et empruntez les motifs d'actes que vous avez notés. N'expédiez jamais le starter ou sa copie Orbis. Chaque page est écrite à partir de son propre brief.

Comment fonctionne le moteur (engine/stage.js, lisez le commentaire d'en-tête) :

• La page est une pile de <section data-act="nom" data-span="2">. Chacune contient un .frame qui reste fixe pendant la durée de la section.
• stage.act(name, { scene, camera, update(p, s), render(renderer, s), resize(w, h) }) enregistre une scène. p va de 0 à 1 sur l'acte. s transporte time, dt, pointer (lissé, de -1 à 1), velocity (vitesse de défilement), width, height, reduced, coarse.
• L'acte qui contient le milieu de l'écran est rendu. Les actes qui partagent un même objet scene sont tous mis à jour ensemble, donc un seul monde continu est simplement plusieurs actes pointant vers la même scène.
• Un acte a besoin d'une portée supérieure à 1 pour que p bouge. p est mesuré sur la distance pendant laquelle le cadre reste fixe, donc une portée de 1 exactement n'en a pas : p passe de 0 à 1 et tout ce qui y est lié ne s'affiche jamais. Utilisez 1,25 ou plus.
• Chaque section reçoit --p comme variable CSS, donc les titres peuvent bouger sur la même chronologie que la 3D.
• data-reveal sur un élément le fait apparaître en entrée ; décalez avec style="--i:2".
• Utilisez seg(p, a, b) pour diviser un acte en temps forts et ease.inOut et autres pour les façonner.
• Pas de WebGL : html.no-webgl montre le .poster de chaque acte. Donnez à chaque acte un poster (une image ou un dégradé).

Thématisez avec les tokens en haut de stage.css (canvas, surface, ink, ink-soft, accent, accent-ink, deux polices). Ne modifiez jamais le moteur pour un projet ; le comportement sur mesure va dans le script de la page elle-même.

Three.js vient d'une version CDN épinglée dans l'import map ([email protected] sur jsdelivr). Gardez l'épingle. Si vous avez besoin d'une version plus récente, choisissez-en une vieille d'au moins deux semaines et relancez les vérifications.

Lisez references/design.md avant d'écrire le balisage et references/performance.md avant d'ajouter la deuxième scène.

Étape 3 : Prouvez-le

cd <build> && npm i playwright-core          # une fois par dossier de build ; nécessite Google Chrome installé
node <skill>/scripts/serve.mjs --root . --port 4600 &
node <skill>/scripts/shoot.mjs --url http://localhost:4600 --out shots/desktop
node <skill>/scripts/shoot.mjs --url http://localhost:4600 --out shots/phone --width 390 --height 844 --touch
node <skill>/scripts/shoot.mjs --url http://localhost:4600 --out shots/reduced --reduced-motion --positions 0,1

Le script fait défiler chaque acte à cinq positions, attend que le lissage se stabilise, prend une capture de chacune, et écrit sheet.png. Il échoue en cas de : erreurs de page, requêtes échouées, absence de WebGL, un acte qui ne dessine rien, et défilement latéral. Un succès signifie qu'il tourne, pas que c'est bon.

Ensuite ouvrez chaque sheet.png et regardez. Pour chaque acte à chaque position : chaque ligne est-elle lisible ? La scène montre-t-elle ce que dit le temps fort ? Sur le téléphone, quelque chose est-il recadré, couvert ou minuscule ? Le sommet ressemble-t-il au sommet ? La fermeture termine-t-elle ? Corrigez, reprenez les captures, regardez à nouveau.

Ensuite la vérification des sentiments (references/feel.md) : faites défiler à froid, un mot par acte pour ce que vous avez ressenti, puis comparez avec la courbe dans BRIEF.md. Là où ils diffèrent, corrigez la page.

Dites clairement ce qui n'a pas été couvert : Chrome sans tête dessine le WebGL en logiciel, donc le taux d'images qu'il rapporte n'est pas celui d'un vrai appareil, et il ne peut pas vous dire comment le défilement se sent sur un vrai téléphone. Demandez à l'utilisateur de l'ouvrir sur son téléphone avant de considérer la page comme terminée.

Règles strictes

Jamais	À la place
Un seul dispositif scénique pour toute la page	Quatre familles ou plus, jamais deux fois de suite
Texte cuit dans une texture ou une image	Vrai HTML au-dessus du canevas
Une flèche de défilement, une icône de souris ou "défilez pour explorer"	Rien. L'accroche suffit
Compteurs de section comme 01 / 05	Supprimez-les
Copie centrée dans chaque acte	Variez : gauche, droite, centre, divisé, haut, bas
Un foncé en pleine écran pour le contraste	.scrim seulement derrière le bloc de texte
Texte dégradé, lueur néon sur le texte	Le poids et la taille font l'accentuation
Chiffres ou statistiques inventés	Seuls des chiffres réels de l'utilisateur
Tirets cadratins dans la copie visible	Point, virgule, deux-points
Objets qui tournent sans jamais s'arrêter	Le mouvement suit le défilement ou le curseur ; le mouvement au repos est lent et petit
Un nouveau rendu WebGL frais par section	Un canevas, un rendu, plusieurs scènes (le moteur le fait)
Expédier la page starter	Écrivez la page à partir de son propre brief
Builder avant la structure, le journal et la notation	Étape 1, les trois
Deux sommets, ou aucun	Un, avec le plus d'espace et un acte calme avant lui
Un plan qui correspond à un build antérieur sur trois colonnes du journal ou plus	Changez le plan, jamais le journal
Dire que c'est fini sans l'Étape 3	Exécutez l'Étape 3, regardez les feuilles, faites la vérification des sentiments

Résultat

Le dossier de build, puis un court rapport : la structure et pourquoi, le résultat de l'empreinte contre chaque ligne, le parcours, la courbe des sentiments et le sommet, le tableau de notation, le geste signature, ce que shoot.mjs a rapporté sur les trois exécutions, ce que vous avez vu sur les feuilles et corrigé, la vérification des sentiments (prévu contre ressenti), et ce que vous n'avez pas pu vérifier. Donnez l'URL locale. Ensuite ajoutez la ligne du build à FINGERPRINTS.md.