>新規に面のユニークIDが設定できるようになりましたが、頂点にもユニークIDを設定するようにできないでしょうか?
>またユニークIDをMQOファイルに保存できるようにしていただけないでしょうか?

頂点もMQObject::GetVertexUniqueID()で取得できますよ。

ファイルへのIDの保存は本当に必要なものなのでしょうか？
おそらくMQOファイル内の頂点・面と関連づけられた何らかのデータを
同時に保存しておきたいということなのかなと思うのですが、
それならOnSaveDocument()がファイル保存前に呼び出され、この時には既に
頂点・面はインデックスが0から順に欠けることなく並んでいるので、
この関数内でインデックスと対になるデータをMQOファイルと同一ファイル名で
別拡張子のファイルを作って保存することで対応できるかと思うのです。
（OnNewDocument()でその別拡張子のファイルの読み込みも可能）

違う用途で考えている場合はまた何らかの考慮が必要かもしれませんので、
できるだけ具体的な用途を提示いただけると有り難いです。

>頂点もMQObject::GetVertexUniqueID()で取得できますよ。
失礼しました。見落としてました。

>それならOnSaveDocument()がファイル保存前に呼び出され、この時には既に
なるほどそういう使い方をするんですね。考えてませんでした。
ただユニークIDが保存できるならプラグイン側はユニークIDで一元管理できて楽かなと思いました。
また実際に次のような状況になるかわかりませんが、MQOデータの作成、保存と同期せずに
プラグイン側のデータを保存したい場合は不都合が生じるかなと思いました。

話は変わるのですが、プラグイン側のデータはプラグインごとに個々にファイルを管理することになるんですよね?
ということはデータ保存するプラグインが増えて幾たびに一つのMQOファイルに対して付随する
プラグインファイルが増えてしまい扱いづらくなってしまうと思います。
でしたらプラグインデータを一括して管理できるファイル形式があると便利だと思うのですがどうでしょうか?

>ただユニークIDが保存できるならプラグイン側はユニークIDで一元管理できて楽かなと思いました。

プラグイン側でユニークIDが必要ならMQOファイル内に保存できるよう、試験的に対応してみました。詳細はSDKのソースコードからm_bSaveUniqueIDを参照してください。
データ量が増えてしまうのと、32bitの上限(0xFFFFFFFF)を超えたときの動作保証がないのが気にかかっていますが…

>話は変わるのですが、プラグイン側のデータはプラグインごとに個々にファイルを管理することになるんですよね?
>ということはデータ保存するプラグインが増えて幾たびに一つのMQOファイルに対して付随する
>プラグインファイルが増えてしまい扱いづらくなってしまうと思います。
>でしたらプラグインデータを一括して管理できるファイル形式があると便利だと思うのですがどうでしょうか?

必要なときのみ保存するようにしておけばそれほどファイルが増えることもないとは思いますが、
統一的な仕様があったほうが良いのは確かでしょうね。
MQO内部に外部データを保存できればユーザーからすれば一番管理は楽なんでしょうが、
それほど柔軟性が高いフォーマットではないのでどうしたものやら。

>プラグイン側でユニークIDが必要ならMQOファイル内に保存できるよう
ありがとうございます。

>それほど柔軟性が高いフォーマットではないのでどうしたものやら。
現状のMQOに新たなデータを加えるのは難しいと思われるので、
とりあえず拡張性の高い内部構造をもった形式で
(データ名、データ形式、データサイズ、データ本体を一つのものとして扱うなどしたもの)
プラグインデータだけを書き出すというのでもいいと思います。

横から便乗させて頂きます。

　当方ではメタセコイアとDCCツール(MAYAやXSI)でボーンのウエイト情報
を相互にやり取り出来るようにしたいと考えています。今まではメタセコ
を挟むとウエイト情報が消失してしまうので非常に不便をしていました。

　今回のプラグイン拡張とSio29さんの提案が取り入れられればあわよくば
ウエイト情報やボーン編集等のキャラクタセットアップまでメタセコイアで
済ませられないか？と思っています。

　しかし、そのの仕様ですと、各種ツールで辺の分断や頂点の追加を行ったり
した場合には対応できなさそうですし、そもそもユーザがウエイトデータを
編集するインターフェイスを提供する事が難しそうです。

　そこで、ちょっとお聞きしたいのですが、現在の仕様でこのような事を
実現する場合Mizunoさん的にはどのような方法を推奨されますか？また、
将来的な拡張でこのような事も視野に入っていたりするでしょうか？

