automatorsplus/immersive-3d-site

immersive-3d-site は何をしますか？

3Dがライブで動作するページです。動画ではありません。訪問者のスクロールがタイムラインとなり、カーソルがセカンドカメラとして機能します。実際のテキストが上部に重なり、読みやすく選択可能。WebGLキャンバスはその背後に配置されます。

成果物: ビルドフォルダ。BRIEF.md、実際の index.html 1つ、エンジンファイル、デスクトップ・スマートフォン・動作軽減モードのスクリーンショット一覧、確認事項と確認できなかった事項を記した短いレポートを含みます。

こうしたページが失敗する理由

多くの「3Dウェブサイト」は、回転するモデルにテキストがフェードインするだけの単一トリックに終始します。3セクション目までに訪問者はすべてを見終え、スクロールを止めます。以下の4つのルールがそれを防ぎます:

1. 各アクションは異なることをする。 references/scene-kit.md から最低4つの異なるシーンデバイスを使用し、同じものを連続して使わない。
2. 一つのピーク。 あるアクションは、訪問者が友人に説明する瞬間。最もスクロール尺を割り当て、最高のシーンを配置し、その前に静かなアクションを置くことで印象を強める。
3. 3Dはメッセージに奉仕する。 すべてのシーンは主題について真実を表現する: 何でできているか、どう機能するか、どのような感触か。装飾だけのシーンは削除する。
4. すべてのスクロール位置でテキストが読める。 どのフレームでも、行がシーンに埋もれて読めない場合は、テキストではなくシーンを動かす。

ステップ0: ブリーフ

ユーザーがすでに与えた情報を再利用します。完全なブリーフが与えられた場合、または「あなたの判断で」と言われた場合は、自分で BRIEF.md を作成し、「創造的委任に基づき記述」とマークし、以下のすべての質問にブランドのトーンで回答して先に進みます。それ以外の場合は、8つの質問をすべて1つのメッセージで、実際の質問として（決してメニュー形式ではなく）尋ねます:

1. それは何か、誰のためか、最終的に何をさせるべきか？ 1つのアクション、すべてで使われる1つのラベル。
2. 3～5語で表現する感触、およびウェブサイト以外から最大3つのリファレンス（映画、ゲーム、アルバムカバー、店舗）。ウェブサイトを挙げると、ページがそれをコピーしてしまう原因になります。
3. 訪問者の言葉での旅路: 最初に何を見て、次に、最後に何を見るか。
4. どこが落ち着いているべきか、どこが激しいべきか。
5. 各段階でどのように感じるべきか、覚えているべき一瞬。 references/feel.md を参照。
6. このサイトが、これまで見たどのサイトもしていないこと。 特徴的な動作の種。本当の回答を引き出してください。「記憶に残る」は回答になりません。
7. プレミアムミニマルからどれだけ離れるか: references/structures.md の範囲を提示。
8. 1つの連続した世界、それとも個別のシーン？ 最大の構造的分岐点であり、ユーザーの判断。さらに: 既存のアセット（ロゴ、色、フォント、商品写真、.glb形式の3Dモデル）があればそれも。

BRIEF.md をビルドフォルダに作成し、ユーザーの回答をそのままの言葉で記述し、以下を追加:

• 旅路: 4～7ビート。それぞれが訪問者の知識や感情の変化を表す。
• 感情曲線: ビートごとに1行。感情と、それを引き起こす画面上の要素。隣り合う2つが似ていないこと。
• ピーク: 訪問者があれについて言う一文と、それがどのアクションに属するか。
• これは ___ なサイト: 体験（テクニックではない）で埋める。
• 特徴的な動作: このサイトだけに存在する1つのインタラクションで、ページにコードされているもの。数値を変えただけのキットデバイスはカウントしない。
• 意図的な沈黙: マークしておくことで、チェックが単なる無動作と区別できるようにする。

ステップ1: 構造、ログ、スコアリング

この順序で3つ。コードの前にすべて完了。

構造を選ぶ: references/structures.md から: 1つの世界、チャプター、商品ステージ、展示、プレイグラウンド、インサート付きエディトリアル、ブロードキャスト。ナビゲーション、オープニング、クローズはそれに従う。BRIEF.md に、なぜこの構造で他の構造ではないかを記述。

フィンガープリントログを実行する: ビルドフォルダの FINGERPRINTS.md を読む（なければ作成、初期は空）。計画は、既存の各行と少なくとも4つの項目（構造、ナビ、ヒローデバイス、アクションシーケンス、クローズ、特徴的動作）で異なっていなければならない。条件を満たさない場合は、ログではなく計画を変更する。

スコアリングする: 最初に感情曲線、次にビートごとにデバイスをテーブルとして BRIEF.md に記述:

ビート	アクション	感情	デバイス	尺	なぜこのデバイスか
認識	ヒーロー	好奇心	ガラスオブジェクト + ドリー	2	製品が生きている。言葉を読む前に。
転換	モーフ	期待	パーティクルモーフ	3	ノイズが形になり、名前になる。
ピーク	レール	畏敬	カメラレール	3.5	内部を通り抜けることで、多くが含まれていると伝える。
証明	爆発	信頼	爆発ビュー	2.5	部品を見せる。それが主張。
決意	クローズ	静けさ	穏やかなホールド	1.5	ページが止まり、クリックを待つ。

ビルド前のチェック:

• 構造の禁止事項が守られている。
• references/scene-kit.md から4つ以上のデバイスファミリーを使用し、連続で同じものなし。
• 隣り合う2つのアクションが同じ感情を共有していない。
• ピークの尺が明確に最大であり、その前のアクションはより穏やか。
• クローズはフェードアウトせずに解決し、ホールドする。
• 尺は画面の高さ単位。シネマティックページは8〜14程度、エディトリアルやプレイグラウンドページは短くても良い。数字合わせのためのパディングはしない。

