環境を書き忘れました。

Metasequoia Ver2.4.8＞Ver2.5 β12へバージョンアップ
WindowsXP SP3

で確認しました。

同じくUV関連のバグです。

Shift+Ctrlの接続されているUVを選択で、同マテリアル内では接続されていないUVも選択されてしまいます。

現象の詳細とサンプルのmqoファイルをアップしますのでご確認お願いします。

追加で申し訳ございません。
ハンドル（三軸の矢印）をドラッグした際も、
絶対・相対どちらを選択していても相対の表示になってしまっております。
絶対座標を見ながらドラッグしたい時もあるのですが、
それらも出来ないような仕様なのでしょうが？

よろしければ一緒にお教え頂けますでしょうか？

>絶対座標にて数値入力による移動を行おうとすると、
>面では移動・表示ともに行われません。
>相対にての面移動ではきちんと動作しております。

>ハンドル（三軸の矢印）をドラッグした際も、
>絶対・相対どちらを選択していても相対の表示になってしまっております。


上記の件ですが、
面や面の集合（オブジェクト）のような、複数の頂点の集合に対して「唯一の絶対座標」を数学的に定義することはできません。

一般的には重心座標をその集合の代表点としますが、
Metasequoiaの場合は、複数の頂点のうち、内部インデックスがもっとも若い頂点の絶対座標が、
「移動」ダイアログボックスに表示されるようになっています。

ちなみに複数の頂点を選択しているときに、プレビュー画面でハンドルが表示される位置は、重心座標ではなく平均座標です。


カレントオブジェクトの各頂点の絶対座標を表示させる簡単なスクリプトを添付しますので、
試してみてください。

>変更するパラメータ選択の際、隣接したグループの”一括選択”ではなく、
>shift押しによる任意の”指定選択”にすることは難しいでしょうか？
これに関しては、ctrl+クリックで”指定選択”出来るようですよ。

>これに関しては、ctrl+クリックで”指定選択”出来るようですよ。

noelさん、ありがとうございます。
ご指摘のとおりctrlキーの使用で、ちゃんと選択出来ることを確認致しました。謝々

>レンダリングオプションとしての”シャドウ”機能の導入です。

Metasequoiaはモデリング ソフトなので、オフライン レンダリングは他のソフトと連携するのが前提なのではないでしょうか？
フリーウェアでもBlenderとか本格的なのが結構あります。
恐縮ですが、私としてはモデリング機能の充実のほうが重要なのでは、と思います。（すでに完成の域に到達している感もありますが）

syghさん、レス遅れてすみません。
少し曖昧だったので、影関連（リアルオフ含めた）の現状について確認してました。

>Metasequoiaはモデリング ソフトなので、オフライン レンダリングは他のソフトと連携するのが前提なのではないでしょうか？
>フリーウェアでもBlenderとか本格的なのが結構あります。

そうですね。半分はポジショントークなんですが、
（成果物として）ファイルの互換性が有るかどうかという事と
（製作過程での）データ連携の効率がいいかどうかという事は、
実際に作業していると少々話が違っているのは理解してもらえると思います。

そういった意味で、データをブラッシュアップしていく過程において、
モデリングソフト上での影情報が必要になることが、経験上ままあるため、
（長年の要望の１つであった複数光源の延長ラインとして）
影情報の生成オプションに関しても一考して頂ければ、と考えてる訳です。

（影表現に関してはプリレンダとリアルタイムの壁はかなり縮まってる感じですが、
詰めるとインハウスツールとかビデオカードの話に膨らむので割愛しときます）

>恐縮ですが、私としてはモデリング機能の充実のほうが重要なのでは、と思います。（すでに完成の域に到達している感もありますが）

gene様、レスありがとうございます。
確かに、モデリング ソフト上で手早くシャドウの確認ができると、レンダリング ソフト用にエクスポートして
シャドウを確認して修正する作業を繰り返すより、作業効率が高いですね。

ところで、gene様はどういった作風や目的（リアル系／アニメ系、ローポリ／ハイポリなど）のモデルを作成なさっているのでしょうか？

一概には言えませんが、リアル系だとシャドウはGIレンダリングで生成されるようなボンヤリとした低周波のシャドウが向いているかもしれません。
逆にアニメ系だとレイトレースやシャドウマップで生成されるようなハッキリとした高周波のシャドウが向いていることが多いと思います。

つまり、シャドウといってもいくつか種類があるので、そのうちどれをMetasequoiaに導入すればいいのか、あるいはすべてなのか、
が明確になっていると、作者のMizno様も対処しやすいのではないでしょうか。


ただ、アニメ系の場合、「理論的に」正しいとされるアルゴリズムでシェーディング・シャドウイングしても、それが鑑賞者にとって
「理想的な（好ましい）」陰影になるとは限らないので、リアルタイム／オフラインを問わず皆さん苦労してらっしゃるみたいです。
多くの場合、陰影用のダミーモデルを別に用意して、法線情報等をすり替えるとかいう工夫がなされているようです。

