Metasequoia BBS

[3458] SDKにおけるStandardとEXの違い / sio29

[質問,SDK,4] 返信

質問があるのですが、プラグイン、SDKにおけるStandardとEXの違いというものはあるのでしょうか?
告知は見たのですがプラグインとSDKについて言及されてなかったのでお聞きしたい次第です。

2013-09-05 14:02

[3459] Re: SDKにおけるStandardとEXの違い / 管理者

>質問があるのですが、プラグイン、SDKにおけるStandardとEXの違いというものはあるのでしょうか?
>告知は見たのですがプラグインとSDKについて言及されてなかったのでお聞きしたい次第です。

提供するSDKとそのSDKで作成したプラグインについてはStandard/EXに違いはありませんので、
Standard版でもプラグイン開発・利用が可能です。

2013-09-05 14:17

[3460] Re: Re: SDKにおけるStandardとEXの違い / sio29

返信

返信ありがとうごさいます。了解しました

2013-09-05 15:41

[3477] Re: Re: SDKにおけるStandardとEXの違い / たけし

返信

>提供するSDKとそのSDKで作成したプラグインについてはStandard/EXに
>違いはありませんので、Standard版でもプラグイン開発・利用が可能です。

EX版だけの機能であるFBXエクスポーターをプラグインで作ってStandard版で配布してもいいのでしょうか？

僕の3DアニメーションツールTransMotionやVixar Motionを使ってもらえるように、プラグインは作らず、こちらで読み込んでからFBXに書き出してもらうようにしてもいいのですが。
http://vixar.jp/transmotion/
http://vixar.jp/motion/

2013-09-09 13:26

[3481] Re: Re: Re: SDKにおけるStandardとEXの違い / 管理者

返信

>EX版だけの機能であるFBXエクスポーターをプラグインで作ってStandard版で配布してもいいのでしょうか？

元々配布していたのならそれを止める権限はこちらにありませんが、
これから用意しようとするのでしたらそれはご遠慮いただきたく思います。
モデリング機能をほぼそのまますべて低価格なStandard版にも提供する代わりの差別化機能なので、
EX版の売り上げで利益が確保されなければ今後の開発原資を確保できず、
継続的な開発に重大な影響を及ぼしかねないということをご理解ください。

>僕の3DアニメーションツールTransMotionやVixar Motionを使ってもらえるように、プラグインは作らず、こちらで読み込んでからFBXに書き出してもらうようにしてもいいのですが。

たけしさんで作成されている機能にどのようなものを搭載していただいても
当方が口を差しはさめるものではありません。
個人的な意見ですが、モーション作成ソフトであるならFBX対応は必須といってもいいのではないでしょうか。

2013-09-10 14:59

途中の4件のメッセージを表示

[3495] Re: Re: Re: Re: SDKにおけるStandardとEXの違い / まじかる☆しげぽん

返信

横から失礼します。
>これから用意しようとするのでしたらそれはご遠慮いただきたく思います。
こちら製品版販売時にライセンス規約に書いた上に、SDKの方でEX版でのみ動作するフラグを用意された方がいいのではないでしょうか。

すでにそのような取り組みをされているかもしれませんが気になったので。

2013-09-10 21:08

[3479] プラグイン / ms3

[雑談] 返信

バージョンアップをいい機会にプラグイン制作の勉強を始めたいのですがどなたか
いい書籍等の参考情報おすすめ有りましたらお願いします

2013-09-10 12:15

[3446] MQWidgetBase::GetSystemWidgetIDについて / sio29

[質問,SDK] 返信

MQWidgetBase::GetSystemWidgetIDについて質問なのですが、この返り値は
MQ_GetWindowHandleと同じと考えてよいのでしょうか?
あとMQ_GetWindowHandleは廃止予定と書かれていますが、今後ダイアログは付属のウィジェットを使えということなのでしょうか?

2013-09-03 23:48

[3447] Re: MQWidgetBase::GetSystemWidgetIDについて / 管理者

返信

ウィジェットのIDはHWNDとはまったく別物です。

当面はMQ_GetWindowHandleを廃止するつもりはありませんし、
まだ描画イベントが提供されないなど整備が追い付いていない部分がありますので、
既にWindows APIベースで作成しているウィンドウをすぐさま新しいウィジェットを用いたものに置き換える必要はありませんが、
ウィジェットを使うことによってボタンやフレーム等の外観が統一できること、
また将来的な話になりますがWindows以外のプラットフォームで展開したときの移植のことも考えて
従来のWindows APIベースでウィンドウ等を作成することは非推奨としています。

2013-09-04 01:06

