BLOG

ごめん10000プリム越えてた!

Posted: 2009/04/09 18:38  by Reiji Mills
Leave a response

ah0314200931.JPG

先日つくったススキ野、
フレキシでやたらと動く&プリムが大量すぎてやはりグラボが弱い人にはまずいようだ。
グラボが弱いフレを呼んでみたら、30メートルぐらい近づいた時点で動けなくなり
そのまま落ちた。
別のもう一人も落ちた・・・

このままでは「近づくと落ちる魔の場所」になるので撤去。
撤去してみたら10000プリムを超えていました。

 

The Return of 島の子供

Posted: 2009/04/09 7:45  by Reiji Mills
Response: 1

島の子供,
約半年ぶりに発見。
ah0314200935.JPG
段々人になっていきます。
ah0314200932.JPG
ah0314200933.JPG
だいぶ人に。
ah0314200934.JPG
あ、もどっちゃった
ah0314200935.JPG

http://avatarhangout.com/

ah0314200936.JPG

 

ススキ野とリソースとクライアント環境

Posted: 2009/04/07 8:35  by Reiji Mills
Leave a response

ah0314200931.JPG
昨日、クライアントサイドの問題で重いかな、と思ったススキ野、
PCを再起動してログインしてみたら全然重くありませんでした。
あーそういえばあの時はPainterを後ろで起動していたのでそのためか、と。
わたしとしたことがとんだ勘違いでした。
でもPC弱い人には重いかもね、誰か連れてきてテストしてみよう。

クライアントサイドの問題というのは要するに自分の回線、
PCのメモリ容量、グラフィックボードにそのときかかっている負荷の総量、
HDのアクセス状況など・・・要するに自分のPC内でのリソースにかなり影響されるので
この辺で勘違いしやすい。
単純に古くからネットをやっている人なら、
特定のウェブサイトにアクセスしたときにサイト内の画像が、
以前アクセスしたときはなかなか表示されなかったが
今日アクセスしてみたらすぐ表示された、なんて状況を
思い出したらいいだろう。

昔は、例えば23時以降は重くなるとか、よくありましたよね。
ブロードバンドの時代でもそれはあるし、
特にバーチャルワールドはかなりデータ量が多いから、
回線や他のソフトの使用状況などによってかなり左右される部分があるのです。

 

ススキ野

Posted: 2009/04/06 21:48  by Reiji Mills
Leave a response

ah0314200929.JPG
ah0314200930.JPG

Avatar HangoutはOpenSIMソフトウェアがまだβのため、
スクリプトには制限がありますが、逆にこんなことができます。

ススキ野原を作ってみました。
これで約8000プリム。
風でゆっくりたなびいてすごくいい感じ。
こういう事はまずSLではできない^^

が!しかし!

レンダリングコストがかかりすぎて重い!
サーバの方は何ら問題がないのですが、あまりにふさふさ動く設定にしたため
PCのグラフックボートへの負担が大きい(動くものは「自分の」PCのグラフィックボードに
負担がかかる)のです。
撮影しようと思ったらカメラが遠・近の二段階しか動かない!
もうすこしフレキシの設定をおとなしくすればマシになるかな?

ちなみに上記の理由から、PCのスペックが低い人は
動くものやパーティクルが大の苦手です。
しかしながら自分のPCはSLではULTRAで描画距離512メートルで
さくさく動くスペックです。
これでこうなわけだから・・・

これらの理由により、OpenSIMソフトウェアでは最大45000プリムまで
置ける、と謳っていますがAvatar Hangoutのうち、
つまりRMH DESIGN Estatesは25000に留めています。
動かないものでも45000だとアバター側への負担が多すぎて
実は問題が多いのです。

それにしても、このススキはテストのために作っただけにしては
結構よく出来たなあ、と自画自賛^^

 

OpenSIMのスクリプト2

Posted: 2009/04/06 11:45  by Reiji Mills
Leave a response

ah0314200928.JPG

先日、OpenSIMでは「ほとんどのSLからのスクリプトは書き換えれば動く」
と書いたが、動くからなんでもOKというわけではない。
むしろかなり慎重に、できれば生活必需品関係以外
一切スクリプトを使わないぐらいにしておかないといろいろと危険だ。
例えばドア一つにしても、かなり書き方を考えないと、
ものによってはスクリプトをコンパイルした途端SIMが落ちる場合もある。
また、そうでなくても、ものによってはサーバのメモリ使用量がどんどん増えていって
そのためにすぐ、若しくは数日でサーバが落ちる場合もある。