すでにご存知かもしれませんが参考までに：
[1] CGWORLD vol.107(2007年7月号)P.92～「Xbox 360用ソフト トラスティベル」
[2] CGWORLD vol.118(2008年6月号)P.28～「OVA 星の海のアムリ」
[3] CGWORLD vol.127(2009年3月号)P.60～「OVA 星の海のアムリ」
(Works Corporation)

[3]はデザイナーのMA@YAさんがモデリング時に気をつけてらっしゃることなどが紹介してあってすごく参考になります。

syghさんレスありがとうございます。
>どういった作風や目的（リアル系／アニメ系、ローポリ／ハイポリなど）のモデルを作成なさっているのでしょうか？
個人的にはデザインツールの一つとして使っています。
（通常、数千～数万ポリゴンレベルで作ることが多いですが、３Ｄ専門という訳ではないので、所謂”生データ”ではないです）

>シャドウといってもいくつか種類があるので、そのうちどれをMetasequoiaに導入すればいいのか、あるいはすべてなのか、
>が明確になっていると、作者のMizno様も対処しやすいのではないでしょうか。
そうですね、自分はプログラム関係は素人なのと、用途的にはニッチ派だと思われるので、
あくまでもそういった立場からの見解なのですが、
ＧＩ的なシミュレート系の影よりは、所謂”セルフシャドウ”のような記号的な影を素早く生成（確認＆再利用）できる機能の方が、
メタセコイア内でのニーズに限っていえば、上ではないかとは思います。
（本格的なシーンビルダーとして使う人はあまり居てないかなと…）

今回、色々調べた中では、レンダリングの要望と言いつつもどちらかというと、
（メジャー所ですが）トライゼットの西川さんの記事や、
http://monsho.hp.infoseek.co.jp/game.html
のような”リアルタイムシャドウ”の方が気になりました。
（まだ未読なんですが、挙げて頂いたＣＧＷの記事の方も探して読んでみます。）

ただ、この話はグラフィックカードの対応への問題がどの程度絡んでくるのか、今ひとつ判然としてないのと、
uolim（+Yafaray）のリージョンレンダのユーザビリティ＆パフォーマンスはかなり良いので、
同じ注力なら光源＆マテリアル等々含めた相互の連携強化に振り向けて貰った方が、
よりメタセコイア自体の生産性は上がるだろうなと思ってるので、上記のようなレスになった次第です。

gene様、詳しいレスをどうもありがとうございます。

僕はどちらかというとプログラマ寄りの人なので、プログラマとしての見解を申し上げますと、

セルフシャドウを含むリアルタイムシャドウを表現するには、おそらくプログラマブル シェーダを使用するしかないため、
グラフィックカード側がDirect3D 9やOpenGL 2.0以上に対応している必要があります。
（表現力や自由度を制限するならばDirect3D 8やOpenGL 1.5でも可能かもしれませんが）

また、現状のMetasequoiaのリアルタイム プレビューではDirect3D、OpenGLともにプログラマブル シェーダではなく
固定機能シェーダのみを使用しているため、かなりの改変が必要になってしまうと思います。

ですので、Metasequoiaの「ファイル==>レンダリング」機能でレイトレースやシャドウマップによるシャドウ表現を追加していただくか、
gene様がおっしゃるようにuolim等を使用して外部レンダラと連携するほうが、現実的かもしれません。


ちなみに、ちょっと調べてみたのですが、Autodesk 3ds Max 2008ならばプレビューでのシャドウ生成に対応しているみたいです。
ぱっと見たところ、シャドウに若干ジャギーが見えるのでオーソドックスなシャドウマップが使用されていると思います。

http://images.autodesk.com/apac_japan_main/files/whats_new_3dsmax2008_final.pdf

Autodesk 3ds Max の pdf を拝見させて頂いて、先端機能についての実状を認識できました。
ハイエンドクラスでも専用ビューを通すプロセスが必要だとは全く思ってませんでした。
（この感じだとトリクルダウンが起こるには、まだ意外と時間がかかりそうですね）

>現状のMetasequoiaのリアルタイム プレビューではDirect3D、OpenGLともにプログラマブル シェーダではなく
>固定機能シェーダのみを使用しているため、かなりの改変が必要になってしまうと思います。
そうなんですか…プログラマの方から見てかなりの改変が必要だということは、やはり相当大変なんでしょうね。
それにグラフィックカードの問題が合わさるとなるとMiznoさんの負担からいっても益々現実的じゃないですよねぇ。

syghさんのお話でこれまで漠然と想定してきたことにも目鼻が付けられそうです。
詳しいご説明と参考資料を教えていただきありがとうございます。

レイトレースシャドウの件に関しては、細かな疑問が出てきてぶっちゃけ少し迷ってます。笑
uolim(Yafaray)は、現状でも標準レンダと同じ感覚でスムージング設定や
複数メッシュライトのシャドウイング、何気にバンプまで使えるようになってるんですが、
ＧＩ系の性なのかどうもクリッピング用の画像を作るのが厳しい感じなので…さて自分的にはどの部分から解決していったもんかなと。

