xiaotao-02/wireframe-3d

wireframe-3d は何をしますか？

実体オブジェクトや生産プロセスを、観察可能、分解可能、説明可能な3D作品にします。ユーザーの目標に応じて制作の重点を割り当てます。構造解説はメカニズムの説明を優先し、参照モデリングは目に見える形状を優先して再現し、その後ユーザーが必要とする構造、動き、インターフェースを追加します。

目標は2つの項目で検収します：構造/インタラクションの利用可能性と参照形状/視覚表現の一致。前者は後者の代わりにはなりません。過去のケースの効果が、新しいテーマの品質を自動的に証明するものではありません。

ユーザーが画像を提供し、モデリング、複製を要求したり、「似ていない/使えない」とフィードバックした場合、構築方法の選択、テンプレートの適用、および本体の生成の前に 参照モデリングと初回納品 を読んでください。まず、識別性を決定する輪郭、曲面、開口部、マテリアルを確認します。このスキルを呼び出したからといって、自動的に簡略化された解説スタイルに変更してはいけません。1回のユーザーリクエストの中で、レンダリング、図面チェック、必要な修正を自発的に完了し、ユーザーが一次的なビジュアルチェック担当者になるのを待ってはいけません。

このブランチを実行する際は 参照モデリングツール を読んでください。ソース記録を使用して固定された参照根拠を確立し、必要に応じてパッチ曲面/実開口部/曲面付属物ツールを使用し、その後カメラをロックしたグレーモデルとマテリアル比較を生成します。ツールチェックが通ったからといって、図面を見たことにはなりません。

車両などの連続シェルが過度に単純化されているとフィードバックされた場合、連続シェルの段階的修正 を読んでください。まず独立して制御可能な形状と共有境界を再構築し、曲面トリミング後のメッシュ品質を診断し、次にランプキャビティと連続塗装を修正します。各段階で対応するソースコードと固定ビューを保持します。

参照製品にマテリアル階層、貼付部品、または繰り返しの多い詳細が必要な場合、製品モデリングの実際の統合と検収 を読んでください。マテリアルは納品メッシュ上で有効でなければならず、幾何学的結合は実際のチェックで設定され、静的バッチ処理はセマンティクス、動き、および測定対象を破壊してはいけません。まず改善前のベースラインを保存し、同じ参照タスク内で実際の修正を保持します。調整に使用されたケースは開発検証に属し、独立したブラインドテストと呼び替えてはいけません。

構造や動きの解説を作成する際は Anatomyからの移行ワークフロー を読んでください。「操作 → 構成要素の変化 → 観察可能な結果」を決定し、精度を機能的なインターフェース、ガイド、終端、ネガティブスペースに適用します。その制作方法は、このスキルのThree.js実装とは別に追跡し、上流のSVGソート体系を直接コピーしてはいけません。

納品ルートの選択

• ユーザーがエンジンを指定した場合はそれに従います。指定がなく、インタラクティブなWebページが必要な場合：デフォルトは Three.js、Three.jsルート を読んでください。
• Web配信エンジンと幾何学的制作方法は別々に選択します。連続した複雑な曲面の場合は、まず構築が重要な形状を表現できるかを検証します。必要に応じて、利用可能なBlenderで編集可能なメッシュを作成し、Webにインポートします。ユーザーが純粋なプログラムによるモデリングを要求する場合は、この制約に従い、局所的な曲面と開口部を表現できる方法を選択します。単純なロフトのサンプル数を増やすだけではいけません。
• 編集可能なエンジニアリングファイル、オフラインレンダリング、カメラアニメーションが必要な場合：Blender を使用し、Blenderルート を読んでください。
• 両方の配信が必要な場合：部品ID、ジオメトリ、状態の意味を共有し、両端で個別に検証します。1回の実行が、もう一方のエンジンでの合格を意味するわけではありません。
• 構造解説を必要としない一般的な製品モデリングの場合は、インストール済みの threejs-modeling-studio を使用できます。このスキルはその存在を必須としません。
• テーマやモデルが参照と似ていない場合は、テーマと構築方法 を読んでください。建築はまず平面図/立面図/断面図、ボリューム/開口部、サイトの関係を処理し、機械はまず輪郭/軸/空洞を処理し、工場はまずステーションとマテリアルフローを処理します。実際のタスクに応じてブランチを選択します。

参照から構造へ

