threejs-scene-composition

Three.js のシーン構成

奥行き、カメラ、ライティング、マテリアルの反応、ジオメトリ、または空間的なアニメーションがメディアのアイデアを担い、ブラウザーでレンダリングするシーンが適切な制作環境となる場合は、Three.js を使用します。このスキルは、アセット要件とクリエイティブの意図が明確になった後に始まり、再現可能なレンダリング済みシーンのパッケージを完成させた時点で終わります。

このスキルでは、メッシュモデリング、リトポロジー、リグの作成、物理シミュレーション、WebXR プロダクト設計、ゲームロジックは扱いません。別の場所で制作された、承認済みの glTF アセット、アニメーションクリップ、テクスチャ、環境マップ、フォント、データ、音声キューを使用できます。

根拠の扱い

• 文書化された事実とは、Three.js、Khronos、WebGL、または W3C の公式情報源で仕様が示されている動作を指します。
• 制作上のヒューリスティックとは、有用な出発点ではあるものの、実際のシーンと納品先のハードウェアでテストする必要があるものを指します。
• 実測結果とは、シーン、フレーム出力、ブラウザー、GPU、またはエンコード済みの納品物から測定した結果を指します。

Three.js は頻繁にリリースされ、サンプルやアドオンのパス、API が変更されることがあります。事実とリンクは 2026-07-12 に確認しました。インストールしたリビジョンを固定して記録し、移行に関する注意事項を確認したうえで、納品前に対象ブラウザーとレンダラーの組み合わせでテストしてください。WebGPU のサポートとレンダラー間の互換性は、特に変化が激しい領域です。

Three.js が適切なレンダラーか判断する

次の要件が納品物にある場合は、Three.js を使用します。

• 実際の 3D カメラ、視差、奥行き、オクルージョン、または空間的な連続性が必要である。
• ブラウザーの PBR マテリアルでレンダリングする glTF シーンやプロダクトのアセットがある。
• スケルタル、モーフターゲット、キーフレーム、またはプロシージャルな 3D アニメーションが必要である。
• カスタムシェーダー、パーティクル、インスタンシング、またはポストプロセッシングが必要である。
• ブラウザーベースのコンポジションシステムから、決定論的にフレームをキャプチャする必要がある。
• 1 つのシーンを複数のアスペクト比やカメラ構図に合わせる必要がある。

次の場合は、別の方法を優先します。

• 2D コンポジターを使うほうが、結果をより明確かつ低コストで表現できる。
• ショットのコンポジションではなく、後続のエンジンで使うためのメッシュ準備が目的である。
• 正確なオフラインパストレーシング、長編映画品質のシミュレーション、または DCC ネイティブな引き渡しが必要である。
• 静止したプロダクトレンダリングがすでにあり、3D による改訂の利点が残っていない。
• レンダリング済みのメディア納品物ではなく、ブラウザー上のインタラクションが主な要件である。

コンポジションを豪華に見せるためだけに 3D シーンを追加しないでください。カメラと立体表現は、メッセージに役立つものでなければなりません。

シーンの仕様を確定する

実装前に、次の項目を定義します。

• 出力サイズ、アスペクト比、フレームレート、尺、アルファの要否、色および HDR の要件。
• 各ビートにおけるカメラ、レンズ／FOV、被写体、動き、ライティングの変化、トランジションを含むショットリスト。
• 承認済みアセットと、そのスケール、軸、ピボット、アニメーションクリップ、モーフターゲット、マテリアル、使用権。
• マテリアルの参照と、色の厳密性に関する要件。
• 環境、ライト、シャドウ、反射、背景、フォグ、ポストプロセッシング。
• シード、データ、アニメーション時間、シミュレーションキャッシュ、アセットのバージョンなど、決定論的な入力。
• ブラウザー、GPU／ソフトウェアの処理経路、メモリ、フレームサイズ、レンダリングワーカー、納期など、パフォーマンスの許容範囲。
• 特に点滅、急速なカメラ移動、動きを抑えたバリエーションに関するアクセシビリティの制約。
• レビューの承認段階：グレーボックス、ルック開発、アニメーション、負荷の高いフレーム、エンコード済みプレビュー、最終版。

