mcpField
T
threejs-particles-trails-and-effects

threejs-particles-trails-and-effects

github.com/linegel開発11140 回インストール5 週間前に更新
リポジトリ

threejs-particles-trails-and-effects について

Three.js の GPU 常駐パーティクル、トレイル、視覚効果を設計するためのスキルです。状態の所有権、描画、時間的な挙動、検証、性能予算を扱います。

主な機能

  1. 01GPU 常駐のパーティクル状態と更新
  2. 02決定論的な生成と ID ライフサイクル
  3. 03圧縮と近傍表現の選択
  4. 04トレイルと時間履歴の処理
  5. 05深度、HDR、出力の所有権
  6. 06検証とリソース予算

活用シーン

  1. 01反復するパーティクルシミュレーションの設計
  2. 02GPU 圧縮パーティクルプールの構築
  3. 03履歴残留を避けたトレイルの追加
  4. 04透明 HDR エフェクトの検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/linegel/threejs-complete-set-of-skill --skill threejs-particles-trails-and-effects

インストール後、Claude Code で/threejs-particles-trails-and-effectsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
agents/
openai.yaml
references/
particles-trails-and-effects-system.md
scripts/
trail-ring-oracle.mjs

詳細

表現優先のパーティクル、トレイル、エフェクト

GPU 上に常駐するオブジェクト空間およびワールド空間のエフェクトを管理します。生成、動き、寿命、コンパクション、描画表現、深度/ブレンドの挙動、シーンリニア HDR 発光を対象とします。ビューポート履歴は $threejs-dynamic-surface-effects に、天候の蓄積は $threejs-rain-snow-and-wet-surfaces に、作成者が指定するイベントの動きは $threejs-procedural-motion-systems に、共有ポスト処理の管理は $threejs-image-pipeline または $threejs-bloom に振り分けます。

エフェクトが別のシステムの管理下にある衝突、外力、または交換を消費する場合は、ステップ 1 の前に、次のローカルな受け渡しを完了します。

  • 量と単位、生成元のフレーム/原点、変換のリビジョン、原点の世代を明記します。
  • 半開のソース区間、更新頻度、サンプル位相、不変の生成元バージョン、許可されるプールのコンシューマーを明記します。
  • サポート/フィルター、妥当性、古さ、誤差、欠落/オーバーフロー時のポリシーを宣言します。
  • 一方向の読み取りを明示するか、双方向の場合はソース/反作用の管理者、適用順序、適用済みの状態バージョンを明記します。
  • GPU リソースの世代、生成パスと消費パス、完了依存関係を関連付け、連続性の途切れ、原点のリベース、世代の変更時にはリセットします。その際、定常フレームでは読み戻しが発生しないようにします。

ソースの管理権限はソースの所有者が保持し、プールは不変の公開データを消費します。ルートに追加のシステム所有者が必要な場合は、$threejs-choose-skills を使用してください。続いて連携入力を読み、エフェクト固有の管理と縮退のルールを確認します。

プロセス

1. 観測対象とその管理者を定義する

次の内容を含むエフェクトの契約を 1 つ作成します。

  • イベント区間、決定論的なシード、エフェクトクラス、変換、流れ/衝突の方向。
  • 座標系、距離/時間の単位、寿命を計測する時計、シーク/リセットの挙動。
  • シルエット、動き、照明、残留物、遮蔽といった視覚的な役割。
  • 深度テスト、深度書き込み、ブレンド/描画順序、HDR 信号、最終出力の管理者。
  • 外部の生成元と、プールが表示専用なのか、別の所有者が管理する物理ボディに基づくのか。

すべての視覚的または物理的な特性に所有者が 1 つずつ割り当てられ、すべての入力にフレーム、時刻、妥当性ポリシー、コンシューマーが定義されたら、このステップは完了です。

2. 動きと近傍表現を選択する

仕組みを表現できる、書き込み可能な状態のうち最小限のものを選びます。

仕組み表現
ポーズと外観が生成データと時刻の純粋関数である不変の生成レコード。頂点 TSL で解析的に評価
粒子ごとに状態が独立して反復するStructure-of-Arrays のホット状態。名前を付けた 1 つの計算積分ステージ
衝突またはフィールドのフィードバックによって状態が変化する反復状態と、同じフレームおよびサンプル時刻における管理対象の GPU フィールド/プロキシ
近傍との相互作用が重要である有界な局所相互作用の前に空間グリッド/ハッシュ、またはソートと走査を実行

割り当て方式は独立して選択します。

使用状況割り当て/コンパクション
穴のコストが走査/スキャッターのトラフィックより小さい安定したスロット、世代を含む ID、生存フラグ、有界の可視範囲
出力の密度を高めることで後続の処理が大幅に減るmark -> exclusive scan -> scatter -> publish indirect count を実行し、2 つ目の状態セットに格納
削除がソースと宛先の一意な所有権のもとで直列化される密なテールスワップを使用できます。すべての状態レーンと ID レーンをまとめて移動

反復プールまたはコンパクション済みプールを実装する前に、状態とコンパクションを読んでください。近傍との相互作用については、近傍との相互作用を読んでください。すべての書き込み可能なレーン、および選択したコンパクションまたは近傍フェーズについて、後続のコンシューマーまたは測定済みの削減効果による根拠が示されたら、このステップは完了です。

3. 状態遷移とアイデンティティのライフサイクルを指定する

順序を明示します。

ordered event packets
  -> deterministic spawn/range allocation
  -> optional neighborhood build from committed source state
  -> analytic evaluation or one recurrent next-state update, including interaction
  -> optional ordered compaction
  -> optional trail sample and publication
  -> draw from the committed state/count
  -> post consumers

