Mega_Primに関する考察

経緯[]

Mega Primについてはさまざまな憶測、特にシムへの負荷について未検証の内容が多々飛びかっています。最終的には Andrew Lindenさんなどに確認を取るのがよいと考えますが、その前に現在出ている情報をまとめて、その上で検証を行うのがよさそうです。このページは確認できる情報および未検証の内容をまとめることで、なにを検証するべきなのか？を明確にするためのページです。

確認された事項[]

公式ブログでの発言・コメントを時系列で記載します。

Office hour / 公式ブログ[]

2007/05/08[]Zero Lindenのオフィス･アワー[13:25] 512mよりも大きなオブジェクトが存在する場合、simはより大きな範囲を把握しなくてはいけなくなる。[13:27] 512m以上となると隣のsimより先との通信が必要になる。そして、そういう機構は実装していないし、したいと考えてもいない。

2007/10/04[]「Second Life Havok4 beta preview temporarily offline」Andrew Linden（Havok4の担当）がコメントにて発言。

• No.18 256m以下のものだけ有効にすることを示唆。
• No.22 Havok4でメガプリムを許可した際の不具合について言及。かなり詳しい解説。
• No.44 あなたのプリムが私の土地にはみだしてますよ問題対策へのアイディア。Havok4をリリースして安定した後にやるかも。
• No.46 Havok4の開発プロセスについて

No.22の翻訳を以下に記載します。Havok4でメガプリムを許可した場合、理論上いくつかの問題が考えられる。簡単に言うと以下の通り：もしメガプリムを使用した場合、いわゆるコリジョン評価によって Havok1と同じくらいシミュレータが遅くなるリスクを犯すことになる。（ただし、Havok1がよく陥るディープ・ソート - 延々と考え込んでしまう状態 - はないとして、つまりすべての対象プリムが立方体だと仮定した上で、二つの環境を比較した場合の話）。。。が、おそらく問題はないだろう。以下が詳細。Havok4は3層のコリジョン評価システムを持っている。接触しようとしているオブジェクト群は「シミュレーション・アイランド（SI）」というデータ構造で管理される。二つの SIが出会った場合、それらはひとつにマージされる。SI中のオブジェクトが飛び出した場合、SIは二つまたはそれ以上に分割される。SIに含まれる複数のオブジェクトは次に「広域」（broadphase - BP）チェックで評価される。BPでは各オブジェクトに対して軸方向サイズ判定（axis aligned bounding box - AABB)が実施される。BPの結果は接触の可能性アリなオブジェクトの組み合わせ として「より詳細」（narrowphase - NP）なコリジョン評価へまわされる。NPはいわゆるコストの高い計算なので、SIやBPという段階を経るのはコリジョン評価を高速に行うためのトリックである。

もしメガプリムを使用した場合、SIはぜんぶひとつになってしまうことが考えられる。そうすると、BPの段階ではリージョンに含まれている N個のオブジェクトについて N-1回の評価をそれぞれ実施しなくてはいけない。だがほとんどの評価結果は接触ナシとして NPには渡らないという結果になる。すなわちこのムダが「ラグ」になる。－ どれくらいかは評価していないのでわからない。あくまで理論上の話。

実際のところ Havok4では Havok1ほどは悪い結果にはならない。Havok4は Havok1に対してより精細な AABB判定をしているし、NPのコードは少し速さが改善されている。それにメガプリムを使うということはメモリ消費が少なくなる期待もあるので、それによって速度が改善される見込みもある。現時点での自分の見積もりでは、、、おそらくメガプリムは、小さいサイズのプリムを同等の大きさに敷き詰めたものと比較してラグは大差ないだろう。とは言え、まだテストしていないのでなんとも言えないわけだが。

2007/10/11[]Andrew Lindenのオフィス･アワー[8:31] Havok1で Static/Dynamic切り替えを使用していないのは切り替えコストが非常に高いから。Havok4ではそうでもない。[8:34] Staticとは「動かすことができないオブジェクトのこと」[8:34] keyframed(Dynamic)なオブジェクトは物理エンジン上で動かすことができるもの。一定またはスクリプト制御の加速度で動かしたり、他のものとコリジョンしたり押したりできるもののこと。

2007/10/12[]「The big prim problem」Michael Lindenがガバナンス・チームとして取り扱いについて言及

• 「物理シミュレータに影響を与える」の表現アリ。
• 「256m以上のプリムに対してグラフィック・エンジンが正常に動作しない」

コメントとフォーラムで意見を募集公式フォーラム

