◒◒◒がちゃ屋◒◒◒

  

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

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


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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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


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

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

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

また炊飯器ですか？ｗ
ﾊｲｰ♪

という訳で、またしても炊飯器を作りました＾＾
今回はレトロ感が漂いまくりの一品です。


環境に優しい１プリで、バリエーションは全１１色です。

本体をタッチすると、しゃもじが出たりフタが開いたりします。

炊飯スイッチをタッチするとご飯が炊けます♪
白米から玄米、赤飯に炊きこみに松茸ご飯まで、、ｗ


オーナーの長押しで設定ダイアログが出ます。
　・リサイズ：　１０～１０００％
　　　※メッシュですので、大きくリサイズすると換算値が１プリを
　　　　越えてしまう場合があります

　・汚れ具合：　３段階
　　　　CLEAN、AGED、DIRTYの３つから選択できます。
　　　　初期状態ではCLEANになっています。


懐かしいものを見てると、その頃の出来事がよぎります。
炊飯器、あなたはどんな想い出が浮かんだでしょうか？＾＾

がちゃ屋へ行ってみる
  

今風でナウい炊飯器を作りました♪ｗ
環境に優しい１プリで、バリエーションは全１１色です。


デジタル時計が付いています。

本体をタッチするとフタが開閉します。

炊飯ボタンをタッチするとご飯が炊けます♪
時々、炊き込みご飯ができたりします＾ｍ＾

保温設定ボタンを押すとＬＥＤが光ります。（それだけです＾＾；

予約ボタンを押すとＬＥＤが光ります。（それだけです＾＾；；；


オーナーの長押しで設定ダイアログが出ます。
　・リサイズ：　１０～１０００％
　　　※メッシュですので、大きくリサイズすると換算値が１プリを
　　　　越えてしまう場合があります

　・時差設定：　１５分（0.25時間）単位
　　　　初期状態では日本にあわせて9.0が設定されています。


炊きたてのご飯ってキモチまであったかくなりますよね♪

がちゃ屋へ行ってみる

  

カフェの超必需品！コーヒーミルを作りました♪
環境に優しい１プリで、バリエーションは全１２色です。


タッチすると、
　１．どこからともなく豆が投入されます
　２．引き出しが開いて挽いた粉が出てきます
　３．最初の状態に戻ります
のように状態が変化します＾＾


オーナーの長押しで設定ダイアログが出ます。
　・リサイズ：　１０～１０００％
　　　※メッシュですので、大きくリサイズすると換算値が１プリを
　　　　越えてしまう場合があります

　・金属パーツの色：　３色
　　　どのバリエーションも同じ３色です。


ぜひ挽きたての豆で、香り豊かな珈琲タイムをお楽しみください♪

がちゃ屋へ行ってみる


ロケ地はコチラ♪おうち屋++HY's++
  

なんともありがちなフォトハンガーを作ってしまいました♪
ただ作るのも面白くないので、１プリで貼り付けられる写真の
枚数の限界にチャレンジしてみました＾＾


環境に優しい１プリで、なんと！１５枚の写真を貼ることが
できます。
もちろん、画像を並べた加工テクスじゃないと貼れないとか
実はプリムセイバーでした♪などのインチキはナシですｗ


バリエーションは洗濯バサミの色で全１２色です。

オーナーの長押しで設定ダイアログが出ます。
　・リサイズ：　１０～１０００％
　　　※メッシュですので、大きくリサイズすると換算値が１プリを
　　　　越えてしまう場合があります

　・紐の色：　４色
　　　どのバリエーションも同じ４色です。

　・リセット
　　　貼り付けたすべての写真をリセットします。
　　　（初期状態に戻ります）


写真の貼り付けは、編集で面を選択してから行ってください。


大切な想い出のＳＳからあーんな写真まで、
お好みで貼りまくってください♪

がちゃ屋へ行ってみる


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

軽く技術ネタなど。

１５の根拠は７＋８です。
１つめのプリムの１面のみで外装を作成し、残り７面を
写真用に割り当てています。
２つめのプリムは８面全てが写真用に割り当ててあります。
これをリンクした場合、ＤＬ負荷およびサーバ負荷が１．５未満で
あれば換算値は１となります。

プリムが３個の場合はサーバ負荷が０．５＊３＝１．５となり、
換算値は必ず２以上となってしまいます。
つまり概算では、リンクするプリム数が偶数の場合に限り
お得になる可能性があります。
（スクリプトの数によってもサーバ負荷が追加されるため、
　実際にはもうちょっと複雑です）

スクリ数とサーバ負荷の関係ですが、微妙にバグってるようなので
注意が必要です。
スクリの追加直後にはサーバ負荷が１．３だったにも関わらず、
そのオブジェクトをテイクしてＲｅｚし直した後ではサーバ負荷が
１．５になっているケースがありました。