まぁ適当に箇条書き+軽い解説
(細かいディテールは端折ったり言い換えたりしてるので
ガチで知りたい人は実際にテストして確認してくだされ)
SLの要求スペック下限が地味に低い理由は
モデルデータ(meshを除く)のデータトラフィックが少ないのと
物理エンジン周りの演算を全部サーバーがやってるお陰ですが
車のホイールとかをサスペンション効かせつつちゃんと接地させるとか
ちゃんと銃口から弾を出すとかって話だと逆にこれがネックになります
普通のネトゲってその辺の物理演算をクライアントにある程度やらせて
サーバートラフィックと処理量を減らしてるのよね
けどSLの場合そこをリアルタイムでサーバーでやらすので
負荷対策かクライアントでの描画情報は一切サーバーに行きません
(チャット キー入力 カメラの位置と回転 のみです)
なので複数アニメ再生してる状態での装着オブジェクトのSIM上の座標や回転は
当然のことながら取得出来ません
llGetAnimationとかはありますが
あれもサーバーからクライアントに送信している
”アニメーションデータのUUID”のみを観測する仕様です
なのでアニメーション自体の回転情報とかはSIMでは見ていません
なのでSIMでの物理演算が ”あの重さ”で済んでいるとも言う
んでまぁ
ここ最近スクリプトと物理を軽くすれば
たとえ50人以上集まってもSIM負荷は上昇しない
って定説が覆りつつあるというか
そこ軽くしても相変わらず重いSIMは瞬発的に重い時が出るってのが出て来まして
その次に注目されたのがアバターのトラフィック負荷なわけです
ちょー簡単に説明するなら
アバターがTPしてくると
SIMにいる人数*2のトラフィックが発生します
(TPしてきたアバターをSIMに居るアバター全員が読み込みリクエスト
+TPしてきたアバターがSIMに居るアバター全員読み込むリクエスト)
これもまぁ情報自体は4年前くらいに出てたんですが
ぶっちゃけ定量的に数値で計測する仕組み(アバターレンダリングコスト等)が
"数値"で指定しようとするとギリギリ設定にする人間が多くなり
ビュワーサイドでロード中も表示されるために途中でロードこけたり
ビューワバージョン違うと数値が変わったりで全く当てにならず
挙句の果てにオカルトチューン呼ばわりされる始末
とまぁそんな感じで
SLのSIMシステムは単純に
ネトゲのサーバーやwebサーバーと比較できるようなシロモノではなく
内部がやたら複雑怪奇なわけです
以上
0 件のコメント:
コメントを投稿