新しい作品を作成するか、全体的な修正を行う場合、まず視聴者が理解すべき1つの主な情報を書き、ユーザーの要求から「必ず表示/必ず保持/禁止/納品形式」を整理します。実際の表示サイズとデフォルト状態を記録します。既存の要求がある場合はそのまま使用し、表を埋めるために繰り返し質問しないでください。ビジュアル比較と修正 に従って制作し、制作と納品チェック記録 を再利用できます。小さな変更は影響を受ける項目のみを補完します。

1. ユーザーの質問から、外観の再現、構造説明、動作デモの実際のニーズを決定します。参照モデリングはまず形状と重要な可視特徴をロックします。機構の課題は、どの内部部品を可視化する必要があるかを決定します。要求されていない内部機構、動作アニメーション、コントロールパネルは、自動的に初期の作業の焦点にはなりません。
2. 簡潔な部品表を作成します：id / 役割 / 所属アセンブリ / パラメータ / 接続オブジェクト / 動作 / ソース。機構の課題はまず帰属、接続、因果パスを決定し、次に切断、展開、または引出線による表現を選択します。機構原理のソース検証とアニメーションの実行可能性は別々に記録します。実際の部品、視覚的な補助部品、説明用パーティクルは分けます。工場は別途、ステーション、マテリアルパス、上下階の搬送、工程条件をリストします。
3. 図面や実際のモデルがある場合は優先的に使用します。寸法がない場合はスケールが概略であることを宣言し、内部パラメータの一貫性を保ちます。オリジナルのサンプルを、参照作品の元のエンジニアリング、複製結果、または公開モデルと言ってはいけません。
4. 最初にボリューム、輪郭、接続、内部空洞を作成し、次に機能的な詳細を作成します。穴は実際の開口部、パイプは肉厚、ブラケットは力の関係がわかるようにします。一連の直方体とラベルでコアな機械構造を置き換えてはいけません。
5. モデリング予算は実際の目標、可視度、識別性に基づいて決定し、固定部品数や固定工数を適用しません。複雑な曲面には適切なパッチ曲面、サブディビジョンメッシュ、断面ロフト、回転、スイープ、または信頼できるアセットを使用します。まず代表的な部分を検証し、次に全体に拡張します。アセットソースとプログラムによるモデリングの貢献は別々に説明します。
6. ユーザーが既存の作品の再現を要求する場合、まず「参照特徴 → ソースファイル/関数 → 実装 → スクリーンショット/状態証拠」の表を作成し、比較可能なカメラをロックします。全体像とクローズアップの両方が合格する必要があります。ソースレコードの数は形状の類似性の代わりにはなりません。具体的な手順は 参照再現とアニメーションチェック を参照してください。
7. グレーモデルはまず主要な輪郭、ネガティブスペース、接続を調整し、次に構造、マテリアル、ライティングを補完します。元のデータが不足している場合は推測を記録します。ビジュアル比較と修正 に従って、一致、差異、未検証を個別に記録し、重要な形状の問題を発見した場合はモデルの修正を続けます。

工場HTMLを移行する際は 元の表示コードと機器復元 を読んでください。ステーションごとに robotSvg/toolSvg シェルと断面方向を復元し、draw() の外部タイムオフセットと負荷ゲーティングを確認します。まず代表的なステーションを検収し、次に安定したIDに基づいて拡張します。assets/lib/source-frame.js は矩形アームセグメントの方向付けを提供します。ケース固有の状態と機器は、任意のテーマの自動ジェネレーターと見なしてはいけません。

保持すべき関係

新しいテーマにインターフェースの嵌合、スライド、配管がある場合は、インターフェースと組立チェック を読み、assets/lib/assembly.js を使用してインターフェース座標、法線、口径、関係、実際のメッシュチェックを一緒に納品します。pass は設定されたルールのみをカバーします。予算超過/未設定の場合は明確にマークする必要があります。意図的にインターフェースを切断したり、実際の口径を変更したりするなどの反例を使用して、チェッカーをテストします。

監査とプレビューは同じルート、意味部品、およびその実際のメッシュを参照する必要があります。ツリーから切り離されたコピー、選択ボックス、監査エンベロープはテストの代用にはなりません。開口部/接合面プローブは独立した基準を維持し、実際のコンポーネントを故意に変更した場合はそれを検出できる必要があります。詳細の表示が完全かどうかは、依然としてクローズアップで判断する必要があります。