[3448] Re: Re: MQWidgetBase::GetSystemWidgetIDについて / sio29

返信

返信ありがとうごさいます。

>当面はMQ_GetWindowHandleを廃止するつもりはありませんし
とりあえず安心しました。
簡単なダイアログならば付属のウィジェットに対応するのは問題ないのですが
使用している自作ダイアログを全てをウィジェットに移植となるとそれなりの労力になるので
ネイティブなウィンドウハンドルを獲得する関数はできれば残しておいていただけるとありがたいです。

2013-09-04 01:50

[3449] Re: Re: Re: MQWidgetBase::GetSystemWidgetIDについて / 管理者

返信

>ネイティブなウィンドウハンドルを獲得する関数はできれば残しておいていただけるとありがたいです。

しばらく（少なくとも１、２年程度）は互換性維持のため関数を残しますが、
本体側が管理できないHWNDが存在することで思わぬ不具合を引き起こす可能性も考えられることから、
ドキュメントにあるように将来的には廃止の方向で考えていますので、
折をみてウィジェットへの移行をご検討いただければ幸いです。
また、ドキュメントを見て移行にあたって不足している機能があればご報告いただけばと思います。

2013-09-04 10:41

[3452] Re: Re: Re: Re: MQWidgetBase::GetSystemWidgetIDについて / sio29

返信

返信ありがとうございます。

>しばらく（少なくとも１、２年程度）は互換性維持のため関数を残しますが、
うーん、なかなか短いですね。

>また、ドキュメントを見て移行にあたって不足している機能があればご報告いただけばと思います。
とりあえず独自ダイアログを作る機能を考えた場合、以下の機能は欲しいかなと思います。
・独自のグラフィックが描画できるキャンバス機能
・ビットマップを管理するクラスとそれを表示する機能
・ビットマップをダイアログとして使えるアイコン機能
・独自なダイアログ同士の通信に使える汎用的なイベントリスナ、イベントディスパッチャ。
・既存のダイアログを拡張できる機能(たとえばMQListBoxのセルを独自のものに置き換えられるようにするなど)
・メニュー、ポップアップメニュー

まだドキュメントを流し読みした程度なので、すでに存在する機能などがあったらすいません。

2013-09-04 15:45

[3454] Re: Re: Re: Re: Re: MQWidgetBase::GetSystemWidgetIDについて / 管理者

返信

>返信ありがとうございます。
>
>>しばらく（少なくとも１、２年程度）は互換性維持のため関数を残しますが、
>うーん、なかなか短いですね。

短いでしょうか。
もっとも「少なくとも」で、実際にいつなくすという計画がまだ決まっているわけではなく、
それくらいを目途に移行いただければ、くらいにお考えいただけると。

>とりあえず独自ダイアログを作る機能を考えた場合、以下の機能は欲しいかなと思います。

描画周りはもともと実装が追い付いていないのと、あとメニューは単なる対応漏れですね。
ただスケジュール的に厳しいので、4.0.1や4.1のような後のバージョンアップで追加対応になる可能性もあります。

イベントリスな・ディスパッチャは内部でも固定化されたものしか仕組みがなく、
汎用となるとうまく対応できるかは検討してみないとよくわかりませんので、
自前で似たようなものを書いたほうがはやいかもしれません。

2013-09-04 17:04

[3455] Re: Re: Re: Re: Re: Re: MQWidgetBase::GetSystemWidgetIDについて / sio29

返信

>もっとも「少なくとも」で、実際にいつなくすという計画がまだ決まっているわけではなく、
>それくらいを目途に移行いただければ、くらいにお考えいただけると。
了解しました。

>描画周りはもともと実装が追い付いていないのと、あとメニューは単なる対応漏れですね。
>ただスケジュール的に厳しいので、4.0.1や4.1のような後のバージョンアップで追加対応になる可能性もあります。
とりあえず現状機能のない部分はWin32APIで作れということですね。
ところで過渡的な利用方法としてWin32APIとウィジェットとの混在は可能なのでしょうか?

>イベントリスな・ディスパッチャは内部でも固定化されたものしか仕組みがなく、
>汎用となるとうまく対応できるかは検討してみないとよくわかりませんので、
>自前で似たようなものを書いたほうがはやいかもしれません。
個人的にはイベントリスナはウィンドウシステム側で持っていたほうが後々拡張するときに問題がないと思うのですが
メタセコのウィンドウシステムがそうであるのならば仕方がありませんね…

2013-09-04 19:11

[3456] Re: Re: Re: Re: Re: Re: MQWidgetBase::GetSystemWidgetIDについて / 管理者

返信