安定した ID をファイル、チェックサム、変換、ライセンス、シーン内での用途に対応付けたシーンマニフェストを作成します。最終レンダリングの前に、リモートアセットをローカルに固定します。

シーン、カメラ、レンダラーの構成

文書化された事実： Three.js は Object3D の階層を Scene 内に構成し、カメラを通して表示し、レンダラーで描画します。子の変換は親の変換を継承します。パースペクティブカメラと正投影カメラは、それぞれ異なる空間の見え方に適しています。

制作上の役割ごとにシーンを構成します。

scene
+- world
|  +- environment
|  +- set
|  `- practical-lights
+- subject-root
|  +- approved-model
|  `- subject-controls
+- fx-root
+- camera-rig
|  +- camera-target
|  `- camera
`- review-guides

安定した名前を使用し、カメラリグ、被写体の変換、インポートしたアニメーション、プロシージャルエフェクトを分けてください。配列インデックスを使って、深くネストされたインポート済みノードを変更するのは避けてください。ノード名を使って一度だけ参照し、ノードが存在することを検証します。

カメラの向き

• レンズのような奥行きにはパースペクティブ投影を、図解的またはアイソメトリックなシーンには正投影を選びます。
• 承認済みの動きをクリッピングせずに有用な深度精度を得られるよう、ニア平面とファー平面を適切に設定します。
• 関連性のないカメラの直接変更を混在させず、リグまたはターゲットをアニメーションさせます。
• 実際のアスペクト比でフレーミングをテストします。中央でクロップするだけでは、縦向きの構図設計にはなりません。
• カメラの速度、加速度、地平線の変化は、対象者とモーション低減の要件に適したものにします。

glTF アセットのインポートと検証

文書化された事実： glTF 2.0 は、シーン、ノード、メッシュ、スキン、アニメーション、カメラ、PBR マテリアル、テクスチャ、バイナリリソースを記述します。Three.js の GLTFLoader は、読み込んだシーンとアニメーションクリップを返し、文書化された一連の glTF 拡張機能をサポートします。コア glTF マテリアルでは、メタリック・ラフネス PBR を使用します。

インポートするアセットごとに、次の作業を行います。

1. Khronos glTF Validator でソースを検証します。
2. 必須および使用中の拡張機能を記録し、ローダーのサポートを確認します。
3. シーンのスケール、向き、境界、ピボット、カメラ、ライト、スキン、モーフターゲット、アニメーション、マテリアル数を確認します。
4. テクスチャの色空間アノテーションと UV／接線の動作を確認します。
5. リファレンスビューアーと本番シーンでアセットを比較します。
6. ソースパッケージを保持し、変換、圧縮、マテリアルのオーバーライドがあれば記録します。

Draco またはメッシュ圧縮、KTX2／Basis のテクスチャパスを使うのは、デコーダーのデプロイ、対象環境のサポート、視覚的な変化、起動コストを確認してからにします。圧縮は配信上の判断であり、自動的に品質を向上させるものではありません。

色、マテリアル、ライティング

文書化された事実： Three.js は、Linear-sRGB を作業色空間とするカラーマネジメントのワークフローを使用します。ベースカラーやエミッシブマップなどのカラー テクスチャには sRGB 色空間のアノテーションが必要です。ノーマル、ラフネス、メタリックネスなどの非カラー データテクスチャは、カラーとして扱わないでください。出力変換とトーンマッピングは、レンダラーが担います。

色を重視するワークフロー：

• 各テクスチャをカラーまたはデータに分類します。
• レンダラーの出力色空間を意図的に設定します。
• トーンマッピングと露出を選択して記録します。
• レンダリングからエンコードまでの全工程を通して、ニュートラルな基準値と承認済みの製品カラーを比較します。
• 1 種類のスタイライズドライティングだけでマテリアルの色を判断しないようにします。
• ディスプレイ変換を二重に適用しないでください。

ライティングの反応が重要な場合は、物理ベースマテリアルを使用します。誘電体と金属の意図された違いを保ち、ラフネス、法線、クリアコート、透過、ボリューム、シーン、玉虫色などの拡張機能は、アセットと対象環境がサポートする場合にのみ確認します。

