Metasequoia BBS

| New message | Normal | Tree |
Status
Tag
Keyword
[2302] 頂点への複数任意情報の実装のお願い / Jama
[From old BBS] Response
Ver3.0のリリースおつかれさまでした。
主にプラグイン開発者の為の要望なのですが多くの方の目に付いた方が良いと
思ったのでこちらに投稿させて頂きます。
 
次期バージョンで頂点への複数任意情報(マルチアトリビュート)の対応を
是非ご検討頂けないでしょうか?以前も同様の要望がありユニークIDという形で
実装して頂いたのですが実装面にも利用面でも難があり該当の機能を実現する
上で現実的でないのが現状です。
 現在最も要望があるのはボーンウエイトだと思うのですが、モーフターゲットや
マルチUVやマルチ頂点カラー、ゲーム用途の属性など応用用途は広いと思います。
 またメタセコイアと他の統合ソフトを併用されている方も多いと思いますが
他のソフトで付けた頂点情報をメタセコイアに持ち込んだときに失わずに済むように
なるとより活用の幅が広がるのではないでしょうか?

 過去に作られたプラグインやデータとの互換性の問題、軽快さを売りにする
メタセコイアのコンセプトと相反する等、問題点が多い事も理解はしているの
ですがこの機能については他にも切望されている方も多いと思いますし
まずはMizunoさんの考えを聞かせて頂けたらと思います。

お忙しいところとは思いますがよろしくおねがいします。
2012-05-12 23:51
[2308] Re: 頂点への複数任意情報の実装のお願い / O.Mizno
ボーンのサポートについては現在検討を進めています。

10年くらい昔のロードマップではVer2.5で搭載予定で、
その布石としてVer2.4でローカル座標をサポートしたのですが、
その後に内部構造の大幅改良を行う時間をとれる見込みがなくなり
Ver2.5自体をキャンセルせざるを得なくなった経緯があります。

今ようやく内部構造の大幅改良を行える算段が立つようになったので、
まずは検討のみという段階にすぎませんが、
速度面や将来の互換性への懸念があることには変わりがないので、
もし正式にサポートするのであれば中途半端な仕様の採用ではなく、
今後長らくは大丈夫な実装にする必要があると思っています。

ただ、ユニークIDでは難しいという理由はどういったものでしょうか?
現在だとオブジェクトの変更通知に対してその理由を知ることができなく、
頂点の追加・削除を検知するために総当たりが必要になるため面倒だというのは
わかりますが、決して困難ということはないと思います。
もし速度面が問題だとしても、実際にどの程度かは検証していませんが、
いまどきのCPUであれば頂点数が少なければ大したボトルネックでもないような気がします。

実装方法については色々検討したいので、こういった面について
ご意見お聞きせいただけると幸いです。
2012-05-14 10:42
[2310] Re: Re: 頂点への複数任意情報の実装のお願い / sss
現在の頂点のユニークIDはオブジェクト内でのみユニークなので
ユニークIDではコピー、ペーストやオブジェクトの合成などでは追いきれないと思います。
オブジェクトが変化するメッセージは、OnUpdateObjectList(オブジェクトの作成、削除)とOnObjectModifiedがあると思うのですが
10万ポリゴンのオーダーのモデルを編集時に頂点を移動しただけの時やオブジェクトの表示/非表示をしただけで
10万オーダーの全検索するのはあまり現実できではないと思います。
ユニークIDを使用するならばせめて何がどのように変化したか(オブジェクト1の頂点1が削除されたとか)のメッセージを送るべきだと思うのですが、どうでしょう?
2012-05-14 21:20
[2311] Re: Re: Re: 頂点への複数任意情報の実装のお願い / O.Mizno
頂点ごとの詳細な変更内容を通知しようとすると、その情報を保持すること自体が
重くなる要因になりやすいです。
実際にstd::setやstd::mapを使うと、10万程度ならいいのですが、
100万以上となるとかなり重いです。
検証こそしていませんが、下手に情報を保持するよりも総当たりのほうが軽くなる
ケースすら出てくるかもしれません。

また、追加・削除だけならともかく、例えば複製など変更内容の種類が増えると、
今度はプラグイン側の対応が大変になったり、
さらなる仕様拡張で種類を増やすことも容易ではなくなるので、
余程かなり慎重に仕様を検討しないとおそらく将来的に破たんします。

そういった意味では、OnObjectModifiedの仕様を現状より複雑にするくらいなら、
頂点ごとに保持するほうがシンプルで拡張性も持たせやすいとは思います。
2012-05-14 23:30
[2313] Re: Re: Re: Re: 頂点への複数任意情報の実装のお願い / sss
そうですねプラグイン側としても頂点ごとに保持してもらったほうが楽でいいですね。

ただ一応このままユニークIDを使うとして、変化したもののメッセージを送るかわりに、変換したもの(頂点や面)にダーティーフラグを立てる方法もあるかと思います。
ただこの方法も毎回ダーティーフラグをクリアしなくてはならないのと、
削除したものは全検索しなくてはならないという欠点があるので、
あまり良い方法ではないかもしれませんが…
2012-05-15 15:31
[2314] Re: Re: 頂点への複数任意情報の実装のお願い / Jama
回答有難うございます。

ボーン対応予定の話は吉報でした。
多くのユーザさんが喜ばれるのではないでしょうか。
 
ユニークIDの問題ですが概ねはSSSさんの言われるような点です。
ご指摘のようにOnObjectModified前後でジオメトリ情報を記憶しておき
総当りで比較する事で推測する事は出来なくはないですが目的の手段に対して
必要となるコーディングコストが重過ぎます。後は保守性の問題といいますか、
将来的に頂点形式が変わると対応できないというのもあります。
その対応に目的の機能のよりも実装工数がかかるのは日曜プログラマ的には
ちょっと厳しいなぁと。
 
ボーンを実装する上で少なからず頂点のデータサイズを任意サイズで拡張できる
様な設計になると思います。その辺をある程度プラグインイに開放して頂けると
私的には有難いです。
私もどういったものを求めているのかというのはまだ漠然としていますので
一度意見をまとめておきます。差し支えなければ検討段階でも良いので今後の
構想など聞かせて頂けたらと思います。
2012-05-15 20:11
[2316] Re: 頂点への複数任意情報の実装のお願い / メタセコユーザ
横槍で失礼します。
オフィシャルでボーンに対応して貰えるのなら使う方はそれで十分です。
マルチUV、マルチ頂点カラーもあれば嬉しいですが今の所無くても困っていません。
ボーン対応の副産物でできる物なら良いのですがそこに手間をかけるなら
先ずはボーンの機能をキッチリ作り込んで欲しいですね。

プログラムの事は詳しくないので見当違いでしたらすみません
2012-05-15 22:40