• 同じパラメータソースがジオメトリ、アセンブリ位置、アニメーション、および読み取り値を生成します。rest + explode * offset は基本的な分解モデルです。リセットは保存されたrest poseに戻り、累積的な平行移動を回避します。
• アニメーションは最初に状態と遷移条件をリストし、次にレンダリングを行います。分解後に開始する場合、アセンブリが実際に収束するのを待ってから、動作サイクルを再生します。一時停止はバネ、ノイズ、パーティクル、読み取り値をフリーズします。停止時にトレイルがある場合、エフェクトを直接削除してはいけません。オフセットバネが必要な場合は、独立した部品状態で駆動し、スライダーの目標値を実際の位置と見なしてはいけません。
• Webでは、assets/lib/motion.js と scene-runtime.js を優先的に再利用し、UI、状態サンプリング、スクリーンショットチェックが同じ setPose を通過するようにします。複雑な動作サイクルは、純粋な状態モジュールに拡張できます。共有状態と再生可能な検収 を読み、ケースごとにクロックを書き換えたり、繰り返し呼び出しで変位を累積したりしないようにします。
• ピボットは実際の回転軸またはアセンブリインターフェースに配置し、子部品は所属するアセンブリに従って移動します。最初に部品に名前を付けてからインタラクションを行います。作成順序でオブジェクトを推測してはいけません。
• 展開時の重なり、黒い断面、薄いブレードの裏側、または動作のずれが発生した場合、展開と動作の修正 を読んでください。セマンティックモジュールに従って位相を設定し、実際のメッシュ間隔をチェックし、重なり合う反例を注入します。ボタンやパーセンテージのみをチェックしてはいけません。ランタイムライブラリは setPose の後に展開を適用します。古いコードを移行する際は、変位の重複を避けてください。
• プロセスフローは実際のパスと現在の状態に依存します。分解後に切断された接続は、「スムーズな」マテリアルフローや流体を表示し続けてはいけません。フローラインを非表示にするか、明確な破線で説明します。
• 部品の非表示、透明表示、クリッピングプレーン、およびキャップ付きソリッドカットは異なる機能であり、実際の実装に従って名前を付けます。クリッピングプレーンにキャップがない場合、ソリッドカットが完了したと宣言してはいけません。
• 概略的な位相やデモ速度は表示できますが、実際の回転数、温度、流量、サイクルタイム、圧力などはソースまたは計算が必要です。パーティクルの流れはCFDと同等ではなく、ギアの回転は動的解と同等ではありません。
• 工場シーンはフロア/ワークショップ/ステーションで整理し、その後プロセス状態を機器とマテリアルにマッピングします。プロセス説明は資料から、ビジュアルグループ化は実装上の選択です。これらを混同してはいけません。
• 工場移行時は、draw() の外部オフセット、HOMEウィンドウ、負荷帰属を確認します。assets/lib/process-timing.js の独立したクロックと境界サンプリングを再利用できます。各ハンドオフポイントの前、時、後に1フレームずつチェックします。等間隔サンプリングのみを使用して境界をスキップしてはいけません。

ビジュアルとインタラクション

2つの元プロジェクトの画風を維持する必要がある場合は、統一イラストレーション を読み、illustrationPalette() と renderStyle:'anatomy-light' を使用します。共有ペーパーサーフェス、制御された法線シェーディング、深度テストによる細かい輪郭、セマンティック強調色を使用します。同じカメラ位置で最終スクリーンショットを比較します。同じ色値やテスト合格で画風検収を代替してはいけません。

構造解説で外観スタイルが指定されていない場合、Anatomyの明確な輪郭、控えめなマテリアル、セマンティック強調色を継承します。参照複製の場合は、参照とユーザー要求でスタイルを決定します。写実的な製品は適切な被写界マテリアルと renderStyle:'studio' を明示的に選択します。イラスト表現が必要な場合のみ anatomy-light を使用します。スタイルを切り替えてもエラー曲面は修正されません。実際に図面を見る必要があります。

構造解説では、最初の画面で本体、主要な内部構造、理解可能な動きを確認できるようにします。外観表示では、最初の画面は完全なアセンブリの本体を主とし、参照でサポートされていない内部構造を表示するために完全に透明なシェルを使用してはいけません。十分なスペースのある主ビューを提供します。ラベルは実際の部品位置に従って配置し、オクルージョンとスクリーンスペースでフィルタリングし、1画面に数十本の引出線があってはいけません。

Webでは通常、回転/ズーム、分解/組立、部品選択、一時停止/リセットを提供します。工場では必要に応じてフロアと工程フィルターを追加します。ネイティブフォームコントロールはキーボード操作が可能で、reduced-motion に従い、画面がオフスクリーンまたはページが非表示の場合は計算を一時停止します。説明に関係のないダッシュボードを機能追加のために設置してはいけません。