ライティング計画：

• 環境光や反射の寄与を、直接光とは別に設定します。
• キーライト／フィルライト／リムライト、またはシーン内の光源を使った構成は、ビジュアルの意図に合う場合にのみ使用します。
• 影を落とす対象と影を受ける対象を明示的に設定します。
• 各シャドウカメラ／フラスタムを、必要な範囲に合わせます。
• シャドウアクネとピーターパニングを確認しながら、バイアスと法線バイアスを調整します。
• 最終解像度と圧縮状態で、接地影とシルエットをテストします。

制作上のヒューリスティック：意図した形状を表現できる最小限のライトとシャドウマップから始めます。ライトを増やすのは、目に見える不足がある場合に限ります。映画的に聞こえるからという理由で複雑さを加えないでください。

アニメーションシステム

Three.js では、インポートしたクリップ、スクリプトによるトランスフォーム、モーフターゲット、カメラ、シェーダーユニフォームを組み合わせられます。プロパティごとに、担当する所有者を 1 つだけ定義してください。

インポートしたクリップとスケルタルアニメーション

ドキュメントに記載されている事実： AnimationMixer は、AnimationClip データから作成された AnimationAction インスタンスを制御します。クリップにはキーフレームトラックが含まれます。アクションは、ループ、クロスフェード、ウェイトの変更、通常ブレンドまたは加算ブレンドに対応しています。

• クリップ名、長さ、ループの意図、ルートモーション、バインドポーズ、スケールを確認します。
• クリップの中間だけでなく、極端な変形や遷移もテストします。
• ルートモーションは意図を明確にして正規化するか、そのまま維持します。
• ポーズと接地の制約が許す場合に限り、動きの連続性を保つためにクロスフェードを使用します。
• ブレンドの前後では、足、手、小道具、顔のモーフ、影をフレームごとに確認します。

モーフターゲット

承認済みの形状変化、顔のポーズ、補正変形にはモーフを使用します。トポロジーとターゲットの順序が一致していることを検証します。影響値はクランプするか、意図的に組み合わせます。中間値では、体積の損失、自己交差、テクスチャの伸びを確認します。

プロシージャルモーション

可能な限り、プロシージャルな状態はコンポジション時刻の純粋関数として記述します。

function applyFrameState(frame, fps) {
  const time = frame / fps;
  subject.rotation.y = baseRotation + time * radiansPerSecond;
  material.uniforms.uTime.value = time;
  cameraRig.position.copy(cameraPath.getPointAt(clamp01(time / shotDuration)));
}

この例では、clamp01(value) が Math.max(0, Math.min(1, value)) を返し、cameraPath が Curve3 の実装など、設定済みの Three.js 曲線であることを前提としています。実際の曲線とカメラターゲットは、それぞれ別途検証してください。

パーティクルの分布とノイズの入力にはシードを設定します。フレームを書き出す際に position.x += ... のように状態を累積させないでください。そうすると、逆方向へのシークや順不同でのフレームレンダリングで、結果が正しくなくなります。

決定論的なフレームレンダリング

ライブプレビューでは、一般に requestAnimationFrame と増分デルタを使用します。固定されたメディアのキャプチャではなく、要求されたフレームからシーン全体の状態を導出してください。

各フレームで次の処理を行います。

1. コンポジションの契約に基づいて time = frame / fps を計算します。
2. インストール済みのバージョンがサポートするミキサー／アクションの方法を使って、インポートしたアニメーションをその絶対時刻に設定します。以前に update(delta) が何回呼ばれたか不明な状態に依存してはいけません。
3. カメラリグ、プロシージャルな変換、パーティクル、シェーダー、モーフ、表示状態を、絶対時刻またはキャッシュ済みの決定論的な状態から設定します。
4. 必要なワールド行列、スケルトン、レンダーターゲットを更新します。
5. シーンとポストプロセッシングのチェーンを一度レンダリングします。
6. ホストレンダラーを通じて、完成したフレームを読み取るかキャプチャします。

