>「押出」は、選んだ面の法線方向を元に押出すものですが、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で修正予定となっています。

標準機能としては用意していませんが、ボタンなどのGUIは設定ファイルで定義され、
仕組みとしては既に用意されていますので、現状でもLayoutフォルダ内の設定ファイルを直接書き換え、またはファイル追加することで
少なくとも前者は問題なく可能、後者については検証していないのでわかりませんができるかもしれません。

初版でいきなりすべてを万全な状態で用意することは難しかったので、
標準機能としてのカスタマイズについては4.1の課題として考えております。

販売に関して掲示板で個別にお答えすることはできません。
Webサイトでの正式発表を行うまでお待ちください。

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

横から失礼します。

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

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