ウィジェットの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

画像がアップされてなかったので再投稿。

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

面に割り当てられている材質をカレントにしたいということでしたら[材質]コマンドのShift+クリックでできますよ。

選択パネルに現材質指定があると、マッピングのままで次々編集でき作業効率があがるのではないでしょうか？

そういうことでしたか。
同じ機能を複数のコマンド内で重複するのは望ましくないので、
材質コマンドをマッピングモードにも追加する形で対応したいと思います。

エクスポート時に三角形分割、選択部処理の面を三角形化等後で一括で三角形化する処理は、最終処理のようなものなのでそちらで対応したらいいじゃんというのは無しの方向で考えていただければと…。

1番目の要望は、要は１つの面の中で頂点から頂点を結んで分割する機能と分割してる途中で辺を跨いだらそこで面が分割される機能は別にした方がいいのでは？ということです。

Ver4β2で、1点目の「エッジを分割して面を二つにします」に「連続で追加」が追加されてるので試してみたのですが、やはり一つの機能に色々まとめすぎていると感じました。

添付画像で説明しているように、一つの面の中で頂点から頂点を結んで面を分割する従来とほぼ同一の機能と
頂点から辺の途中を結んで分断したり、連続で頂点を描いて分割するような動作はナイフっぽい挙動だと思うのでナイフコマンドに機能を追加してほしいです。


その他コマンドに、三角分割する機能は引き続き対応検討よろしくお願いします。

>添付画像で説明しているように、一つの面の中で頂点から頂点を結んで面を分割する従来とほぼ同一の機能と

辺を結ばず頂点間を結びたい場合、編集オプションの[辺]を外せば頂点にのみスナップするのでこれでご了解いただければと。

ワイヤーコマンドの中でもかなりの使用率だったので、ちょっと違う操作をしてワイヤーに戻った際に毎回辺ボタンをオフにするのはかなり操作性が悪くなってしまいます。
ワイヤーはWボタン連打で、機能を切り替えてすぐに機能が使えるのが良かったので、ひとつの機能に色々の処理をできるようにしてしまうと毎回そのような辺のオンオフや、その他オプションのオンオフすることになります。
新しい機能も、それによって操作性が犠牲になっては元も子もないので寄り使いやすい形での実装お願いします。

再度、ご検討お願い致します。

編集オプションの切り替えが面倒なら、Shiftキーを押せば辺の真ん中か頂点のどちらかにしかスナップしないので、
これで誤操作はかなり防げるのではないでしょうか？
特定用途向けではエッジ追加を多用したとしても決して汎用的な使い方ではないはずなので、
むやみにオプションを追加するのは望ましくないと考えています。
（もちろん要望の件数が多ければ話は変わりますが）