アダプターの例：

export function renderAtFrame(frame, fps) {
  const time = frame / fps;
  mixer.setTime(time);
  applyFrameState(frame, fps);
  scene.updateMatrixWorld(true);
  composer.render();
}

ミキサーのタイムスケールが 1 以外の場合に setTime() を使う前に、現在の AnimationMixer の動作を確認してください。原則は絶対時刻での評価であり、特定の API 呼び出しに固執することではありません。

最終キャプチャでは、実時間、シードなしの乱数、ライブネットワーク応答、非表示タブでのタイミング、デバイスの向き、制約のない物理演算を使用しないでください。シミュレーションが不可欠な場合は、事前にベイクするか、再現可能な固定ステップのキャッシュを定義します。

同じ負荷の高いフレームを、クリーンな状態から 2 回実行してレンダリングし、比較します。バックエンドやハードウェアによって GPU のピクセルが完全に一致しない場合があります。厳密な再現性が必要な場合は、許容範囲を定め、レンダリング環境を固定します。

シェーダーとポストプロセッシング

視覚的な要件を満たす場合は、まず組み込みマテリアルを使用します。カスタムの ShaderMaterial、生のシェーダー、ノードベースのシェーディング、ポストプロセッシングは、表現の幅と移植性のリスクの両方を高めます。

カスタムシェーダーの場合：

• ユニフォーム、座標空間、精度に関する前提、必要な拡張機能を記録します。
• 時刻にはコンポジション時刻を使用します。
• 不安定な計算をクランプし、境界値をテストします。
• フレーム 1 の前に、制作で使用するすべてのバリアントをコンパイル／プリウォームします。
• シェーダーエラーとレンダラー情報を記録します。
• 対象のバックエンドでエフェクトを実行できない場合に備えて、フォールバックを用意します。

ポストプロセッシングの場合：

• エフェクトは一般に可換ではないため、パスの順序を指定します。
• 最終出力の解像度でのレンダーターゲットメモリを見積もります。
• 圧縮後のブルーム、ぼかし、被写界深度、グレイン、色収差を確認します。
• アセットやマテリアルの不備を隠すエフェクトは避けます。
• 最終パイプライン全体で、アルファとプリマルチプライ処理を確認します。

パフォーマンスとリソース管理

**文書化された事実：**シーンからメッシュを削除しても、ジオメトリ、マテリアル、テクスチャ、レンダーターゲットの GPU リソースが自動的に解放されるわけではありません。破棄可能なリソースには dispose() メソッドが用意されています。Three.js は診断用にレンダラーのメモリ情報を提供しています。

本番環境でのアプローチ：

• ID を共有できる場合は、ジオメトリとマテリアルを再利用します。
• 繰り返し登場するオブジェクトには、インスタンシングまたはバッチ処理を使用します。
• 主役のシルエットを損なう前に、ドローコール、マテリアルのバリエーション、オーバードロー、透明レイヤー、シャドウキャスターを減らします。
• カメラからの距離によって置き換えが見えなくなる場合に限り、LOD を使用します。
• テクスチャは、画面上で必要な最大表示範囲に合わせたサイズにします。
• 置き換えたジオメトリ、マテリアル、テクスチャ、レンダーターゲット、コントロール、ポストプロセス用リソースを破棄します。
• 終了処理の際に、イベントリスナーとアニメーションループを削除します。

空のシーンではなく、実際の使用を代表する一連の動作を測定します。読み込み時間、初回フレームのシェーダーコンパイル、ピークメモリ、フレームごとのレンダー時間、読み戻し／キャプチャのコスト、エンコード後の出力品質を記録します。

アクセシビリティと視聴者の安全性

**文書化された事実：**WCAG 2.2 の SC 2.3.1 は、一般的な閾値および赤色の閃光の閾値を下回る場合を除き、任意の 1 秒間にコンテンツが 3 回を超えて点滅しないよう制限しています。ループするコンテンツはループ再生し、想定される最大表示サイズでテストしてください。

次の点も確認します。