2007/10/16[]SLDev向け説明会ログAndrew Lindenによる解説[11:11] 256mより大きなプリムは該当の面が256mまで縮小される[11:17] Static vs Dynamicのアイディア[11:29] SIの概念説明[11:32] Dynamicなオブジェクトはコリジョン評価の対象となる。もし大きなオブジェクトは強制的にStaticという扱い（動かない）としてよければ、これらを物理エンジン上で別の分類として取り扱うことができる。そうすれば、SIにこれらを含まないで別のものとしてコリジョン評価をすればよいので最適化できるかもしれない。ただしこの場合、例えばスクリプトでstaticなオブジェクトをいきなり物理扱いに変えたりすると問題が起きるかもしれない。

2007/11/29[]「Second Life Havok4 beta preview refresh with new fixex」Sidewinder Linden（Havok4のミッション・マネージャ）によるポスト。

• 256m以上のメガプリムは自動的に256mに縮小される。DEV-6085: put megaprims back into Havok4 build (note that any megaprims larger than 256m square will be forced down to 256m per side)

Andrew Lindenもコメントで言及。

• No.8
• No.11 Andrewの個人的な見解としてプラン案を掲載。以後の進展などは彼の Office hourで取り扱う旨を話しています。

2008/02/05[]Andrew Lindenのオフィス・アワー[11:44] microprimについて。物理エンジンのコリジョン・トレランスは0.1mになっている。それ以下の寸法のオブジェクトは正しくコリジョンしない。[11:47] megaprimに関するプラン（アイディア）

1. その土地にかかっているオブジェクトを持ち主がリターンできる（または動かせる）ようにする。
2. 許可された範囲を超えてオブジェクトを拡大しようとした際に、ビルダーに対してなんらかのしるしを返すUIを実装する。
3. 土地の権限で「自動的に境界をより厳密に守らせる」というオプションを使えるようにする（デフォルトはオフ）。
4. ビルダーが好きなだけ大きなものを作れるようにする（または場合に応じて土地のサイズを上限とするような機能）。別名「メガプリムの解放」。

(1)～(3)は通常のプリムにも適用される。これができればメガプリムも普通のプリムと同じように考えられるようになるだろう。スカルプティはまた別。これはLLの公式プランではなくて、（Andrew Lindenの）個人のプラン。まずは Havok4をリリースすること。スカルプティのコリジョン処理をちゃんとできるようにしたいけど、ちらっとソースを見ただけでしばらく見たくない気分になった :)

2008/02/28[]「Havok early adopter and beta preview refresh with 6 fixex」Sidewinder Lindenによるポスト。megaprim関連で多数の修正がされている。

• No.5 Sidewinder Lindenによるコメント。megaprimについてサイズと取り扱いを再コメント。
• No.6 Kelly Lindenによるコメント。「megaprimをサポートしない」という意味は【新しいものを作ることを許可しない。いまそうであるようにmegaprimが動作しつづけるとは保障できない】ということ。

2008/03/25[]Andrew Lindenのオフィス・アワー[11:26] Havok4では256mより大きなプリムを縮小する、という話しについて[11:27] 予定を再検討することにした。[11:27] 84のプライベート・アイランドでそのようなメガプリムを使っているのを確認した。[11:28] 詳細までチェックしていないがそのほとんどはファントムで、雲や地平線を表現するのに使用されている。[11:30] Havok4でのメガプリムがパフォーマンスに与える影響は、まだ検証していない。→ Havok4導入とメガプリムの問題は別として、Havok4リリース後に改めて考えることにするとのこと。

2008/03/27[]Sidewinder LindenによるHavok4ベータ更新の公式ブログポストSidewinder Lindenによるコメント

2008/03/27[]Andrew Lindenのオフィス・アワー[17:14] 1024^3でも 256^3でも理論的にはたいした差はない。どれくらいのdynamicなオブジェクトが重なっているかが重要。[17:19] 256x256のメガプリムでレース場を作るのと、小さいプリムを敷き詰めるのとどちらがよい？[17:21] アイランドの生成状況による。[17:23] 一言で回答するなら「わかりません」

JIRA[]

VWR-3327 - メガプリム近辺のミニマップは動作がヘン[]Minimap oddity near megaprims

SVC-1516 - ミニマップ表示がおかしい。メガプリムがミニマップ上で20%ほど大きく表示される[]Mini-Map Rendering Error, Mega Prim appears 20% larger on Mini-Map

関連リンク[]

• Havok4担当の Andrew Lindenのユーザー・ページ

Office hourのログも精査が必要

一応の確定事項？[]

• Havok4では 256mより大きなサイズのメガプリムは該当の面が 256mまで自動的に縮小される。 → 保留になりました。

特に記載のない限り、コミュニティのコンテンツはCC BY-SAライセンスの下で利用可能です。