3

私は現在、Maya ASCII .ma をソース フォーマットとして使用し、物理およびグラフィックスの独自のフォーマットを出力として使用して、インディー ゲーム用のインポート ベースのパイプラインの作成に取り組んでいます。ヒンジ ジョイントなど、Maya 内の可動域アトリビュートのようなものを保持します。多くの微調整が必​​要な他のタイプのパラメーターは、別のソース ファイルになります (おそらく、質量、バネ定数、物理エンジンの強度などの .ini ファイル)。

したがって、入力は 1 つの .ma と 1 つの .ini であり、出力は特に 1 つの .physics ファイルと複数の .mesh ファイル (ジオメトリ/マテリアルごとに 1 つの .mesh ファイル) です。

また、おそらく Python 3.1 を使用してデータを再フォーマットする予定であり、基本的な Maya ASCII を読み取る LGPL 2.1 コードをすでに見つけています。おそらく、開発中にプラットフォームを起動するために Python も使用するでしょう。ゲームは C++ で開発されています。

このすべての中で、あなたが反対するようアドバイスするものはありますか? 欠陥がある可能性のあるものの簡単な要約:

  • 輸入ベースのパイプライン (輸出ベースではない)?
  • マヤ（3DSではない）？
  • Maya ASCII .ma (.mb ではない)?
  • .ini (.xml ではない)?
  • Maya のモーション アトリビュートと .ini の「freak-tweak」アトリビュートの分離 (Maya のすべてではない)?
  • データを構築するための Python 3.1 (埋め込み C++ ではない)?

編集: 物理/グラフィックスのインポート/エクスポート ツール チェーンを実装する方法についてより良い提案があれば、ご意見をいただければ幸いです。

4

3 に答える 3

4

本当にこれを行いたい場合は、いくつかのことに注意する必要があります。主なものは、おそらく最初に予想したよりも面倒だということです. 他のいくつかは次のとおりです。

  • Maya .ma (少なくとも現在の v.2010 まで) は mel によって構築されています。Mel はチューリング完全ですが、ノードの観点から階層シーンを記述する方法は、「コード」よりもはるかに簡単です。
  • エラー処理を早い段階で追加しないと、後で後悔することになります。
  • 多くの異なるノードを処理する必要があり、変換が最も厄介なものです。その他のタイプには、メッシュ、マテリアル (さまざまなタイプ)、「シェーダー エンジン」、およびファイル (テクスチャなど) が含まれます。
  • .ma は形状と微調整のみを記述します。しかし、生の頂点を定義することはめったにありません。Maya とまったく同じ方法ですべてのプリミティブを生成する必要がないように、.ma 内に小さな「エクスポート」スクリプトを保持することにしました。後から考えると、これが正しい方法でした。それ以外の場合は、次のようなことができる必要があります
    1. 「球を作成する」、
    2. 「半径あれこれのソフト選択範囲をこちらからあちらへ移動」、
    3. 「頂点を 252 xyz 単位移動」(すべての頂点が暗黙的に定義されている)。
  • Maya はメッシュのポリゴンを定義します。rt を三角形に変換したい場合があります。
  • 特定のタイプのノードに存在するすべてのパラメーターは、明示的または暗黙的に定義されます。デフォルト値を知っておく必要があります (暗黙的に定義されている場合)。
  • 基本的に、オブジェクトはトランスフォーム、メッシュ、およびプリミティブによって定義されます。トランスフォームはメッシュの親です。変換には、スケーリング、回転、平行移動、ピボットの平行移動などが含まれます。メッシュはプリミティブにリンクし、その逆も同様です。プリミティブにはタイプ (「polyCube」) と寸法 (「幅、高さ、深さ」) があります。
  • ノードには「多重継承」がある場合があります。たとえば、複数回インスタンス化されたメッシュには 1 つのメッシュ (および 1 つのプリミティブ) がありますが、複数の親 (変換) があります。
  • ノード トランスフォームは次のように計算されます(詳細については、Maya xform docを参照してください)。

vrt = getattr("rpt")
rt = mat4.translation(vrt)
...
m = t * rt * rpi * r * ar * rp * st * spi * sh * s * sp
  • 私は物理学に基づいてエンジンを構築しているため、ゲーム エンジンは物理的な形状に配置されたメッシュを必要としますが、モデリング時にはその逆を必要とします。これは、将来のアプリケーション (「物理のないメッシュ」) のために汎用性を維持するためです。このささやかな決断が、私を変容させる大きな悲しみの原因となりました。線形代数がブラッシュアップされました。スケーリング、回転、平行移動、剪断の問題。あなたはそれに名前を付けます、私はそれを持っていました。
  • cgkitの Maya パーサーでインポート ツールを作成しました。ありがとうマティアス・バース！
  • 似たようなことをするつもりなら、自分のコンバーターを書く前に私のコンバーターをのぞき見することを強くお勧めします。この「小さな」プロジェクトは、基本的な作業状態になるまでに 3 か月の苦痛を伴いました。
于 2009-12-01T11:37:17.157 に答える
1

.maパーサーを再実装し、それを解釈するために必要なすべてのMaya内部を複製する代わりに、エクスポートベースのパイプラインまたはOBJやCOLLADAなどの標準化されたファイル形式の使用を検討する必要があります。

.ma / .mb形式は、Maya自体以外のプログラムで読み取ることを目的としていないため、オートデスクはこれを簡単なプロセスにするための努力をしていません。100％正しく解析するには、MELスクリプト言語全体を実装する必要があります。

私が見たすべてのMayaベースのパイプラインは、最初にコンテンツを標準化されたファイル形式にエクスポートするか、Maya内でMELスクリプトを実行して、MELノードインターフェイスを使用してコンテンツをダンプします。

Mayaは、GUIをロードせずに、シーンをロードし、MELスクリプトを実行し、存在する「ヘッドレス」モードで実行できることに注意してください。したがって、自動ビルドシステム内で問題なく使用できます。

于 2009-12-24T04:44:16.983 に答える
1

人間が読める形式と人間が書き込める形式の両方で、優れたPythonサポート（そして実際にはあらゆる言語サポート）を備えた一般的なシリアル化形式として、iniファイルまたはXMLではなくYAMLまたはJSONの使用を検討することをお勧めします。

手作業でファイルを生成することがない場合は、XMLを使用できます。

JSONとYAMLの利点の1つは、入力です。どちらの形式も、Pythonリスト、辞書、float、intに解析されます...基本的には、正常なPythonタイプです。

また、使用するすべてのライブラリが3.1で動作することが確実でない限り、ライブラリの可用性の問題のため、2.xを少し使用することを検討することをお勧めします。

于 2009-07-21T12:01:28.937 に答える