デフォルトのWeb開始点は、コンパクトなトップバー、ラベルパネル、常駐デモコントロール、フォーカスモードを使用します。複雑な説明は必要に応じて展開します。新規またはプレビューUIの最適化時は プレビューUI を読み、assets/web/preview-ui.css / preview-ui.js を再利用すると同時に、モデルのフレーミング安全マージンと狭画面での操作性をチェックします。レイアウトはユーザースタイルに合わせて調整できます。

実行可能な開始点

新しいThree.jsテーマは、buildScene() 独立ビルダーと prepare_web.py --builder を優先的に使用します。デフォルトのプレビューは渡された部品IDで動作し、もはやポンプの hub/rotor/cover を借用する必要はありません。コンポーネントライブラリとテーマインターフェース を読み、必要に応じて assets/lib/ の中空回転体、異径管、フランジ付き穴/床スラブ、石壁開口部/窓枠、緩斜面水路、カメラ/照明ツールを呼び出します。これらは変更可能なオリジナルコンポーネントであり、任意のオブジェクトの自動モデラーではありません。

--example river-pavilion / --example flanged-chamber はオリジナルの建築/機械ツール検証問題です。ユーザーが指定した複製対象の代わりにはなりません。既存の scripts/make_demo.py、prepare_web.py --scene、build_blender.py は遠心ポンプ共有リストルートを保持します。JSの新しいコンポーネントと汎用プレビューはBlenderを自動的にサポートしません。それぞれ実装と検証を行います。

--example pneumatic-press は新しいインターフェース、実際のメッシュ特徴、ストローク、接続図、イラストレーションの例を提供します。新しいJSインターフェースチェックとシェーダーはBlenderに自動的に移行されません。Web検証をデュアルエンジン検証と見なしてはいけません。

--example contact-switch はAnatomyボタンメカニズムの独立した3D再構築を提供します。実際のガイド穴、可変ピッチスプリング、6つの終端、ワイヤーとベースプレートのクリアランス、および実際の接点ギャップによって駆動される読み取り値。これは開発例であり、すべての新しいテーマのブラインドテスト結果と見なしてはいけません。

--example indexed-workcell はオリジナルのプロセス開発例であり、異なる機器ビルダー、独立したサイクルとHOME、マテリアル帰属、マルチカラー動的キャッシュを示します。factory-process.js の明示的な機器マッピングと条件サンプリングを再利用します。未知の機器は静かに汎用ボックスにダウングレードしてはいけません。verify_migration.py --three <threeパス> --report <JSON> を実行して、これらの関係と配色/投影の反例をチェックし、その後ページを実際に確認します。

• 共有データ契約：座標、ジオメトリ、状態、検証境界。
• ソースと移行マッピング：上流ファイル/関数へのインスピレーション、再実装部分、ライセンスを正確に。
• ユーザーが既存のオープンソースケースを指定した場合、既存作品の3D移行 を読んでください。表示ジオメトリと監査プロキシ、純粋な状態抽出、インスタンス化、実際のブラウザ検証。
• scripts/validate_scene.py：ID、有限数、退化面、閉じたメッシュ、正の有向ボリュームをチェックします。閉じたソリッドにのみチェックを適用します。開放曲面はルールを調整し、説明を追加する必要があります。
• インターフェースチェックを変更した後、scripts/verify_assembly.py --three <インストール済みthreeパス> --report <出力JSON> を実行し、新しいテーマに実際の穴/接合面/ギャップとエラー反例を設定します。現在はThree.jsチェックのみを実装しています。
• 共有JSコンポーネントを変更した後、scripts/verify_components.py --three <インストール済みthreeパス> --report <出力JSON> を実行し、開口部、肉厚、異なる寸法、カメラセーフゾーンを確認します。その後、影響を受けるサンプルを実際に開きます。数値チェックは美観を評価しません。
• 展開またはフレーミングを変更した後、scripts/verify_explosion.py --three <インストール済みthreeパス> --report <出力JSON> を実行します。実際のテーマは explosionChecks を設定し、verify_scene.py で検収します。設定されていない場合は合格と見なせません。プレビューには serve_preview.py --root <出力ディレクトリ> --port <開始ポート> を使用します。ローカルのみの空きポートにバインドし、開発キャッシュを無効にします。生成後、リロードして現在の成果物を確認します。
• 新しいテーマは scripts/verify_scene.py --builder <subject.js> --three <インストール済みthreeパス> --report <出力JSON> を実行できます。その後、現在の環境で許可されているブラウザツールを使用して操作し、スクリーンショットを撮影します。独立したブラウザ自動化が許可されている場合は、node scripts/verify_preview.mjs --url <ローカルプレビューURL> --out <証拠ディレクトリ> を実行し、スクリーンショット、状態、エラーを記録し、その後手動で図面を確認します。使用方法、ツールの制限、範囲については 共有状態と再生可能な検収 を参照してください。