• カメラの急激な全画面移動、回転、ズーム、視差、地平線の傾き
• ちらつく影、Z ファイティング、発光のパルス、稲妻、パーティクル、ポストエフェクト
• 色、奥行き、動きだけで伝えられる情報
• 変化する 3D 背景上に表示される字幕や必須テキスト
• 視聴者や配信先のニーズに応じた、モーションを抑えたレンダー

インタラクティブコンテンツとして公開する場合は、モーションを制御できるようにし、該当する場合はユーザー設定を尊重します。収録済みの動画では、メディアクエリでレンダー済みのピクセルを変更できないため、別途、動きを抑えた出力を作成します。

権利と来歴

Three.js は MIT ライセンスですが、シーンの依存関係にはそれぞれ独自の条件があります。モデル、テクスチャ、HDRI、フォント、シェーダー、モーションクリップ、モーションキャプチャ、プラグイン、ロゴ、参照メディアのライセンスと使用許可を記録してください。生成素材については、入手可能な場合、プロバイダー、モデル、バージョン、プロンプト、シードのメタデータが必要です。

公開デモからダウンロードしたアセットが、商用利用の許諾を得ているとは限りません。必要な表記を保持してください。モデルが実在の人物、ブランド製品、私有地、芸術作品、または保護対象のキャラクターを描写している場合は、レンダリングの前に、該当する同意と権利を確認してください。

レンダリングの QA と引き継ぎ

次のチェック項目を確認します。

• **構造：**すべてのアセットがローカルで読み込まれます。glTF の検証と拡張機能のサポートが文書化されています。
• **フレーミング：**カメラ、クロップ、セーフエリア、ニア／ファークリッピング、アスペクト比の各バリエーションが問題なく動作します。
• **ルック：**承認済みの内容と、色空間、トーンマッピング、露出、マテリアル、反射、ライト、シャドウが一致しています。
• **モーション：**クリップ、ブレンド、モーフ、プロシージャルな状態、カメラパス、接地、ループが、フレーム単位および通常再生で問題なく動作します。
• **決定性：**ストレス条件下のフレームの再生成と後方シークの結果が、宣言された許容範囲内で一致します。
• **パフォーマンス：**ピークメモリとレンダー時間が本番環境の許容範囲内に収まり、終了処理で破棄可能なリソースが解放されます。
• **安全性：**点滅と広い視野にわたる動きのレビューに合格しているか、より安全なバリエーションが提供されています。
• **出力：**フレーム数、fps、寸法、アルファ、コーデック、音声同期、圧縮が要件を満たしています。

引き継ぎには、ソースコード、バージョンを固定した依存関係／ロックファイル、ローカルアセット、シーンマニフェスト、レンダー設定、正確なコマンドまたはホストのエントリーポイント、代表フレームの確認結果、パフォーマンスに関する注記、来歴台帳、ライセンス表記、QA レポート、既知のバックエンドの制限事項を含めてください。

例1：色が重要な製品オービット

これは完全な例であり、必須の定型ではありません。

目的： 承認済みのランニングシューズを、製品発売向けに12秒の4Kオービット映像にします。劇的な効果よりも、素材と色の忠実性を重視します。

入力と制約： 検証済みのGLB、承認済みのベースカラー見本、4Kテクスチャセット2種類、ライセンス取得済みのスタジオHDRI、3840x2160、30 fps、レビュー用H.264と高品質なマスターフレーム、ロゴや形状を創作しないこと。

ワークフロー：

1. GLBを読み込んで内容を一覧化し、メートル単位のスケール、境界、名前付きマテリアル、UV、必須拡張機能を確認します。
2. ベースカラーテクスチャにsRGBを指定し、ノーマル、ラフネス、メタリックネスは非カラーのデータとして扱います。
3. ニュートラルな環境に、幅の広いキーライトと控えめなリムライトを1つずつ加え、ターンテーブルに合わせて柔らかな接地影を調整します。
4. 承認済みの色見本とニュートラルなリファレンスカードを基準に、トーンマッピングと露出を固定します。
5. シューズは静止させたまま、イージングを加えた210度のオービットをカメラリグでアニメーションさせます。最後の2秒は、最も見栄えのする斜め前方のアングルで静止させます。
6. カメラとターンテーブルの状態は、絶対フレーム時刻から評価します。
7. 全体を書き出す前に、フレーム0、1、90、180、299、300、359をそれぞれ2回レンダリングします。
8. エンコード済みのレビュー映像とマスターフレームを比較し、メッシュの細部、ロゴ、影、色の変化を確認します。

