3dviz-pro-max

3Dviz Pro Max

エージェントの空間推論、ジオメトリ、構図、プログラミングの能力を活用し、ユーザーのアイデアを形にします。カタログ、キット、リグ、スクリプトは、判断や制作を効率化しますが、作成できるものに制限を設けるものではありません。実行可能なシーンを作るには、視覚的な判断も必要です。

ワークフロー

新しいシーンでは、以下の判断を順に進めてください。既存の成果物の場合は、まず内容を確認し、変更によって影響を受ける手順だけを適用してください。ユーザーの制約は、推奨されるツールや記録より優先されます。

1. 意図とビジュアルの方向性。 見る人に何を見て、感じて、理解し、あるいは行動してほしいのかを明確にします。 個性のあるビジュアルのアイデア、有用な参考資料、想定する鑑賞距離を選びます。形状、素材、光、カメラ、動きをどう組み合わせるかを決めます。環境によっては時刻も重要です。解剖学的な研究や数学的なオブジェクトには、スタジオ風、図解風、あるいは架空の設定が必要な場合があります。
2. 重要なオブジェクトを検討します。 テンプレートを選ぶ前に、重要な各オブジェクトを説得力のあるものにするシルエット、プロポーション、パーツ、接続部、表面の特徴、動作を特定します。オブジェクトの検討と オブジェクトの制作を活用します。最も難しいオブジェクト、または最も個性のあるオブジェクトから早めに取り組みます。
3. 表現の根拠を固めます。 イラスト、離散状態、シミュレーション、再生のいずれかを選びます。境界が明確であれば、シーン内で組み合わせることもできます。確立された学術的、科学的、技術的主張については、実際の記述を調査し、調査と信頼性を使って、主張 → モデル → レンダリング結果を事実確認します。装飾的なメッシュ、インポートした解剖データ、物理エンジンは、科学的な主張の正しさを保証しません。信頼できる状態の基準を特定します。
4. オブジェクトごとに構築方法を選びます。 以下のルーティングテーブルを使います。役立つ場合は不足している判断材料を調べます。テーマを、語句が最も近い項目に無理に当てはめないでください。レシピ、数値のデフォルト値、見た目のプロファイルは、すべての値をそのままコピーする指示ではなく、調整して使う候補です。 重要な接合部では、オブジェクトに連続した表面、層状の覆い、独立して動くパーツのどれが必要かを判断します。接合したボリュームが不自然に見える場合は、表面の連続性を使います。メッシュの結合は、あらゆる問題に通用する修正方法ではありません。

   python3 scripts/search.py "<subject and unresolved decision>"
   python3 scripts/resolve.py <record-id>
   python3 scripts/design-context.py "<objective>" --blueprints --look <style-id>
   

5. 品質目標を定め、ツールを確認します。 関連する場合は事実の忠実性も含め、概要、詳細確認、クローズアップの各距離で、オブジェクトが何に耐えられる必要があるかを明示します。ツールの有無を芸術的な品質と同一視せず、利用可能なツールを確認します。

   python3 scripts/host-probe.py --out host.json
   python3 scripts/design-context.py "<objective>" --blueprints --host host.json \
     --delivery web-desktop --hero <blueprint-id>
   

   T0～T4は、既存のキットのパイプラインと、宣言されている検証状況を示します。従来のquality_ceilingフィールドは、同梱キットのパイプラインに関する推奨値であり、カスタムジオメトリ、外部アセット、プロシージャルマテリアル、エージェントの創造性に対する制限ではありません。キットに特定の段階がなくても、別の構築方法を妨げるものではありません。Blenderが利用できるからといって、オブジェクトの品質が高くなるわけではありません。Three.jsだけで構築したからといって、品質が低くなるわけでもありません。
6. 説得力のある最初のビューを作ります。 ユーザーのスタックを維持します。役立つ場合は、共有スクリプト、レンダラーのセットアップ、リグと足場、マテリアルユーティリティ、ジオメトリ操作を再利用します。大規模なシーンやコレクションでは、手法を広げる前に、代表的で難易度の高いオブジェクトまたはシーンを1つ確認します。キットの形に合わせたプロトタイプを、気づかないうちに完成版の主役にしないでください。必要に応じて、カスタムジオメトリ、シェーダー、マテリアル、テクスチャ、ライティング、インタラクションを作成します。適切なモデリング、スカルプト、リギング、UV、ベイク作業にはBlenderを、適切なプロシージャルジオメトリ、インタラクティブな状態、レンダリングにはThree.jsを使います。両者の受け渡し方法は意図的に選びます。 個性のある仕上がりを目指す場合は、有用な参考資料をもとにカラーパレットとマテリアルの方向性を練ります。各パーツへの割り当て、表面のスケール、光への反応に落とし込みます。マテリアルの調整は優れた形状を引き立てますが、形状と接合部はそれぞれ別に評価し続けてください。 指向性のあるライティング、実用光源、昼夜、またはスケールを変更するライティングを追加または変更する場合は、リグを実装する前にライティングの方向性とスケールを読んでください。発光体と受光体の関係、および最終的なワールドスケールを特定します。芸術的な表現は自由に選べます。
7. モデルに沿った動作にします。 変換、関節、接触、コントロールを、それぞれの信頼できる状態に結び付けます。周囲のオブジェクトも確認します。台には支えが必要です。光線はモデル化されたシーン内で不透明な障害物に当たれば止まる必要があります。生き物には十分な空間が必要です。イラストでは物理現象を単純化してもかまいませんが、実際には行っていないシミュレーションを誤って示さないようにします。 可能であれば再利用するジオメトリは一度だけ確保し、動作中は変換、ユニフォーム、またはバッファを更新します。静的なシーンは停止状態にし、視差効果を抑える設定を尊重します。測定されていない予算に合わせるためだけに、アイデンティティを決定づけるディテールを削らないでください。実際に処理負荷のかかる部分を最適化します。 アイデンティティ、メカニズム、コントロールの効果が不明瞭な場合は、被写体の明確さと意味のある動きを使います。何が変化し、何が固定されるかを説明します。目印、色の意味、表示値を、見た目の状態と同期させます。静止時のシルエットだけでなく、関係する極端な状態でも局所的な変形や接合部を確認します。
8. 実際の出力を実行して確認します。 プロジェクト既存のコマンドでビルドし、利用可能で認可されたブラウザーで成果物を表示します。概要、意味のあるクローズアップ、重要なインタラクションを確認します。自動キャプチャが許可されている場合は、以下の共有コマンドを任意で使用できます。

   pnpm build
   python3 scripts/capture.py --dir dist --all-views --click "#control" --out captures
   

   テスト対象の状態で目に見える動きがあるはずの場合に限り、--motion-check 2000 --expect-motionを追加します。--expect-usableは大きな表示上の失敗を検出できますが、アートの良し悪しは判断しません。ヘッドレス実行が対象外の場合、表示中のブラウザーでの確認も有効です。見ていないフレームを見たかのように説明してはいけません。 ライティングを変更した場合は、露出を固定した光源の分離、参考になる方向変更、出力またはリセットの各コントロールを確認します。光る電球だけでなく、影響を受ける受光体や遮蔽物も確認します。リセットを約束するコントロールがない限り、ライティングモードを変えても、ユーザーが選んだ動きやカメラ設定を維持します。