スキルを使用するために、上流リポジトリ全体を実行プロジェクトにコピーしてはいけません。上流の iso-kit、tube、lathe はSVG生成体系です。このスキルのThree.js/Blenderジオメトリ、深度テスト、インタラクションは独立した実装です。

検収と納品

実際の機能に従って実行し、再確認可能な結果を保持します：

1. ジオメトリ：パラメータ/ID/単位/有限数をチェックします。重要な穴、肉厚、軸心、接触、ギャップは対象を絞った検証を行います。データチェックは画像チェックの代わりにはなりません。
2. 状態：アセンブリ、半分解、全分解、リセットをチェックします。実行時の読み取り値とジオメトリの位相が一致し、一時停止時にジャンプしないことを確認します。衝突は、接触が予期されない部品のペアに対してのみテストします。通常のアセンブリ接触を常にエラーと判断してはいけません。
3. 画面：実際の表示サイズで、デフォルトの最初の画面、主ビュー、背面/側面ビューをチェックし、本体の比率、オクルージョン、めり込み、宙に浮いた部品、マテリアルの差異、シャドウ、テキストの可読性を確認します。Webでは狭い画面でテストします。Blenderでは .blend ファイルを再度開き、オブジェクト、ドライバー、フレーム状態を確認します。 オリジナルがある場合は、同じカメラ位置での全体像と機能的なクローズアップを追加します。透明、スモーク、または炎がある場合は、その前後のオクルージョンと停止プロセスをチェックします。ジオメトリと純粋な状態が合格した後でも、実際にシェーダーをコンパイルして画面を観察する必要があります。
4. 納品読み返し：ユーザーが受け取るエントリまたはファイルを再度開き、ターゲットビューアで4つのカテゴリの要件に従って PASS / FAIL / NOT_RUN を項目ごとに記録します。エクスポートがある場合は、ネイティブエンジニアリングファイル、エクスポート物、最終的なキャリアをそれぞれチェックします。アニメーションがある場合は、ユーザーが経験するフローを完全に再生し、動作、テキスト、読み取り値を確認します。フレームサンプリングは連続チェックの代わりにはなりません。コンソールまたはBlenderログをチェックします。測定後にのみパフォーマンスを報告します。

現在のThree.jsテンプレートは、prepare_web.py によってファイルハッシュリストと build-info.js が生成されます。verify_preview.mjs --expect-build <リストid> を使用して、スクリーンショットを実際のバージョン、ページ、カメラ、状態、読み返されたビューポートにバインドします。画像は依然として手動で確認する必要があります。対応するバージョンやビューポートを読み取れない場合、古いスクリーンショットを新しい結果として流用してはいけません。バッチインスタンス変更後は、面と輪郭のマトリックスと数を同期します。ソースマテリアルのセマンティクスを保持し、すべての細いロッドを太くして詳細を作り出してはいけません。

納品エントリ、編集可能なソース、必要なリソース、少数の重要なスクリーンショットを提供します。ソースの事実、オリジナル/改変部分、実行済み検証、未検証項目を報告します。ユーザーが複製を要求する場合、実際の参照に一致させ、付属のポンプサンプルで代替してはいけません。

エクスポート、複数バージョン、または明確な納品要件がある場合は、証拠と納品ツール を読んでください。要件を最終的な読み返しと対応付け、ソースコードとスクリーンショットのハッシュをバインドし、期限切れの記録を防ぎます。排他的ポートを使用してローカルプレビューを開始し、検証済みの独立したスナップショットでバージョンを保持します。ツールは証拠の関連性とファイルの整合性のみをチェックでき、ビジュアル再現度を自動的に評価することはできません。

スキル自体を反復する場合、変更に応じて evals/evals.json から独立した問題と実際の入力を選択します。これらは実行される評価プロンプトであり、合格記録ではありません。開発例、歴史的回帰、新しいテーマの評価は別々に記録し、同じケースのみを繰り返し調整して一般化された結論を導き出さないようにします。