>とりあえず現状機能のない部分はWin32APIで作れということですね。

はい、そうなります。
描画を含めた複雑な制御をおこなっているものはまだ移行できないので、
SDK側で必要なAPIの整備が行われるまで現状維持でお待ちください。

>ところで過渡的な利用方法としてWin32APIとウィジェットとの混在は可能なのでしょうか?

ウィジェットとHWNDは１対１ではなく一部のものしかHWNDを持たないこと、
またそもそもウィジェットに割り当てられたHWNDの取得関数は提供していないので、
混在は難しいと思います。
特殊な用途（自前でDirect3D描画するとか）で必要になることがあるかもしれませんが、
下手に提供すると今度はマルチプラットフォーム化の際の障害になりかねないので、今のところは提供しない方向で考えています。

>個人的にはイベントリスナはウィンドウシステム側で持っていたほうが後々拡張するときに問題がないと思うのですが
>メタセコのウィンドウシステムがそうであるのならば仕方がありませんね…

もちろんその通りです。
できないことはないとは思いますが、他のもっと重要度の高いものの実装が間に合っていない今の段階ではなんとも、、、というところです。

2013-09-04 20:01

途中の7件のメッセージを表示

[3457] Re: Re: Re: Re: Re: Re: Re: MQWidgetBase::GetSystemWidgetIDについて / sio29

返信

ありがとうごさいます。了解しました

2013-09-04 20:37

[3450] 不具合報告 / ss

対応済み [Ver4β] 返信

他の形式は検証してませんが外部ソフトからOBJファイルを読み込むとき左右反転されて読み込まれるようです　また　エクスポートするときももう一度左右反転されて吐き出すようです

2013-09-04 13:21

途中の1件のメッセージを表示

[3453] Re: Re: 不具合報告 / ss

返信

回答ありがとう御座います

2013-09-04 15:50

[3443] コマンドパネルについて質問兼要望 / シオビ

[Ver4β] 返信

コマンドパネルについて質問兼要望です。

・システムや編集のボタンをアイコン化することは出来ますでしょうか？
・ボタンを任意の順番で表示させることは出来ますでしょうか？

2013-09-03 17:13

途中の1件のメッセージを表示

[3445] Re: Re: コマンドパネルについて質問兼要望 / シオビ

返信

回答ありがとうございます。
Ver3のスタイルファイル内で使われていた機能名が、今回のLayoutでも使えることを早速確認できました。
とりあえずこれで何とかなりそうです。

2013-09-03 22:45

[3440] Ver4発売後のVer3の取り扱いに関して / mqdl

[質問] 返信

Ver4が今月9月末予定との事ですが、既存のVer3は
並行発売されるのでしょうか。

Ver3の販売注意でVer4に一本化の場合、Ver4のシリアルでVer3の
利用は可能でしょうか。

2013-09-02 15:24

途中の1件のメッセージを表示

[3442] Re: Re: Ver4発売後のVer3の取り扱いに関して / mqdl

返信

畏まりました。発表をお待ちします。

2013-09-02 16:32

[3412] 不具合報告4.0β　beta2 / らくと

対応済み [Ver4β,不具合報告] 返信

1個目のテクスチャと2個目のテクスチャに張った場合に起きましたがエラーが起こる前のファイルで別のテクスチャを張っても問題なかったですが同じテクスチャを張ったら起きましたので、どうもテクスチャのルートしだいでこのようなエラーが起きたようです。
問題の署名:
  問題イベント名:    APPCRASH
  アプリケーション名:    Metaseq.exe
  アプリケーションのバージョン:    4.0.0.4
  アプリケーションのタイムスタンプ:    5209d2f2
  障害モジュールの名前:    Metaseq.exe
  障害モジュールのバージョン:    4.0.0.4
  障害モジュールのタイムスタンプ:    5209d2f2
  例外コード:    c0000005
  例外オフセット:    0000000000314df5
  OS バージョン:    6.1.7601.2.1.0.256.48
  ロケール ID:    1041
  追加情報 1:    b694
  追加情報 2:    b6944810aefa65be3177291f43e4a4a2
  追加情報 3:    a78f
  追加情報 4:    a78fb9cd80be8fea7d7e267815841d93

2013-08-20 22:50

[3421] Re: 不具合報告4.0β　beta2 / 管理者

返信

ある程度試してみても再現しないのでいくつか質問ですが
・1個目のテクスチャと2個目のテクスチャというのは「模様」と「透明」で間違いないでしょうか？
・crashlog.***.txtはC:\Users\(username)\AppData\Roaming\tetraface\Metasequoia4に出力されていませんか？
・再現性はどの程度ありますか？同じような手順で割と高い頻度で起こるのか、この１回きりか
・表示モード(Direct3D 9/Direct3D 11/OpenGL)はどれでしょうか？