SLよりもリソースの使用量がかなり重要になっていて、
Region/EstateメニューのGet Top Scriptなどはほとんど参考にならない。
リソースの使用量というのはサーバ管理者しかわからない。
だから、例えば自分の場合、サーバを管理するようになる以前は
サーバ管理者が暇なときに頼んで、
なにもないSIMにスクリプトアイテムを一個だけ置いて、
数時間若しくは数日様子をみて問題がないものだけ使うようにしていた。
今はサーバの管理もやっているので、自分で全部チェックできるけどね^^
ドアに関しても数パターンの全く違う書き方のスクリプトを用意して、
いちいち個別に数日単位でチェックして最適なものを見つけた。

またスクリプトに限らず基本的に
「駄目って書いていないことはなんでもやっていいんでしょう!」という
ノリの人は大変な苦痛を強いられるか、OpenSIMグリッドには向かない。

まだOpenSIMはβなんだから、駄目なものは駄目、
バージョンアップによる変更にも随時対応できる柔軟な頭の人じゃないと
つとまらないと思う。

 

休日

Posted: 2009/04/06 0:28  by Reiji Mills
Leave a response

ah0314200927.JPG
今日はものすごーく長時間寝て、さっき起きてPCの前に座ったら
なんか南アメリカに行く途中でニューヨークの空港で
飛行機の乗り継ぎを間違えて?2日間空港内にいないとならないが
なにもやる事がない&金がない&暇すぎる、i dont really know im okな人から
スカイプでメッセージが。

何しとるんだこの人

でもあるんだよねえ・・・
数年前アメリカ国内で移動するときに
出発先の空港が雷雨のため、予約していたノースウェストは運休で
ユナイテッドの便に搭乗、シカゴでその便からノースウェストに乗り換える
という形に変更されたのだが、
その便と次のノースウェストの便のゲートが空港内の
端と端で、しかも到着したら乗り継ぎ便の出発まで10分程度しかない。
手荷物を持ったまま二キロほど
走って縦断、それでギリギリ間に合ったのだが
こういう変更はアメリカのローカル便ではよくあること。
乗り逃すと最低数時間、場合によっては一日待つ事になる。

ちなみにアメリカの地方都市に行く場合って
こういう変更がなくても、海外からはハブ空港から
各地方のローカル便に乗り継ぎで、乗り継ぎの間
6時間ほど時間を潰さねばならない、なんて当たり前にある。

さて今日は寝続けていたので
回復モードの体にPCのディスプレイは辛い。
スカイプでは

hello
am i still alive

なんて言ってる人がいるが風呂にでも入ろう。
ちなみに今朝のエステートミーティングでは
マルチグリッド化がアナウンスされた、てかもうなってる。
マルチグリッドなんて「構想」する前に
切れる奴が一人か二人いればどんどん進んでいくものだ。
現在はウェブサイトをそれに合わせて変更中。

 

セカンドインベントリはヤバイ

Posted: 2009/04/03 23:19  by Reiji Mills
Leave a response

ah0314200926.JPG

自分がクリエータか、フルパーミッションのアイテムなら
PCに保存し、別グリッドに持ち運べるセカンドインベントリ。
一見便利なソフトだが、サーバに与える負担は大きい。

なにしろオブジェクトの全ての情報、テクスチャ、スクリプト、サウンドなどを
全て一気にアップロードするというアバター技(?)ではありえない
大量のデータを一気にサーバにながしこむわけだから、
データベースサーバへのアクセスが一気に増え、場合によってはサーバが落ちる。
OpenSIMが出来て以来、トラブルの原因は大体がセカンドインベントリによる
大量アップロードかスクリプトのどちらか。
このため、OpenLifeに至ってはこれを阻止すべくセカンドインベントリの使用自体を禁止しているぐらいだ。

別にこれはOpenSIMグリッドに限った事だけではなくて、
セカンドライフでも、例えば一つのSIMで、
同時に10人ぐらいでセカンドインベントリで大量のオブジェクトをアップロードしたら
SIM落ちかアセット障害が発生する。

Avatar Hangoutでは将来的な制限を検討しつつ、
現状ではユーザーの判断にゆだねるが、
慎重な使用と、1アイテムをアップしたら
インベントリにそのアイテムがリストアされるまで
暫く待ち、なにか疑問があればスタッフに問い合わせを、
という形にしている。
その理由から土地のObjectRezは土地オーナーのみにしておいたほうがよいわけだ。
まーどちらにしても、セカンドインベントリの使用は運営のサンドボックスで行うのを
推奨します。

 