9. 被写体と根拠に基づいて改良します。 ビジュアルレビューと インタラクション／フレームの確認を、状況に応じたプロンプトとして使います。事実誤認、動作しないコントロール、誤解を招く関係性を修正してから、最も影響の大きいビジュアル上の弱点を改善します。形状の失敗には、テクスチャの追加やキットの段階を上げるのではなく、構築方法の変更が必要な場合があります。ピンチ、外れた接合部、繰り返し発生するポーズ修正には、領域ごとの変形診断を使います。ソルバーの精度、表面の変形、ビジュアル品質は、別々の根拠で評価する必要があります。ジオメトリを変更した後は、オーナーシップとリグに関する前提を見直します。有用な改良を続けます。決まった回数だけ表面的な調整を重ねるのではなく、何度も失敗する手法を再評価します。
10. 正直に報告します。 構築したこと、実際に確認したこと、数値で検証したこと、依然として制約があることを分けて示します。ビルドの成功やコレクションの完成だけでは、芸術的な承認や被写体の明確さは証明されません。スキルの使用を説明する際は、読んだガイダンス、実際に取得して適用した記録、カスタム作業、実行したツールを区別します。スキルへのリンクだけでは、データセットを使った証明になりません。 大きな成果物では、プロジェクトで必要とされている場合に限り、有用な判断をdesign-system.md、 scene-spec.json、validation-report.mdに記録します。小規模な編集や、ユーザーが対象外とした内部実験のために書類を作成しないでください。該当する場合は、ソースやアセットの権利、およびマテリアルに関する科学的な制約を記録します。

構築方法の選択

方法	役立つ場合	維持すること
キットをそのまま再利用する	形状、構造、挙動、仕上がりが実際の要件にすでに合っている	想定される距離から確認します。適合するなら、キットを主役にできます
キットを調整する、または再利用可能なパーツを組み合わせる	一般的な構造は役立つものの、個性や挙動が異なる	シルエット、プロポーション、接合部、素材、関節構造を変更します。色を変えるだけでは不十分な場合があります
カスタムジオメトリ／マテリアル／リグを作成する	個性的な主役、分析用の形状、参考資料、または機構に別の解決策が必要である	低レベルの操作やツールは再利用します。カスタムとは、インフラストラクチャを作り直すことではありません
適切な外部アセットを使用する	作成済み／スキャン済み／ソースのジオメトリが、再構築よりも対象に適している	出所、権利、スケール、位置合わせ、トポロジー、そしてアセットが実際に何を表しているかを確認します
方法を組み合わせる	部分や役割によって、異なる手法が適している	スタイル、スケール、状態の所有者、インターフェースに一貫性を持たせます

主役か背景かという役割も、BlenderかThree.jsかという選択も、それだけで構築方法が決まるわけではありません。構築の仕組みは自由に再利用し、完成形状は適合する場合に限って再利用してください。データセットに項目がないのは、カバレッジの不足を意味するのであって、その手法が利用できないという意味ではありません。創造性を発揮するために、特別な理由を示す必要はありません。

役立つ箇所だけ読む

• カタログ：トピック別の候補。カバレッジと不足箇所が明記されています。
• 条件付き推論：モデルと検証方法の選択。
• 物理的な相互作用：支持、クリアランス、接触、因果関係。
• 動きと状態：再生、関節構造、インタラクション。
• デザインの統合：オブジェクトを一律にせず、視覚システムに一貫性を持たせます。
• キット：再利用可能な設計図と、対象範囲を絞ったパイプラインの実証。
• Blender／Three.js間の引き継ぎ：ツールの役割とアセットの受け渡し。

小さな編集

影響を受ける挙動やビジュアルを直接確認し、変更します。機能しているインタラクションとユーザーの選択を維持してください。テキスト、色、または小さなジオメトリの編集に、新しいシーンやワークフロー全体は必要ありません。