ステップ2: ビルド

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

templates/starter/index.html を構造のベースとして使用（インポートマップ、キャンバス、セクション、1つのモジュールスクリプト）し、スコアリングしたアクションパターンを借用する。スターターまたはそのOrbisコピーを本番に使用しないでください。 すべてのページは独自のブリーフから記述されます。

エンジンの動作（engine/stage.js、ヘッダーコメントを参照）:

• ページは <section data-act="name" data-span="2"> のスタック。各セクションは、そのセクションの長さにわたって固定される .frame を持つ。
• stage.act(name, { scene, camera, update(p, s), render(renderer, s), resize(w, h) }) でシーンを登録。p はアクション内で0から1まで変化。s は time、dt、pointer（スムーズ化、-1～1）、velocity（スクロール速度）、width、height、reduced、coarse を持つ。
• 画面の中央にあるアクションがレンダリングされる。同じ scene オブジェクトを共有するアクションは一緒に更新されるため、1つの連続した世界は複数のアクションが同じシーンを指すことで実現。
• アクションは尺が1より大きい場合のみ p が移動する。 p はフレームが固定されている距離全体で測定されるため、尺がちょうど1の場合は移動しない: p は0から1にスナップし、それに連動するものは表示されない。1.25以上を使用。
• すべてのセクションは --p をCSS変数として持ち、見出しが3Dと同じタイムラインで動く。
• 任意の要素に data-reveal を付けると、エントリー時にフェードイン。style="--i:2" でタイミングをずらす。
• seg(p, a, b) を使用して1つのアクションをビートに分割し、ease.inOut などで整形。
• WebGL非対応: html.no-webgl は各アクションの .poster を表示。すべてのアクションにポスター（画像またはグラデーション）を設定。

stage.css の先頭にあるトークン（canvas、surface、ink、ink-soft、accent、accent-ink、2つのフォント）でテーマを設定。エンジンを1つのプロジェクト用に編集しないでください。特別な動作はページ独自のスクリプトに記述します。

Three.jsは、インポートマップ内の固定CDNバージョン（jsdelivr上の [email protected]）から使用。固定を維持してください。より新しいバージョンが必要な場合は、少なくとも2週間以上前のバージョンを選択し、チェックを再実行してください。

マークアップを書く前に references/design.md を、2番目のシーンを追加する前に references/performance.md を読んでください。

ステップ3: 検証

cd <build> && npm i playwright-core          # ビルドフォルダごとに1回; Google Chromeが必要
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

スクリプトは各アクションを5つの位置までスクロールし、スムージングが落ち着くのを待ち、それぞれのスクリーンショットを撮影し、sheet.png を書き出します。ページエラー、失敗したリクエスト、WebGLなし、何も描画しないアクション、横スクロールで失敗します。合格は正常に実行されたことを意味し、品質が良いことを意味しません。

その後、すべての sheet.png を開いて確認。 各アクションの各位置で: すべての行が読めるか？ シーンはビートが示すものを表示しているか？ スマートフォンで、何かが切り取られたり、隠れたり、小さすぎたりしていないか？ ピークはピークに見えるか？ クローズは解決しているか？ 修正し、再度撮影し、再度確認。

次に感情チェック (references/feel.md): 冷えた状態でスクロールし、各アクションで感じたことを一言で書き出し、BRIEF.md の曲線と比較。不一致があればページを修正。

確認できなかったことを率直に伝える: ヘッドレスChromeはWebGLをソフトウェアで描画するため、報告されるフレームレートは実際のデバイスのものではなく、実際のスマートフォンでのスクロール感を伝えることはできない。ユーザーに、完了と呼ぶ前に実際のスマートフォンで開くよう依頼する。

ハードルール

絶対にしないこと	代わりに
ページ全体で1つのシーンデバイス	4つ以上のファミリー、連続で同じものなし
テクスチャや画像に焼き付けたテキスト	キャンバスの上に実際のHTML
スクロール矢印、マウスアイコン、「スクロールして探索」	何もない。ヒーローだけで十分
01 / 05 のようなセクションカウンター	削除
すべてのアクションで中央揃えのコピー	左、右、中央、分割、上、下と変化させる
コントラスト用の全画面ダークオーバーレイ	テキストブロックの後ろだけ .scrim
グラデーションテキスト、ネオングロー	ウェイトとサイズで強調
架空の数字や統計	ユーザーからの実際の数字のみ
表示コピー中のダッシュ記号	ピリオド、カンマ、コロン
決して止まらない回転物	モーションはスクロールまたはポインターに追従。アイドルモーションはゆっくりで小さい
セクションごとに新しいWebGLレンダラー	1つのキャンバス、1つのレンダラー、複数のシーン（エンジンが行う）
スターターページをそのまま出荷	独自のブリーフからページを記述
構造、ログ、スコアリングなしでビルド	ステップ1、3つすべて
2つのピーク、またはピークなし	1つ、最大の尺とその前の静かなアクション
3つ以上のログ列で以前のビルドと一致する計画	ログではなく計画を変更
ステップ3なしで完了と呼ぶ	ステップ3を実行し、シートを確認し、感情チェックを行う

出力

ビルドフォルダ、次に短いレポート: 構造とその理由、各行に対するフィンガープリント結果、旅路、感情曲線とピーク、スコアテーブル、特徴的な動作、shoot.mjs が3回の実行で報告した内容、シートで確認して修正した内容、感情チェック（意図したものと感じたものの比較）、確認できなかったこと。ローカルURLを添える。最後に、ビルドの行を FINGERPRINTS.md に追加する。