期待される結果： 形状とロゴが安定し、カメラフレームを再現でき、マテリアルがニュートラルに反応し、接地感が明瞭で、最終エンコードまで承認済みの色が保たれます。

起こりやすい問題： 色変換が二重に適用される、ラフネスマップがsRGBとしてタグ付けされている、環境光が強すぎて承認済みの色が変わる、ニアプレーンでクリッピングが発生する、1フレーム目にシェーダーコンパイルの引っかかりが生じる、圧縮でニットの質感が損なわれる。

バリエーション： 9:16の場合は、16:9のオービットをクロップするのではなく、カメラパスをより近くなるように作成し、最後の静止区間も別途調整します。

例2：プロシージャルなタイトルワールド

これは完全な例であり、必須の定型ではありません。

目的： 2,000本のインスタンス化された柱が立ち上がって都市のような文字シルエットを作り、その中をカメラが通り抜ける8秒のタイトルシーケンスを作成します。

入力と制約： 1920x1080、30 fps、承認済みのタイトル1点、外部3Dアセットなし、決定論的なシード、控えめなグロー、動きを抑えた代替版、点滅なし。

ワークフロー：

1. 保存済みのシードとバージョン管理された生成設定を使用して、承認済みのタイトルマスクを、インスタンスごとの目標高さを記録した固定テーブルに変換します。
2. 1種類のインスタンス化ジオメトリ／マテリアルとインスタンスごとのトランスフォームを使用して柱をレンダリングします。
3. 絶対時刻、目標高さ、決定論的な空間ディレイに基づいて各柱の高さを制御します。累積した高さは変更しません。
4. 作成済みの位置と注視点を設定したカメラスプラインを使用し、カメラの地平線のロールを制限します。
5. メインレンダリングの後に控えめなブルーム処理を適用し、処理の順序とレンダーターゲットのメモリ使用量を確認します。
6. 読みやすいタイトルシルエットを1.5秒間静止させます。
7. 動きを抑えたバージョンでは、カメラを固定し、柱の移動量を短くします。
8. 全画面の点滅をレビューし、ストレスフレームを繰り返し比較します。

期待される結果： レンダリング間でインスタンス配置が同一になり、1フレームだけの飛びがなく、タイトルが読みやすく、カメラが安定し、GPUメモリ使用量が上限内に収まります。

起こりやすい問題： インスタンス配置にシードが設定されていない、トランスフォームの累積で時間を逆方向にシークすると破綻する、柱が密集してモアレが生じる、ブルームが強すぎる、カメラのクリッピングが発生する、タイトルを読み取れる静止区間がない。

バリエーション： GPUやレンダーワーカーの制約が厳しい場合は、3Dレイヤーをアルファ付きで事前レンダリングし、シーンマニフェストと来歴情報を保持したまま、2Dランタイムで合成します。

出典

2026-07-12 に確認した公式および権威ある出典：

• Three.js のドキュメントとマニュアル：https://threejs.org/docs/ および https://threejs.org/manual/
• Three.js のアニメーションシステム：https://threejs.org/manual/en/animation-system.html
• Three.js の色管理：https://threejs.org/manual/en/color-management.html
• Three.js のクリーンアップに関するガイダンス：https://threejs.org/manual/en/cleanup.html
• Three.js の GLTFLoader：https://threejs.org/docs/#examples/en/loaders/GLTFLoader
• Khronos glTF 2.0 仕様：https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html
• Khronos glTF Validator：https://github.com/KhronosGroup/glTF-Validator
• WebGL 2.0 仕様：https://registry.khronos.org/webgl/specs/latest/2.0/
• Three.js ライセンス：https://github.com/mrdoob/three.js/blob/dev/LICENSE
• W3C WCAG 2.2「3 回の閃光またはしきい値以下」：https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html