同じエラーのエラー情報のテキストファイルです。

update.txtに書いていますが、Ver3.0.2で
・材質の設定時に、MQOファイル以下のフォルダにある画像をマッピング指定した場合は相対パスで設定されるようにしました。
という仕様変更がされていますので、ご確認ください。

ファイル読み込みダイアログを表示したときに、既存のファイルがあるフォルダではなく
初期化（？）された位置になるのは不便なので、今後のバージョンで修正したいと思います。

ありがとうございます。

改めてupdate.txtを確認しましたが、当方で発生している現象とは違うもようです。
誠に申し訳ありませんが、もう一度ご確認の程宜しくお願い致します。



update.txt内容
[フォルダA]
　 |　└ xxxx.mqo
 　└[フォルダB]
　　　　└xxxx.bmp ←これを選ぶと相対パス



起きている現象
[c:]
 └[フォルダA]
　　　└[フォルダB]
　　　　　└[フォルダC]

「より下」ではなく「以下」なので、同じフォルダにある場合も当然含みますよ。

ありがとうございます。


こちらで色々試してみましたところ、何かしらのファイル読込操作を行ったときのディレクトリ状態に引っ張られているように思えました。
rootから追いかけていくとだいたい絶対パス指定で読まれますが、mqoファイルのあるディレクトリから追いかけると
ほぼ確実に相対パス指定で読まれるといった次第です。
（前回の読込操作が絶対パス指定の場合はその限りでは無いようですが）


これが今回の仕様変更によって生じたものと理解しましたが、相対パス指定ではファイルの行先がすぐにわからず管理がしにくくなるので
環境設定のところで旧来のファイル指定方法（絶対パス指定か相対パス指定か）を選べるように出来ないでしょうか。


何卒、宜しくお願い致します。

Beta3でUVが崩れないようにしました。

歪むのはアルゴリズム上仕方ない気がします。
他のソフトでは見た目上あまり変わらないようにする機能もあるようなので、
うまく再投影するような処理を付加すればできなくはないのでしょうけど。

確認しました。
曲面をフリーズするように指定しているとエラーはでないのですが出力できなくなっています。
次のベータで修正します。

Beta3で正常に出力されるよう修正しました。

書き忘れましたが、3.0.2にバージョンアップしてもダメでした。

プラグインの質問は、まずプラグイン作者の方にしましょう。
DirectX関連だと思います。
http://space.geocities.yahoo.co.jp/gb/sign_view?member=uvpowertools

>匿名様
他のプラグインも沢山試したのですが、どれも同じようにダメだったのでここに書き込ませて頂きました、DirectXは入っています。
言葉足らずで申し訳ありません。

pluginフォルダに直接dllを置けばインストールの処理は必要ないはず。
UVpowertoolはplugin\stationにdllを置いたのならば、メニューバーの選択部処理に追加されているのではありませんか?
二重にインストールしようとしてエラーがでているのでは?

>mqouser様
アドバイスありがとうございます。
プラグインフォルダに直接置いても、メニューバーに追加されませんでした。
その後、プラグインフォルダに直接置いたファイルを削除してから、「プラグインについて」からインストールしようとしましたが、失敗しました。
なので、二重になっている訳でもありません。

Ver3.1 Beta2でオープンエッジが丸くなるようにしました。
ただ、逆に従来通りにはできないので互換性はなくなっています。

>■回転ハンドルを移動する際(Ctrl+マウス左クリック時)、ハンドルがあらぬ方向に移動してしまいます。

これは[L]ボタンを押してローカル座標でリングをドラッグ（X/Y/Zいずれかの方向のみの移動）をしたときのことでしょうか？

>■オブジェクトを複数選択した状態で複製した場合の名称不具合

こちらはVer3.1 Beta2で修正しました。

>・CreateVertexUserDataの引数について

ユーザーデータは単なるバイナリデータの塊にすぎないので、
プラグイン間でやりとりすることはできないことはないという程度で
基本的には考慮していません。
もしやるならそのプラグインがユーザーデータのフォーマットを公開して、
変更も行わない前提が必要になりますし、
実際問題としてそこまで行われるのかどうか・・・
それに、いつ凍結するかわからないようなクローズドな外部リソースに依存するのもどうかと・・・
ただ、それが可能なくらいの柔軟性をSDKの仕様に持たせておくのは、
今後のことを考えても重要かもしれませんが。


>・保存について

