3Dモデリングツールへの要望 (Request for 3D Modelling Tools)

　3Dモデリングツール(3Dモデラー)への個人的な要望を書き連ねたものです。なかなか時間的にも高度な部分では能力的にも自身では届きにくいので、本腰の3Dモデラー開発者さんの目に届くことを願って書いてみます。この要望の視点はゲーム用途が多く、１つ１つの機能よりも、全体的なシステムへの要望となっています。

　これからの3Dモデリングツールへ個人的に求める機能を大雑把に列挙してみたいと思います。実用上の違いがなければ、実装が本体組み込みか、プラグインによるのかは問いません。
　既存のモデラーや計画中のモデラーが実装済みか対応予定であるかどうかに関わらず、望む機能を並べました。
　幾何モデリングのみのツールは選択肢がいくつかありますが、幾何からキャラクターアニメーションまでの（利用者視点で見て）完全統合が能率上重要（かつ、思いつきで作業ができる）となるので、これを謳うモデラーを強く希望します。
　本格的なモデラーの方の意見を入れつつ、以下のことも考慮してもらえればありがたいと思います。

各種幾何モデリング機能: 基本機能はおそらく実装されると考え、多くは列挙しない。曖昧なモデリングも数値入力も楽にできれば助かる。
ゲームなどリアルタイム用途: 考慮を希望（編集できるモデリング内容、カスタム付加情報）。また、X File（出力を中心として）などの完全サポートがあると重宝するだろう。
稜線（辺）の扱い: 面を構成するものという従属的でよいが、稜線を選択して各種編集ができること。これで編集効率が違う。
N-gon(５頂点以上のポリゴン): あると助かる。
線（２頂点ポリゴン）: あると助かる。
細分化曲面のウェイト: 角になるか丸くなるかについてのウェイトは、頂点と稜線に対しての両方がサポートされるべき。
対応3DAPI: 今のところ個人的にはDirectXのみでかまわない。
シェーダ: 頂点シェーダ、ピクセルシェーダを扱う機能が欲しい。機能拡張されなくなった過去のモデラーとの大きな違いとなりうる。
統合環境・ビルド環境: 開発言語のIDEのような統合環境があり、編集用データをスクリプトで加工して完成版にするような機械的な作業行程を自動的にできるようにする。プロジェクトファイルなどを持つ。ZIP形式など一般的な書庫と相互連携できるとよりよいだろう。書庫APIを提供しプラグインで他の形式を扱えるようにするのもありだろう。プロジェクトに必要なファイル数が増え、作業ファイルとマスターアップとの間に機械的な最終ステップが必要となるような、本格的な用途での自動化手段がシステムで提案されていれば助かるはず。プログラミング用のIDE・ビルドツールとの相互運用までも考慮に入っていればなおよい。
データ形式: おそらく各種形式はプラグイン対応となるだろう。幾何やモーション、プラグインの拡張データなどが１つのファイルにインラインになるオープン仕様な形式も欲しい。フォーマットとしては、汎用的な処理で扱いやすいXMLベースの形式の対応、たとえばCOLLADA（扱いやすいかは分からないが）などへの対応があると便利そうに思う。
法線の扱い: モデラーが必須でなくとも法線の埋め込み形式も仕様化しておき、法線を保持できる各種出力形式で簡単に出力できるようにして欲しい。プラグイン作成が少し省力化されるだろう。ローポリゴン用途やN-Patchなど細分化用として法線を活用したい場合も考えられる。法線を直接編集する機能や、法線を複数保持できることも検討されたい。また、シェーダテクニックで法線(Normal)のみならず、接線(Tangent)や従法線(Binormal)が必要とされる場合があるので、これを法線と並列するような形で管理できると価値が高いだろう。
対応画像形式: テクスチャなどに使う画像は、JPG/PNG/PSD/DDSなどいくつか対応希望。ハイダイナミックな画像も考慮されたい。
ボーン: Direct3Dがアクセラレーションできる仕様のボーン対応が少なくも必須。
マテリアル: GIレンダラーがサポートするようなパラメータおよび、Direct3Dで使う基本的なパラメータ、ピクセルシェーダで扱うようなパラメータをうまく扱えると助かる。
頂点毎のテクスチャ座標(UV)の編集: 必須。各頂点に複数のUV座標の保持は欲しい。
カスタム付加情報: 頂点や面には頂点シェーダやピクセルシェーダや、プラグインと特定用途のために応用できるような任意用途の追加データをつけられることを希望。付加データの用途を管理できる機構も希望。
細分化曲面: 必須。基本的にポリゴンへフリーズせずに全ての作業ができることが希望。
鏡面編集: 軸に平行な面での対称オブジェクトの編集機能。対称が手違いで崩れないように片側は仮想の状態が理想。ただし、モーション付けなどで対称を逸脱する可能性があるので、このあたりの混乱を最小にする必要がありそう。
回転操作および姿勢回転データ表現: 少なくともクォータニオンへの対応が必須。
レンダリング: 外部レンダラーの制御でよいだろう。しかし焼き込み機能には配慮が必要。
焼き込み: 高精細モデルをレンダリングした結果を簡易モデルのテクスチャや頂点への（色・法線マップ・GIの結果など任意の）焼き込みがあると非常に効果的。ただし、レンダラーとの細かな連携が必要となる。また、この行程を手作業で進めると手間が掛かるので、ビルド機能などで単純化が望まれる。
3Dペインティング（3Dモデルのテクスチャを3Dで直に描きこむ）: ある程度本格的なものを希望。色・透明度・バンプマップ・法線マップには対応して欲しい。ペイントツール的な機能とともに、ドロー系（ベクトルグラフィックス）からラスタライズできたらかなり使えるだろう（この部分はこれだけで単体ソフトウェアになりうるので、プラグイン的な設計した方がよいかも知れない）。シームレステクスチャ編集も考慮したGUIを希望。特にペインティングではタブレットによる描き込みが考慮されていることを望む。
モーション作成: 複数のモーションが１ファイル上で作りこめること。それに応じたモーションやキーの編集機能。モーションと幾何とでファイルをいつでも統合・分離が自由にできることを希望。複数のモーション同士のつながりを容易に確認できる機能。（仮にある程度プラグインに実装をゆだねるとしても、それができる基本設計を希望）
モーションブレンド: 複数のモーションが作成できることを拡張し、ボーン構造の違いを超えて、複数のモーションをミキシング編集できると本格的に使えるだろう。
アニメーションキー: モーションの補完は直線・曲線程度の選択はあった方がよいだろう。
Undo/Redo: メモリの限りできること。
Cut/Copy/Paste: ほぼ全ての編集要素でこの操作ができることが望ましい。複数選択・範囲選択・全選択なども望まれる。
自動保存: 不意の異常終了で作業データが失われる可能性を低減するため強く希望。
ワークフロー: ジオメトリ・テクスチャ・ボーン・モーションなどの一連のモデリングが順不同でいつでも編集できる統合されたワークフローであること。
ビルボード: ビルボード表現のオブジェクトを埋め込めると便利だろうと思う。
バンプマップ・法線マップ: これらはシェーダ経由としても容易に作業できる形とすることが必須。
ディスプレースメントマップ: バンプマップ・法線マップや、モーフィングとの親和性を考慮しつつ対応しているとよいだろう。
UVマッピング: アトラス展開などを含み、何通りかの自動生成が欲しい。すぐ実装とは言わないが、現在はハイコスト（ピクセルシェーダ必須のような方法）だが将来的に可能性の見込みがある展開方法も考慮はされたい。3Dペインティングがきちんとしていれば、一見複雑なUV展開でも描画結果が優れていれば価値があると思う。
モーフィング: 頂点アニメーション機能があるとよさそう。
物理演算: 物理エンジン自体は外部利用でもよいので、あれば重宝されるかもしれない。
インバースキネマティック: 仮に拘束などが設定できなくても、モーション付けでキーの位置決定だけの用途でもちょっと便利なので、あれば作業を省力化できるだろう。拘束などがしっかりできれば、プラグインなどを含め本格的な用途が見込めるかもしれない。
パーティクル生成: あれば便利だろう。作成コンテンツの直接再生が提供されるのならば標準機能ならば、視覚効果を上げるよい道具となる。ビルボードとの組み合わせも便利なはず。
インスタンシング(シーン構築機能): パーティクル生成の機能と共通化できるかも知れないが、仮想的にオブジェクトを複数配置して、マップ作成（レベル作成）のようなシーン構築する機能があると、用途が広がるだろう（ソフトウェア・ハードウェア両面から描画が最適化されればさらに実用的）。これがあるならば、シーンのオブジェクトに対するタグ（属性やイベント）を表現する機構もあるとよい。スクリプトで応用の幅が広がるだろう。
スクリプトのデバッグ: モデラー本体をデバッガから起動することも考慮されるとよいだろう。デバッグ用に起動を最適化するオプション（起動画面があるならばその省略など）や、デバッグメッセージなど、デバッグ用機能の提供。
プラグイン・スクリプト: ほぼ全てのことができるAPIとともに対応することを強く希望。LuaやPythonなどと比べれば腰をすえたプラグイン用となるであろうが、CLR(.NET)への対応を希望。本体が.NET Frameworkに依存しないならば、なくても本体は使用できるようにしておいた方がいいだろう。
モデラーのAPI: 対応の幅を広げるため、APIはフラットな形となると思われるが、Managed言語(CLR)などからのアクセスが楽なように引数・戻り値の型は考慮されたい。モデラー本体がプラグインの不具合を引きずることは最小限であって欲しい。（プラグイン・スクリプトがGCを持つような言語のものならば、メモリを直接扱うような場合を除き、共倒れは抑制しやすいだろう）
ファイルパスの扱い: 全てのファイルパスは相対表現ができること。

機能ではない面への要望: （個人の場合は大変ですが、）安定性（不具合遭遇時の挙動や迅速なパッチ）、ソフトウェア開発が継続していて、機能が徐々に追加されている安心感の有無が大きいと思われます。

お問い合わせがあれば、あるいはなくても、うまく言い表せていない部分は加筆修正します。