リソース?

Posted: 2009/04/03 8:05  by Reiji Mills
Leave a response

ah0314200925.JPG

Avatar Hangoutでは、メインランドとEstate管理のSIM群がある。
メインランドは運営直売りだが、できることにかなり制限がある。
地形編集不可だかプラスマイナス10メートルまでのどっちか、
SIM丸ごとといっても道路は含まないので
面積は4万sqmちょっと、支払いはG$のみ、
名前変更不可能、元から建物などがある場所の場合はその変更は不可能、
などなど。SLで言うとモールやマンションを借りる形に近い。
で、スクリプトも機能制限あるか不可かどっちかだったかな?
そして再販、レンタルは不可。

で、Estate。
Estateは自由にSIM・土地を販売できるが、
そのためにはまず500USDで権利を買い、その上で
最低210USD程度のサーバを借りなければならない。
サーバを借りればサーバの容量が許す限りSIMを増やすことができる、
但し、一番安価なサーバだと、SIMに物を置いて人が来た場合、
SIM1~2個程度、それもスクリプトは皆無に近くしないとまともに動かないだろう、
これについては後日。

でEstateオーナーになると、毎週、日本時間の日曜日の朝6時ごろの
スカイプによるEstateオーナー会議の出席がほぼ義務化される。
OpenSIMのソフトウェアはまだβなので、
ここで、発見されたバグ、不都合な部分などを話し合い
今後のAvatar Hangoutの方向性やルールを決めるのだ。
この会議は基本は文字チャットだがボイスチャットになる場合もある、
当然全部英語。
会議は、その場で異議を唱えないものは合意したとみなす、
という欧米ノリ。この理由から、
スクリプト、リソース、土地設定、サーバなど全般にわたるかなり高度なレベルの
知識とノウハウがあり、尚且つ
英語でのかなりのディベート能力がある人じゃないとEstateオーナーは務まらない。
SLではSIMを持ったらEstateオーナーだが、その意味が根本的に違うわけだ。
逆にAvatar HangoutではSIMオーナーは単なる住民にすぎない、
土地価格を安く提供できるからSIM単位で貸すのがほとんどなだけで、
住民はEstateオーナーの作るルールに従わなければならないわけだから。
この方法は、
住人を指導・サポートするのはEstateオーナーになるので運営の負担が減る。
逆にEstateオーナーというのが、いうなれば小リンデンみたいなものになるわけだ。
しかし、Estateオーナーにかなり高度な知識が要求されるため、
それで実際にやっていけているのはほんの数人に過ぎない。
過去にも、知識は皆無だが野心だけはあるタイプの人が
Estate権限を買ったりしているが、到底手に負えないので
ほとんどが手放している。多分現状では、
エンジニアの経験があるか、じゃなくても多少はプログラミングの経験がある、
もしくはPCとインターネット、Webなど全般に精通していないと無理じゃないかな。

まずOpenSIMは、スクリプトに関してはSLとは決定的に違う。
ほとんどのスクリプトはそれに合った形に書き直す必要があるし、
よしんばそうしたとしても、依然としてスクリプトには弱いので
ラグを最低限に留める必要がある。
どの程度かというと、SLでの海外でのultra low lag !なんて
謳っているSIM以上のレベルじゃないかなー。
海外の厳しいところは、
生活必需品以外のパーティクル一切不可(つまり滝・暖炉など以外の全て)
HUD不可・レーダー不可・生活必需品以外のスクリプト不可・
ネットワークベンダー不可、ついでに建物は事前審査制、なんてところも
少なくないが、OpenSIMで「落ちないラグない」には
このレベルを当たり前のように維持する必要がある、現状では。
これが「スクリプトはやめたほうがいいね、わかった」で終わる
物分りのいい人はなんの問題もなく過ごせているが、
SLで環境SIMから流れてきた系の人は頭打たれまくってるね。
そもそもSLでの環境SIMに関しては、リンデンは最初から「住むな」
と言っていたわけで、それをスルーして住み始めて
好き勝手する連中がでてきたから仕方なしにリンデンも値上げせざるを得なかった、
というのが実情だろう。

これはサーバの仕組みにも関係してくる。
まずサーバでSIMを動かすには現状では二種類ある。
VPSとDedicated。