2013-08-21 11:57

[3438] Re: Re: 不具合報告4.0β　beta2 / binc

返信

横から失礼します。

テクスチャ関係のエラーだと思うのでこちらに投稿させていただきます。
レンダリング時にらくとさんと同じようなエラーメッセージが出たので
テクスチャを全て消してからレンダリングすると正常にレンダリングされました。
下記がクラッシュログです（一部抜粋）。

Metasequoia Ver4.0 Beta3 (64bit) is running.
Windows version : 6.1 (Windows 7 x64)
Direct3D11 Driver: NVIDIA GeForce GTX 660

Exception code: c0000005 (EXCEPTION_ACCESS_VIOLATION)
Access violation at address 000000013F82F103. Read of address 000000000852138E.
Module: E:\Program Files\tetraface\Metasequoia4\Metaseq.exe

0x000000013F82F103 Metaseq.exe: GetMapInterpolate + 323 bytes, d:\release\metaseq40_beta3\metaseq\raytracer.cpp(324) + 57 bytes
0x000000013F82F70F Metaseq.exe: MRayTracer::CalculateShading + 543 bytes, d:\release\metaseq40_beta3\metaseq\raytracer.cpp(370)
0x000000013F82ECF6 Metaseq.exe: MRayTracer::Process + 1462 bytes, d:\release\metaseq40_beta3\metaseq\raytracer.cpp(249) + 51 bytes
0x000000013F6C385A Metaseq.exe: FThread::ThreadCallback + 26 bytes, d:\release\metaseq40_beta3\metaseq\libthread.cpp(21)
0x000000005D8A1D9F MSVCR100.dll: endthreadex + 67 bytes
0x000000005D8A1E3B MSVCR100.dll: endthreadex + 223 bytes
0x00000000774A652D kernel32.dll: BaseThreadInitThunk + 13 bytes
0x00000000775DC541 ntdll.dll: RtlUserThreadStart + 33 bytes

2013-08-31 02:13

途中の2件のメッセージを表示

[3439] Re: Re: Re: 不具合報告4.0β　beta2 / 管理者

返信

[レンダリング]でマッピング画像があってUVが0～1の範囲がにあると落ちるようです。
次のリリースで修正します。

2013-09-01 22:54

[3433] configアイコンのバグ / シオビ

対応済み [Ver4β] 返信

ビューの設定画面内のアイコンが環境設定のテクスチャを切り替えても変更されません。
設定に関係なく常にIcon＞Blackのconfig.svgを参照しているようです。

2013-08-29 21:42

途中の1件のメッセージを表示

[3437] Re: configアイコンのバグ / 管理者

返信

エンコードの問題か画像が見えませんが、この問題自体は認識済みで製品リリースまでには対処予定です。

2013-08-30 12:17

[3435] Pythonスクリプトで異常終了 / たけし

対応済み [Ver4β] 返信

多分これで放物線が描けるはずですが、スクリプトエラーが出て、すぐに3Dビューを右ドラッグすると強制終了されます。

doc = MQSystem.getDocument()
obj = doc.object[0]

def graph(x,ratio,size):
v = []
x *= ratio
v.append(obj.addVertex(x*size,x*x*size,0))
v.append(obj.addVertex((x+ratio)*size,(x+ratio)*(x+ratio)*size,0))
obj.addFace(v)

for x in range(20):
graph(x,0.1,100)
graph(x,-0.1,100)

Metasequoia3ではrangeをxrangeにしないと動作しませんでした。
もしかすると僕のPythonのスクリプトが間違ってるのでしょうか？

2013-08-30 08:52

[3436] Re: Pythonスクリプトで異常終了 / 管理者

返信

落ちるほうはもちろんですが、スクリプトエラーになるのもどちらも不具合なようです。
4のBeta版ではこのスクリプトが正しく動作するよう修正しますが、
Ver3系では仰せのとおりxrangeにすれば大丈夫なようなのでそれでご対応いただければと思います。

2013-08-30 12:15

[3401] 選択パネルメニューに現在質指定追加 / くま

対応済み [要望] 返信

タイトルどおりですが、コマンド選択パネルに現材質指定も追加してほしいです。

2013-08-20 12:44

途中の3件のメッセージを表示

[3432] Re: Re: Re: Re: 選択パネルメニューに現在質指定追加 / くま

返信

マッピングに材質コマンド欲しいと思ってたのでうれしいです。
ありがとうございます。

2013-08-23 14:33