これはユーザーデータを管理するプラグインが行うものなので、
バッティングが起こること自体がないと思いますが。
というか、なぜ他のプラグインで保存しようとするのかよくわかりません？？？
また、OnSaveDocument内からmqxに保存される際にはXML要素名にプラグインIDが付加されるので、
要素名が重複することはなく、XMLツリーはプラグインごとに別々になります。

回答ありがとうございます。
確かにプラグイン間でのユーザデータのプラグイン間共有はどこまで需要が
あるのかを考えると難しいところですね。個人的には同一目的のユーザデータを
扱うのにプラグイン間で依存関係が生まれてしまうのは避けたいかな、と思います。
その辺りは他の方の意見も聞けると良いのですが･･･。
 
保存については少し説明不足でした。プラグインとユーザデータの関係が対に
ならないのなら各々のプラグインが保存/読み込みを行うと問題があるのではないかと思った次第です。
現在の仕様なら問題はないと思います。
 
頂点の追加/挿入についてはプラグイン側でどこまでできるか実験コードを書いてみたのですが
ちょっと難しいかな、と感じました。特にモーフデータのように頂点データを扱うものは局面化の
フリーズにまで対応させようとするとプラグインレベルではお手上げですね。
解決方法として思い浮かぶのはDirect３DのVertexDeclaration(D3DVERTEXELEMENT9)やFVFのように
データの型、利用用途、補完方法等のバイナリフォーマットを初期化時に与えデータの補完は
メタセコイア側に一任するという方法ですがこれはMiznoさんの負担が大きそうで･･･
 
また、マルチUV、マルチ頂点カラーも扱おうと思ったのですがこれはFaceDataの方にもユーザデータを
持てるようにする必要がありますね･･･。実装するまでメタセコイアの仕様が頭から抜けていて
どうしたものかなぁと言った所です。

フィードバックは一人でも多くの方にいただけるといいのですが、
プラグイン開発者自体が多くないのと、あとお忙しい方もいらっしゃるでしょうから、
なかなか難しいところです。
ユーザーデータ周りは焦って中途半端な仕様にしたくないので、
実際にどなたかが最初のプラグインのリリース準備ができた段階で仕様fixにしたいですね。
そういう意味ではVer3.1でなくてもタイミングが合った時点でいいかなと思います。

VertexUserData便利に使わせて頂いてます。
ところでVertexUserDataと同じようにオブジェクトやマテリアルにもユーザーデータを付加させるAPIがあるとうれしいのですが、
どうでしょうか?

>頂点の追加/挿入についてはプラグイン側でどこまでできるか実験コードを書いてみたのですが
>ちょっと難しいかな、と感じました。特にモーフデータのように頂点データを扱うものは局面化の
>フリーズにまで対応させようとするとプラグインレベルではお手上げですね。
>解決方法として思い浮かぶのはDirect３DのVertexDeclaration(D3DVERTEXELEMENT9)やFVFのように
>データの型、利用用途、補完方法等のバイナリフォーマットを初期化時に与えデータの補完は
>メタセコイア側に一任するという方法ですがこれはMiznoさんの負担が大きそうで･･･

全然試せていない状況で推測で言ってしまい申し訳ないのですが…
フリーズやナイフにより追加された頂点への、ユーザーデータの補完割り当てを行いたいという認識で合ってるでしょうか。

メタセコ側に一任しない方法であれば、たとえばナイフの場合、既存の辺の途中に新しい点が追加されることになりますが、その際に、その辺を構成する二つの頂点と、追加された頂点のユニークIDのペア(オブジェクトIDと頂点ID、以降単にユニークIDとします)をプラグインに通知する仕組み(プラグイン定義のコールバック関数を呼び出す形になるのでしょうか)にして、プラグイン側で補完の処理を記述するしかないのかな、と思えます。
フリーズに関しても同様です。
（こちらはフリーズの際に、新規頂点作成に使われた頂点郡のユニークIDやら、フリーズ前の曲面生成方式やらが必要になるでしょうか。）

とりあえずナイフに関しては膨大な数の頂点が追加される状況は考えにくいのと、フリーズの場合は逆にそうなる可能性が高いですが、何度も実行するものでもないと思うので、パフォーマンスへの影響的に妥協できるかな、と考えております。

横から失礼します
 
　私も手始めにマルチ頂点カラーに対応したColladaエクスポータ/インポータを作ってみようと思ったのですがJamaさんが上げられた問題点で詰まっています。まだテスト実装という事でこれからに期待しています
 
　気になったのはインポート時に追加したVertexUserDataをセーブ→終了→ロードでユーザデータを保持しようとすると別に常駐プラグインを作る必要がある事でしょうか。今後他の開発者さんがインポータプラグインを作られるとユーザデータ管理常駐プラグインが乱立して混乱が起こりそうな気がします。MQImportPluginにOnSaveDocumentコールバックを追加して頂けるとシンプルになるかと思いました。
 