VPSはヴァーチャルサーバで、一つのサーバ上で更に「ヴァーチャルサーバ」を
作ってその上で複数のSIMを動かす。但しそのシステム上パフォーマンスはプア。
ラグが発生しやすいし、
他のどこかのSIMで大量のリソースを使っていると
他のSIMが引っ張られる、また、インワールドスクリプトに於いては
unexpected なエラー・・・予期できないエラー?が発生しやすい。

Dedicatedは専用サーバ。

SLの場合、価格改訂以前のOpenSpaceはVPSで1サーバに12個・・・
と公表しているが、実際のインワールドの感触だとこれは
「1VPSサーバに12個」じゃなかろうか?どっちにしろその理由から
パフォーマンスはプアなので・・・リンデンは「人住むな」
と言っていたわけだがそれを守っていた人の方が少なかったため
値上げに踏み切られてしまったのはご存知の通り。
Homestead以降はしらないが、多分それも、6~8個に下がった程度だろう。

対して通常SIMはDedicated一個につき「平均」四個。
何故平均かというと、通常SIMに関しては月295USDという「充分な」
賃貸料をもらっているため、サーバ一個に4SIMでもやばいぐらい
リソースを使っている場合、リンデンは文句を言わずに
サーバ一個にそのSIMだけにしたり、随時調節している筈。
だからたまに間違っちゃうと「今日なにもしていないのに重い!」
という事態にも陥るわけだが・・・これを「やったもの勝ちになる」とは
捉えない方がいい。軽くてリソースの使用量が極端に少ない「いいお客さん」のSIMは
恐らく心情的な問題で、他の軽いSIMと組み合わせてくれている筈だから。

Avatar Hangoutは以前はVPSだった。
が、これがつまりSLのOpenSpaceと同様の問題が頻発する。
アホの子がどこかのSIMで大量のスクリプトを置いたら
AH全域が超ラグくなったり、イギリスのNというアホの女の子が
大量にスクリプトを置いたらAH全域が超ラグくなったり、
また別の子が駄目と言ってるのにSLからそのまま変なスクリを持ってきたら
全域が落ちたり。

大体問題を起こす人は決まってたんだけどな!

んで今度は、Estate単位でサーバを分断、だけど
初期には選択肢の中にVPSを入れていたら
某スクリプターがVPSを選んで・・・まあこっから以降は
他のEstateには影響がない・・・筈なんだが
VPSを混ぜているとDedicatedのほかの部分にも
影響があることが判明したので、現在は全部Dedicatedのみ。

但しDedicatedにしても、同じEstate内でリソースを大量に使う
SIMがあればそのサーバの他のSIMに影響が出るのは言うまでも無い。
最終的には多分、通常使用のSIM四つぐらいで、リンデン式の言い方ならば
クラス7サーバ一個になると思う。

リソースに関して説明してないが、長くなったのでまたの機会に。

 

Coastal Road2

Posted: 2009/04/02 22:11  by Reiji Mills
Leave a response

ah0314200923.JPG
ah0314200924.JPG

南側の海岸線に道をずーーーーーーっと・・・
しかしイメージが湧いてこないときは作業の手を止める&
建物込みで作りたいので道のイメージが湧いても
そこにあるべき建物を含んだ光景が浮かばないうちは作業を進めないので
ペースは未だかつてなくゆっくり。
とはいってもなんやかんやと実に忙しい。

 

Bridge

Posted: 2009/04/01 9:34  by Reiji Mills
Leave a response

ah0314200922.JPG

今日は橋の建設を進めた。
Avatar Hangoutメインランドからこの橋をずーっとつなげていく予定になっている。
とりあえずSIM一個分形ができたのでそれをSIM四つに並べてみて雰囲気を確認しつつ
真ん中に中央分離帯として何の植物を植えるか、などと考えつつ・・・・

SLやらOpenSIMって狭いんだよねー
視界の関係で建物は現実よりも大きくしないと狭く感じるのに、
現実でそこら辺にどこにでもある50メートルぐらいの幅の道路なんてほとんどない。
あってもそれを複数のSIMにまたがって・・・もない。
まー車が実際に走行したり、それを規制したり渋滞もないから
そんな必要はないんだろうけど、この橋だって幅はわずか30メートル前後だ。

 

Select Language

Latest Comments

BLOG

www.flickr.com
This is a Flickr badge showing public items from the RMH DESIGN group pool. Make your own badge here.