◒◒◒がちゃ屋◒◒◒

すっかり暖かくなってきまして、もう昼間だと暑いぐらいですねー＾＾
そんな訳で、１プリを狙ったメッシュの作り方をざっとまとめて
おこうかと思います。
とりあえずなんとか１に収めたい、、あたりの部分です。

【　仕上がり寸法の設計　】
２ｘ２ｘ２ｍぐらいの立方体はすでに厳しいと思います。
ある程度の大きさから換算値がどんどん上がってしまうため、
大物は基本無理。。というのが現実だと思います。


【　リンク数　】
サーバ負荷に起因し、最大２プリムまでの構造が考えられます。
３になるとサーバ負荷が０．５×３＝１．５となり、
換算値２以上が確定してしまいます。

２プリム構造の場合であってもサーバ負荷の制約があり、
スクリプト数が１以下でなければなりません。

スクリプト数１：　0.5*2 + 0.3 = 1.3
スクリプト数２：　0.5*2 + 0.3 + 0.2 = 1.5

各負荷は小数点第一位の四捨五入であり、ＤＬ、物理、サーバ、
いずれかの負荷が１．５に達した時点でアウトです。

ポリゴン１枚であっても、１万頂点のオブジェクトであっても、
一律０．５ってのはいささか詐欺臭い感じがしないでもないですが、
オブジェクトレコードの数で言えばまぁ同じなので、完全な詐欺とも
言い切れない感もありますので、神ことリンデン様の仰せに従う他
なさそうですｗ

もちろん各プリムの頂点数が多すぎるとかは論外ですので、
２個合わせて多すぎにならないように作らないといけません。


【　ＵＰ時の調整　】
多少の崩れは覚悟して、ＬＯＤ１、０にはできるだけ
頂点数を割り当てないようにします。

できるだけゼロに近いほうが良いですが、Generateで
０を指定してもあまり小さくならない場合は、代替オブジェクトを
作って、それをアップロード時に指定します。

代替オブジェクトはマテリアルの構造がオリジナルと同一でないと
ビューアがバグったりするため、元のオブジェクトをコピーして
各マテリアルから１ポリゴンずつ使うようにして作るのが間違いありません。

バウンドボックスがオリジナルと同じサイズになるようにスケーリング
されるため、法線を反転して裏向きにすると良いです。

物理負荷が１．５以上になる場合は、「最低」で自動生成すると
まずＯＫです。
たまにえらく大きい値が見える場合がありますが、実際にＵＰして
Ｒｅｚしてみると０．４とかで、なーんだｗ　ってのが多いです。
（つまり、アップロード画面はまだバグってます）


【　番外編　スカルプは重いのか？　】
スペック的な部分に注目して、色々な観点からメッシュと
スカルプを比較してみましょう。

・シミュレータによる頂点データの保持
　スカルプ：　なし
　メッシュ：　あり（形状定義用に展開されたメッシュを保持）
　保持するメモリ、デコードに使うＣＰＵ、どちらもメッシュのみに
　存在する負荷であり、比較的にはメッシュは重いと言えます。

・当たり判定
　スカルプ：　形状に関係なく球体固定
　メッシュ：　データに依存し、havokのメッシュコライダを使用
　ＣＰＵ的に、メッシュのほうが遥かに重いです。

・ＤＬサイズ
　スカルプ：　平均３ＫＢ程度
　メッシュ：　ものにもよりますが、圧縮状態で２００ＫＢなど
　メッシュは６０倍も大きいですね。

・テクスチャの転送量
　スカルプ：　１画像
　メッシュ：　最大８画像
　メッシュだと最大８倍の負荷を生み得ます。

・１プリあたりの頂点数
　スカルプ：　１０２４固定
　メッシュ：　軽く４０００以上
　メッシュのほうが数倍重いです。

恐ろしく明白ですが、どっちが重そうでしょうか？
誰が見てもメッシュのほうが重そうですよねｗ
そりゃそうです。
メッシュになって表現の質が格段に上がったのは事実ですので、
それなりに重くないとバランス的におかしいですよねｗ


では、これだけメッシュが重い要因が満載であるにも関わらず、
メッシュは軽くてスカルプは重いという現実はどこから来ている
のでしょうか？
64x64ピクセル程度のpng画像のダウンロードがサーバにとって
致命的な負荷でないのは明白であり、遅い現実があるならそれは
仕様や作り的なレベルに問題があると考えるのが自然です。
一切視界に入らないオブジェクトを必死でダウンロードしておいて
遅いとか、ほとんどジョークの域ですｗ

現代のＷＥＢ系技術では細かい大量のダウンロードを的確に捌く
手法はいくらも確立されており、スケーラビリティの確保に成功
している事例はたくさんあります。
それらをやらずして　スカルプ＝悪　メッシュ＝良　のようにアピールした
リンデンの狙いは何でしょう？
僕自身はズバリ、
　・プリム消費の安定化を図り、利益構造を確実なものとする
であろうと考えています。
まぁ普通の営利企業ですし問題ないですけどｗ


まぁそうは言いましてもデータ由来でスカルプが極端な負荷を生む
ケースもない訳ではなく、その顕著な例はサイズ詐称によるものです。
見た目は数ｍのオブジェクトであっても、実はバウンドボックスが
２５６ｍもあったり。。とかその類ですね。

これは古典的にＬＯＤが落ちるのを防ぐ手段であり、崩れ耐性を
上げることが目的でしたが、遠くからでも視界に入ったことに
なってしまう訳で、重さの観点では非常によろしくないです。
ＬＯＤの判定アルゴリズムが理想的なレベルまで煮詰められなかった
結果がこんな形で皺寄せとして現れています。
とは言っても、これはあくまで一部です。
あらゆるスカルプが６４ｍだったりはしませんし、ヒュージプリムに
貼り付けた構造物も割合で言えばごく僅かでしょう。

長くなったので終わりますｗ