　私も何かアウトプットを出せるといいのですが携わるのは大半業務上で使うプラグインな為公開が難しいという事もあり申し訳ない限りです

私の認識が間違っていないとすれば、厄介なのは、頂点を追加するようなユーザー作成のプラグインでしょうか。
補完用情報をつけようがない（ユーザー情報を空のままにするしかない）処理かもしれないし、補完用情報をつけられるような処理かもしれない。補完用情報をつけられるような処理とは言っても、処理内容によって補完情報は大きく異なることも容易に想像できます。

この場合、AddVertex()の引数にユーザーデータへのポインタを設けるなどの統一的な規格が必要と考えられます。
頂点追加プラグインごとに通知の方法がバラバラであっては、ユーザーデータ操作用プラグインでの対応は困難でしょう。　

＃そういえばブーリアンなんかも頂点の追加があり得ますね。こちらは作者さんのご好意でバイナリを提供していただいているので、細かい対応は不可能ということをSDK BBSか不具合・要望BBSのどちらかで見た記憶があります。

>ところでVertexUserDataと同じようにオブジェクトやマテリアルにもユーザーデータを付加させるAPIがあるとうれしいのですが、
>どうでしょうか?

要望にはないですが面も併せて、Beta2で対応しました。

とりあえず現状で挙っている問題点は
・頂点の追加/分割
・インポート/エクスポート
ですね。さらに面も追加になると余計に問題点が増えそうですが。

いずれにせよ、ブーリアンのような既存の（修正ができない）プラグインについては対応のしようがないので、情報が欠落しないようユーザーが気をつけるしかないです。

オブジェクトとマテリアルのユーザーデータ付加APIの追加ありがとうございます。

頂点が追加された場合の処理ですが、とりあえず新しく追加された頂点であること検出できるとありがたいですね。
またはプラグイン側のユーザーデータの初期化ルーチンへ飛ばすような仕組みを作るなどあるかと思います。

あと別な話ですいませんが、
OnNewDocumentはファイルが読まれたあとに飛んでくるメッセージだと思うのですが、
OnNewDocumentのタイミングでプラグインのデータを初期化する作りにすると
インポートプラグインからSendUserMessageなどで他のプラグインにデータを送る場合、初期化されていない状態になってしまいます。
できれば読み込み処理前に飛んでくるOnPreNewDocumentみたいなメッセージがあると便利だと思うのですが、どうでしょうか?

面とマテリアル＆オブジェクトへのユーザデータ追加ありがとうございました。
素早い対応ありがとうございます。一気にできる事が広がりました。

>sio29さん
>頂点が追加された場合の処理ですが、とりあえず新しく追加された頂点であること検出できるとありがたいですね。

私は今の所ユーザデータに1byteのダーティチェック領域を余分に確保して０なら新規頂点として認識させています。
チェック済みは＋１すればとりあえずお手軽＆低コストで新規追加分をチェックできますよ。
無駄にメモリは食いますが^^

新規追加頂点が判ればプラグイン側でかなりのオペレーションに対応できますがやはり限界はあるので
もう少し根本的な仕組みが必要かな、と思います。

なるほど0クリアされているのですね。
アロケータ後なので不定値だと思ってました。ありがとうございます。

>OnNewDocumentのタイミングでプラグインのデータを初期化する作りにすると
>インポートプラグインからSendUserMessageなどで他のプラグインにデータを送る場合、初期化されていない状態になってしまいます。
>できれば読み込み処理前に飛んでくるOnPreNewDocumentみたいなメッセージがあると便利だと思うのですが、どうでしょうか?

インポートプラグインからSendUserMessage()でメッセージを送ったときに、常駐プラグイン側でまだOnNewDocument()が呼ばれていなければ初期化処理を行うようにすればいいように思います。
もちろん後でOnNewDocument()が呼ばれたときに二重に初期化しないようにして。

という感じでどうでしょうか？

>インポートプラグインからSendUserMessage()でメッセージを送ったときに、
>常駐プラグイン側でまだOnNewDocument()が呼ばれていなければ初期化処理を行うようにすればいいように思います。
その場合、どこで初期化フラグをクリアすればいいのでしょうか?
インポータプラグインで読み込む場合の流れは
インポータプラグインの読み込み(SendUserMessage)→OnEndDocument→OnNewDocumentとなり初期化フラグをクリアするタイミングがないのですが…