コールドパラメーターは一度だけ生成し、更新するのはリカレントレーンのみとします。スロットが移動しても、エンティティの安定したアイデンティティを維持します。生成、消滅、スロットの再利用、テレポート、表現の変更、および以前の状態が取得できない場合は、表示前にモーションベクトル、トレイル、補間、時間履歴を無効化します。解析的なパーティクルでは前回と現在の表示時刻の両方を評価します。リカレントプールではシミュレーションの状態ペアを保持し、レンダラーが補間する場合やティックをスキップする場合は、タイムスタンプを個別に付けた前回の表示状態も保持します。

カメラカットなど表示のみの不連続が発生した場合は、影響を受けるスクリーンスペースモーションと時間蓄積をリセットしますが、パーティクルのシミュレーション、ライフタイム、アイデンティティ、有効なワールドスペースのトレイル履歴は再開しません。

エフェクトが TAA、モーションベクトル、トレイル、または複数フレームにわたるポスト処理に影響する場合は、時間的アイデンティティを参照してください。各状態バージョンに書き込み元が 1 つだけあり、描画が確定済みのバージョンを使用し、再利用されたスロットが以前のエンティティの履歴を引き継がないことを確認できたら、このステップは完了です。

リボンまたは履歴トレイルについては、トレイル履歴とリボンを参照してください。

4. r185 の GPU パスを構築する

three/webgpu の WebGPURenderer を使用し、await renderer.init() を呼び出して、この標準パスでは renderer.backend.isWebGPUBackend === true を必須とします。WebGPU を利用できない場合の明示的な案内は $threejs-compatibility-fallbacks に誘導します。リカレント状態には Fn().compute(...)、renderer.compute(...)、ストレージノード、StorageInstancedBufferAttribute を使用します。スプライトの描画には SpriteNodeMaterial を、形状のあるパーティクルの描画には InstancedMesh と NodeMaterial ファミリーのマテリアルを使用します。高密度コンパクションでは IndirectStorageBufferAttribute を通じて間接コマンドを公開し、geometry.setIndirect() を使用します。

r185 の computeAsync() は GPU の処理完了を待つのではなく、レンダラーの初期化を待ちます。グローバルなフェーズ間の依存関係は順序付けされたディスパッチとして表現し、フレームのクリティカルパスで必要なカウントと状態は GPU 上に保持します。

コンピュート、間接描画、境界、または完了処理を実装する場合は、r185 の実行に関する事実を参照してください。追加されたすべてのスポーン、更新、近傍処理、コンパクション、トレイル公開、描画フェーズに明示的な GPU の順序付けがあり、空またはオーバーフローの状態でも有効なカウントとマッピングが公開され、定常フレームパスで読み戻しやパーティクルごとのオブジェクト更新が行われないことを確認できたら、このステップは完了です。

5. 表現、深度、出力を結び付ける

カメラに正対する火花にはスプライトまたはインスタンス化クワッド、形状のある破片にはライティング付きのインスタンス化メッシュ、形状に沿うプラズマには船体由来のジオメトリ、航跡には生成したカプセル/プロファイルジオメトリを使用します。流れに沿うエフェクトについては、シェルと航跡を参照してください。火花または破片については、解析的な火花と溶解する破片を参照してください。

各描画クラスには、深度と透明度の仕様を明示します。ストレージ駆動の動きには、チャンク化した解析的境界または GPU リダクションを使用します。美観用の描画はシーンリニア HDR のまま保持し、トーンマッピングと出力変換の担当を 1 つにします。フルシーンブルームでは HDR の美観用描画を参照します。選択的なエミッシブ MRT は、作成時に対象の包含/除外要件があり、有効な透明ブレンドと実測済みのアタッチメントコストがある場合に限り割り当てます。

透明またはエミッシブのエフェクトを承認する前に、深度、HDR、出力を参照してください。オクルージョン、描画順、境界、HDR への寄与、最終変換のそれぞれに、テスト済みの担当が 1 つだけあることを確認できたら、このステップは完了です。

6. 仕組みと予算を実証する

シード値を固定した時間状態をキャプチャし、該当する証拠のみを提示します。イベントとスポーンの範囲、プールされた状態のライブ数/スロット数、オーバーフロー、ID、経過時間/速度、圧縮された状態の圧縮回数とマッピング、トレイルのヘッド/数、時系列サンプルと途切れ、ローカルインタラクションの近傍占有数とオーバーフロー、選択した描画クラスとポスト処理クラスの境界、深度モード、未加工HDR、任意の選択的シグナル、ブルームの寄与、オーバードロー、GPU時間を提示します。同じ表示負荷で、採用を認められた選択肢のみを比較します。

ブルームを採用する場合は、ブルームを無効にしてビューティーパスを検証し、ハローによる補助がなくても、読み取りやすいシルエット、レイヤーの役割、深度、モーションを維持します。スケールアップする際は、まずアイドル時の処理を停止し、不要な書き込み可能状態や圧縮をなくします。その後、選択したモーションクラスとオーナーを維持しながら、アクティブ数、フィールドの帯域幅、透明レイヤー、ポスト処理の範囲を減らします。

該当する分岐については、リソースの計上と診断と障害の兆候を参照してください。シード値による結果を再現でき、採用されたすべてのイベント、更新、近傍処理、圧縮、トレイル、描画、ポスト処理の各フェーズで順序が証拠によって示され、安定したIDとリセット制御のテストに合格し、フレーム経路で必須の読み戻しがゼロであり、深度と出力のオーナーがそれぞれ一意で、ブルームを採用した場合はブルームなしの画像も明瞭であり、シーン全体が定められたリソース予算と時間予算を満たしたとき、スキルは完了です。

コメント