私はmqdlさんが仰るmqoで作品を作ることもあり、一つのシーンとしてライトの影響度（数値設定や複数のライト配置）も保存されると第三者に意図どおり見てもらえるので、私からも対応をお願いします。

>拡散色だけでなく反射色もカラー指定出来るように

本来、鏡面反射のハイライト色は光源の色が反映されるものだと私は認識しています。
また、Lightwaveの場合は現在のMetasequoia同様に一つのマテリアルに対して一つのカラー設定しかできないようになっています。
ですので、鏡面反射色はモデラ側ではなくレンダラ側で制御する項目だと思いますが、いかがでしょうか？

モデリング時の利便性向上のためのライトパラメータの保持に関しては私も賛成です。

>1)ライトの(ワールド座標上の)向きを固定出来るように
>3)ライトのカラー、光量の設定を可能に
>4)複数ライト対応

Ver2.5 Beta11で対応しました。
補足説明になりますが、オブジェクトのタイプを指定すると、
従来通りの視野に対する平行光源は適用されなくなるので、
光源オブジェクトを配置することにより1)と3)は実現可能です。

>2)ライトの向きをmqoファイルに保存出来るように。

これも光源オブジェクトで対応できることになるかと。
従来の光源はプレビュー用途にのみ用いて、外部レンダラーに渡すには
光源オブジェクトを用いるということになります。

まず実際にモデリングに使わせて頂いた上で、必要と考える点や
疑問点がありましたら後日別途申し上げたいと存じます。

ご対応、誠に有難う御座いました。

複数光源に関しましてしばらく使用させて頂きましたが
差し当たり3点お願いがあります。

1)カーソル(ハンドル)は個別の光源が反映されないように
　これまでもカーソルはグローバルなディレクショナルライトが
　反映されていましたが、個別作成した複数光源は反映されないように。
　つまりこれまでと同様の表示になりませんでしょうか。
　作成した光源の状態によってはカーソルが見にくい場合があり、
　モデリングがしにくくなる事があります。

2)光強度は1.0以上も設定出来るように。
　いずれにせよMetasequoiaでは表示上RGB(255\x2c255\x2c255)でクランプされると
　思いますが、昨今のレンダラは浮動小数点管理しており、光強度1.0以上の
　シーンを構築し、外部ソフトにデータを渡したい場合があります。

3)プラグインから光源データを取得出来るように。
　現在プラグイン側からデータを取得できない為、その都度MQOファイルから
　独自にデータを読み込んでいます。
　現在データの取得が出来ない理由は仕様が固まっていない理由もあるかと
　思いますが、暫定でもかまいませんのでプラグイン側からデータを
　取得出来るようにして頂けると、テストや仕様確認上、非常に助かります。

以上、宜しくお願い致します。

私も同様に不便を感じていましたので、不具合状況のＳＳを作りました。

移動などすると、ハイライト表示が更新されて正しくなるのですが、逆にその際も「すべてを非選択」を実行しても、ハイライト表示が消えません。

絶対パスでなく相対パスを指定するのはいかがでしょうか？

例えば、MQOファイル
「E:\Documents\modeldata\enemy1\enemy1.mqo」
に対して、PNGファイル
「E:\Documents\modeldata\enemy1\enemy1_texture1.png」
をテクスチャとして指定する場合、

「参照」ボタンを使ってファイル指定すると、絶対パス
「E:\Documents\modeldata\enemy1\enemy1_texture1.png」になりますが、
そうではなく
「enemy1_texture1.png」と相対パスを直接入力します。

モデルデータ毎のフォルダにMQOファイルとテクスチャファイルを入れておいて、
テクスチャファイルを相対パスで指定すれば、ファイルを別フォルダに移動しても
相対的な階層構造が維持されていればパスを再指定する必要が無くなりますので
管理しやすくなると思います。

ただLightWaveでは相対パスが使えないのでLWO <=> MQOで相互変換したときに
絶対パスになってしまうため、再配置するときにパスの再指定が必要になるのが不便といえば不便ですが。

添付画像どおりの平面状のオブジェクトですと、
テクスチャのマッピング形式として平面マッピングを指定することで
頂点の座標に応じたUVが自動的に割り当てられます。

ただ、平面や円筒、球体で表せない形状なら該当する機能はありません。
四角形が規則的に並んでいるだけなら計算上は可能ですが、
三角形もまじった不規則な形状になると、どこを基準として計算すべきか
一意に決められない困難な問題を含むためです。

ご教示頂いた通りに平面マッピングを適用したところテクスチャを歪まずに表示そせることに成功したのですがver2.4.9にて幾つか不具合らしきものをみつけました。添付のデータで再現できます。
1)レンダリング画像では正しくテクスチャが表示されるが、モデリング画面に平面マッピングが反映されない。(UVと同様?)
2)オブジェクトを移動、回転、拡大させるとマッピングがずれる。
1)の問題はver2.4.8で実行したところモデリング画面とレンダリング画面の表示が逆になりました(モデリング画面では正しく、レンダリング画面では歪む)

1)の問題は表示をソフトウェア以外に設定したところ改善されました。
お騒がせしました。