>スクリプトを使ってみたのですが、文法エラーなどで何らかのエラーになった場合にメタセコイアが不安定になってしまって、保存などができなくなることがあります。再現性が定かではないのと、スクリプトの使い方とかがおかしいのかもしれないので、もう少しわかれば追記します。

rc6では問題ないようです。ありがとうございました。
下記スクリプトでマテリアル名の設定を行っているのですが、スクリプトを実行して名前を変更してもドキュメントに変更があったとは認識できないようで、上書き保存のメニューなどが有効にならないようです。


-----
doc = MQSystem.getDocument()
num = doc.numMaterial
for x in range(0\x2cnum):
    mat = doc.material[x]
    if mat is None: continue
    if mat.textureMap != "":
      length = len(mat.textureMap)
      namewk = mat.textureMap
      mat.name = namewk[0:length-4]

スクリプトから材質を変更してもアンドゥ対象に含まれいなかったので、RC7でこれを含まれるようにしました。上書き保存もできるようになります。

あと、アンドゥ後にスクリプトから材質へアクセス(getMaterialなど)するとエラーが起こったりしていたので修正しました。たぶんこれで安定性は向上したと思うのですが、まだ何かありましたら引き続きご報告いただけると幸いです。

>あと、アンドゥ後にスクリプトから材質へアクセス(getMaterialなど)するとエラーが起こったりしていたので修正しました。

オブジェクト削除後(オブジェクトを0個にはしてません)にもエラーが出てましたのでRC7で試してみたところ、RC6以前と同じくエラーが発生しました。

---
from math import *

doc=MQSystem.getDocument()

pos=[]
for obj in doc.object:
    for vert in obj.vertex:
        if vert.select:
            pos.append(vert.getPos())
if len(pos)==2:
        
    vx=pos[1].x-pos[0].x
    vy=pos[1].y-pos[0].y
    vz=pos[1].z-pos[0].z

特に問題ないと思いますが…

元からの仕様として、ドラッグの開始位置は頂点付近でないといけないのですが、
もしかして面の上からドラッグしようとしていませんか？

こちらも同症状でています。
以前はできていました。

追記です。

ボタンをマウスで押しての操作はできました。
どうやら、ショートカットで同操作を行うと、
画面上はボタンが押されていても、
実際は押されていない、という状態になっているようです。

>どうやら、ショートカットで同操作を行うと、
>画面上はボタンが押されていても、
>実際は押されていない、という状態になっているようです。

不具合確認できました。
確かにマウスのほうしか試していなかったです。

ちょと意味が取れない部分もあるので、間違っているかもしれませんが
環境設定＞操作＞視点操作＞回転の中心位置
で解決できそうな気もしますが、どうでしょうか？

回転ではなくズームなので、恐らく LW のモデラと同じ挙動の事を言っているのではないかと。
「マウスカーソルの位置を中心にしてズーム」ですよね。
個人的にも(選択式で)あると嬉しい機能かもです。それこそ LW と同じ操作で使いたいですね。

私も個人的にはRhinocerosの操作ようにズーム等したい場所にマウスのカーソルを移動させその位置でマウスのホイールでズームイン、ズームアウトできればうれしいので可能であれば機能につけてほしいです。

>1)マウスカーソルがオブジェクトパネル上にある際、
>　ホイール操作によってオブジェクトパネルがスクロールするように。
>

上記1)はオブジェクトパネルではなく、コマンドパネルのあやまりでした。
失礼致しました。

>1)マウスカーソルがオブジェクトパネル上にある際、
>　ホイール操作によってオブジェクトパネルがスクロールするように。

RC5でオブジェクト・材質パネル上でホイールすると、そのパネルが
スクロールするようにしました。
と思ったらレスのほうをよく見ていなかったようでコマンドパネルの
ほうだったのですね、こっちはまだ対応していません。

>2)材質パネル、オブジェクトパネルのXサイズ制限解除または緩和。
>4)EXE終了時のウィンドウサイズの記憶。

は対応済み。

>3)EXE終了時のDLL呼び出し。

は新しく追加されたStationプラグインで大丈夫かと。

>新規に面のユニーク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()を追加しました。
内部で対テーブルを作成しているので、アクセスには時間はかかりません。
ただ短期間で付けたので、デバッグが全然できておらず、
間違ったインデックスが返される可能性もなきにしもあらずです…。

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

メタセコの伝統的な操作（手軽な頂点結合はメタセコの売りの1つ）を変えてしまうのはどうかと思いますが如何でしょうか。

変更による大きなメリットがあれば変更の余地もあるかもしれませんが「ショートカット好きが嬉しい」という好みの問題で操作体系を変えてしまうのは忍びないです。

他の人の意見も聞きたいところですが、もし本当に搭載するなら、オプションで任意で選べるようにして欲しいです。

>メタセコの伝統的な操作（手軽な頂点結合はメタセコの売りの1つ）を
>変えてしまうのはどうかと思いますが如何でしょうか。
変えるのではなく、第3の手法としての提案です。

>変更による大きなメリットがあれば変更の余地もあるかもしれませんが
>「ショートカット好きが嬉しい」という好みの問題で操作体系を変えて>しまうのは忍びないです。
書き方が悪かったです。
ショートカットを多用する人はそっちの方が
作業が早いのでということです。

>他の人の意見も聞きたいところですが、もし本当に搭載するなら、
>オプションで任意で選べるようにして欲しいです。
そのつもりの提案です。

ここのところMetasequoiaには多くの要望、エラー報告が寄せられており、それに対応する開発者はO.Miznoさんただお一人です。
現状で操作上大きな問題が無ければ、この時期に細々とした要望を出すのはどうでしょうか？

>現状で操作上大きな問題が無ければ、この時期に細々とした要望を出すのはどうでしょうか？

要望はいつ出していただいても構いませんよ。
既にVer2.5の開発も始めてますし、いつ採用するかは私が決めることなので、
変な気遣いはしていただかなくてもいいです。