>MQScene::GetGlobalDirectionalLightNumにアクセスした瞬間にハングアップしているようです。
>3.1では動作しているコードですが、4βでは落ちるようです

ご指摘ありがとうございます。
32bit版固有の不具合のようですので次のβリリース修正します。

>MQScene::GetGlobalDirectionalLightNumにアクセスした瞬間にハングアップしているようです。
>3.1では動作しているコードですが、4βでは落ちるようです

β5で修正しました。

Ver3のダウンロード状況を見る限りzip版の需要は結構あると思いますが、
できれば通常はインストーラ版をお使いいただきたいです。
というのはインストーラでソフト本体だけでなく必要なランタイムも併せてインストールされるからで、
注意書きも見ずにzip版を使うとランタイムエラーで起動しないという人が多発することが考えられます。
そのため提供するかどうかはまだ検討中です。

設定ファイルMetaseq.setting.xmlはMetaseq.exeが書き込み可能なフォルダにあればその位置に、
Program Files下など書き込みができない場合にVista以降では
C:\Users\(ユーザー名)\AppData\Roaming\tetraface\Metasequoia4(_x64)
となります。

>「押出」は、選んだ面の法線方向を元に押出すものですが、4.0で「移動」に搭載された機能の様に任意の法線を選んで、それを元に押出せないでしょうか？

こちらは「指定した一方向にすべての面を押し出す」ということでお間違いないでしょうか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OBJの他いくつかの形式で左右が逆になることを確認しています。
β4で修正予定となっています。