以上、よろしくお願いします。

>　しかし、そのの仕様ですと、各種ツールで辺の分断や頂点の追加を行ったり
>した場合には対応できなさそうですし、そもそもユーザがウエイトデータを
>編集するインターフェイスを提供する事が難しそうです。

逆にお尋ねしますが、どういった仕様であればそういったことに対応
できると思いますか？
今のところテストケースとなるプラグインがないため、
仕様が複雑化しすぎないよう最小限の実装を行うに留めていますが、
ある程度目的が明確になれば必要に応じた拡張を順次行おうと考えています。

>でしたらプラグインデータを一括して管理できるファイル形式があると便利だと思うのですがどうでしょうか?

RC5で必要に応じて拡張子がmqxのXML形式のファイルの保存・読み込みが行われるようにしました。
プラグインごとに割り当てられたXML要素には好きなようにデータを追加することができます。

>RC5で必要に応じて拡張子がmqxのXML形式のファイルの保存・読み込みが行われるようにしました。
ありがとうございます。ほぼ期待どおりです。

ただ少し要望があります。
MQXmlElementはそのプラグイン自身のデータにしかアクセスできないようですが、
他のプラグインのデータにもアクセスできるようにできないでしょうか?
複数プラグインから同一パラメータにアクセスしたい場合などに困ってしまいます。

またMQXmlElementについて質問なのですが、xxxChildElementを使うことによって階層構造を作ることができるのでしょうか?

更に別な質問なのですが、ユニークIDからインデックス値を逆引きする方法がないようにようですがどうやるのでしょうか?
見落としていたらすいません。

>MQXmlElementはそのプラグイン自身のデータにしかアクセスできないようですが、
>他のプラグインのデータにもアクセスできるようにできないでしょうか?
>複数プラグインから同一パラメータにアクセスしたい場合などに困ってしまいます。

実はルートのXMLElementも渡してはいるので、MQBasePlugin.cppの書き換えが必要になりますが、
MQOnEvent()で
MQXmlElement root = (MQXmlElement)ExtractEventOption(option\x2c "root_elem");
の一文を追加すればルートのMQXmlElementも取得できるので、
後は必要な要素を探せばアクセスも可能です。

もっともプラグイン間でのデータ通信ができないとあまり必要性も感じないのですが、
どういった場面で使うことを想定しているんでしょうか？

>またMQXmlElementについて質問なのですが、xxxChildElementを使うことによって階層構造を作ることができるのでしょうか?

AddChildElementで子階層を追加できますよ。（要素名は重複も可）

>更に別な質問なのですが、ユニークIDからインデックス値を逆引きする方法がないようにようですがどうやるのでしょうか?
>見落としていたらすいません。

>MQXmlElement root = (MQXmlElement)ExtractEventOption(option\x2c "root_elem");
>の一文を追加すればルートのMQXmlElementも取得できるので、
ありがとうございます。

>どういった場面で使うことを想定しているんでしょうか？
たとえば頂点をグループ化するだけのプラグインを作ったとして、
他のプラグインでそのグループ化した頂点に対して何かしらの操作をする場合や、
他のプラグイン作者の方のプラグインにてその頂点グループを参照してもらう場合など便利になると思います。困るというほどはないですけど。
ただそうなると今度は常駐型のMQXmlElementが欲しくなったりしますけど…

>総当りで一致するものを見つけるしかないですね。
総当りですか…当面は総当りでもいいと思うのですが頂点や面など数の多いものや参照の頻度が高いものはつらいと思います。
プラグイン側でハッシュテーブルなど作って最適化することはできますが、
頂点が作成、削除された場合など再構築のタイミングが難しいのでできればSDK側で逆引きできる関数などがあると便利だと思います。

>頂点が作成、削除された場合など再構築のタイミングが難しいのでできればSDK側で逆引きできる関数などがあると便利だと思います。

MObject::GetVertex/FaceIndexFromUniqueID()を追加しました。
内部で対テーブルを作成しているので、アクセスには時間はかかりません。
ただ短期間で付けたので、デバッグが全然できておらず、
間違ったインデックスが返される可能性もなきにしもあらずです…。

速度は計っていないのですが、大量の面・頂点を追加・削除したときに若干重くなった可能性もありますなぁ。

>MObject::GetVertex/FaceIndexFromUniqueID()を追加しました。
ありがとうごさいます。