› Gausman Music › 2008年02月2008年02月24日
Bone
Natural,Black,Pinkの三色です。
最近なぜスカルプの負荷やラグについて調べていたのかというと、
こちらのゴリゴリスカルプ作品を販売するためだったのですね！
本当はラグについての実験を完了させてから販売しようと思っていたのですが、
ひょんなきっかけで前倒し販売となりました。
各L$60、フロントスタイル、バックスタイルの2本で1セットです。
※サウンドはついておりません。
あわせてギタープレイアニメーションHUD「GM gt-HUD（L$100）」もどうぞどうぞ！
さてこのホネホネロック、Horishi Haxに見せてみましたところ、
おいここはこうしろとか質感もっと出せよこのサル店長が！
などと言われましたので、じゃあ修正するからもうちょっと販売は先になりそうだな～と思っておりました。
ところで店長これはいつ、何色販売するんだい？
と聞かれ、全然決めてないよ、と申し上げたたところ、
ちょっと気合入れてさ今日の0時に全部作業終えて販売しろよ
んでこれ同梱しとけ！店長今日はめちゃイケおあずけな！
と言って彼のホネホネタトゥーを投げつけられたのでございます。
ということで、3/3（月）24：00まで！期間限定でHoly Ground製Bone Tattooを同梱させていただきます！
各色それぞれ種類の異なったTattooが入っておりますよ！現在Gausman Musicにて販売中です。
内容はコチラ！
以上何卒宜しくお願い申し上げます。
Gausman Music (JPL KANAGAWA)
Tattoo&Furniture&Doara
Holy Ground
最近なぜスカルプの負荷やラグについて調べていたのかというと、
こちらのゴリゴリスカルプ作品を販売するためだったのですね！
本当はラグについての実験を完了させてから販売しようと思っていたのですが、
ひょんなきっかけで前倒し販売となりました。
各L$60、フロントスタイル、バックスタイルの2本で1セットです。
※サウンドはついておりません。
あわせてギタープレイアニメーションHUD「GM gt-HUD（L$100）」もどうぞどうぞ！
さてこのホネホネロック、Horishi Haxに見せてみましたところ、
おいここはこうしろとか質感もっと出せよこのサル店長が！
などと言われましたので、じゃあ修正するからもうちょっと販売は先になりそうだな～と思っておりました。
ところで店長これはいつ、何色販売するんだい？
と聞かれ、全然決めてないよ、と申し上げたたところ、
ちょっと気合入れてさ今日の0時に全部作業終えて販売しろよ
んでこれ同梱しとけ！店長今日はめちゃイケおあずけな！
と言って彼のホネホネタトゥーを投げつけられたのでございます。
ということで、3/3（月）24：00まで！期間限定でHoly Ground製Bone Tattooを同梱させていただきます！
各色それぞれ種類の異なったTattooが入っておりますよ！現在Gausman Musicにて販売中です。
内容はコチラ！
以上何卒宜しくお願い申し上げます。
Gausman Music (JPL KANAGAWA)
Tattoo&Furniture&Doara
Holy Ground
2008年02月22日
ラグ考察 ２
前回記事で触れました、作り手として、それを利用する、あるいは描画させる人に対しての負荷を
軽減するために気をつけたほうがよいこととして、
・常時動くスクリプトを再検討する
・プリム数を減らす
・テクスチャサイズを小さくする（512×512以下）
・パーティクルはなるべく控える
・過度のスカルプティ
恐らくこの他にも挙げれば枚挙にいとまがないと思うのですが、全部実行しようとすると、
モノ作るなSLやめろという、本末転倒な結果になってしまうんですね。
そんなのはやですね。
ということで、どれをどれだけ気をつければよいのでしょうか。
上記に挙げた項目の上から四項はわかりやすいです。
自分が表現したいことに支障をきたさないギリギリのラインまで最小化すればよいです。
一番下、「過度のスカルプティ」・・・これがわかりにくいですね。
過度ってどれくらい？スカルプだからといって？負荷に関して標準プリムとどう違うのさ！
という感じでイラっときますね。え、こない？
前フリが長くなりましたが今回は「Sculpted Prims（以下スカルプ）」に関して、
Second Life WikiのSculpted Prims: FAQを参照しながら今一度考えてみます。
■スカルプとは
少ないプリム数で有機的で複雑な形状を表現できてしまうアレです。
どうやってあの形を描画しているかというと、「スカルプトテクスチャ」と呼ばれる
あのグラデーションがかったテクスチャのRGB値を、それぞれx,y,z値に換算してモデリング、描画しています。
ちなみにRGBとはRed,Green,Blueのイニシャルです。
レッド吉田はグッドジョブの略じゃないです。私はグッドジョブだと思いますが。
例えば、z軸に対してうっすーいスカルプを作りたい場合は、画像編集ソフトの色調補正などで
青色を調整してやればいいですね。
では負荷に関して、前回同様、サーバー（SIM）とクライアント（各PC）の観点から考察します。
間違ってたらごめんなさい！しかも答えは出ないかもしれません！
■スカルプの負荷ついて
・サーバー（SIM）側
サーバー（SIM）に与える負荷として考えられるのは物理に関する項目ですが、FAQによると、
物理エンジンにおける運動・衝突の扱いは、そのスカルプと大体同じ大きさの"lopsided sphere"と
同じだということです。
"lopsided sphere"ってよくわかりません。不均衡な球？歪んだ球？
さらに、「将来それ以上の詳しい説明をするかもしれません」と書いてありますが、
これが書かれたのは恐らく一年くらい前じゃないかと・・・。
前記事でサーバー管理者（SIMオーナー）であるSincrea氏のコメントにあるように、どんなプリムでも
物理属性を与えるだけで結構な負荷になるということらしいですので、
これは「スカルプだから」ということにはならないのかもしれません。
・クライアント（各PC）側
クライアント（各PC）に与える負荷としては形状・テクスチャの読込み・表示に関するものですが、FAQによると、
1000の頂点（32×32？）を持つスカルプのレンダリング負荷は"中空トーラス"と同程度ということらしいです。
"中空トーラス"の頂点も1000くらいあるということですよね。
前記事でmagnumさんに教えていただいたポリゴン換算に非常に納得したわけですが、
ということは、"中空トーラス"も過度に使うとラグの原因になるということでしょうか・・・。
いずれにしろ、「スカルプだから」負荷が高いとかラグが増すとかいうのは、いまいちピンと来ないわけです。
確かにスカルプは標準プリムと違って、別にスカルプトテクスチャを読込み処理をしなくてはいけないので
その分負荷はあるわけですが、リンデンが推奨する64×64サイズのスカルプトテクスチャなどは、
普段512×512等の標準テクスチャをガリガリ処理している私たちにとって、それほど憂慮すべき
要因にはならないのではないかとも思います。
頂点数の少ないキューブのみで構成されたオブジェクトと1000近い頂点数のスカルプのみで構成された
オブジェクトを描画する際は、確かに差（ラグが発生する発生しない等）が出ると思います。
じゃあキューブのみで構成されたオブジェクトと中空トーラスのみで構成されたオブジェクトを比べた場合は？
というと恐らくスカルプの場合と同じなのでは・・・という気がしてきました。
lslWikiにこんな一文がありました。
To make sure one's created objects aren't causing extra rendering lag, avoiding lots of polygons and textures is a good idea, but most people have computers that can keep up these days.
とても主観的なコメントですね。
しかしながら「そうなんだ～」とも思っちゃいましたね。
以上、所詮机上の空論でございます。
次回は実際に実験してみたいと思いますが、ああめんどくさい。
順番は逆ですが参考文献はこちら
・Lag - lslWiki
・Region Performance Improvement Guide/ja - Second Life Wiki
・Sculpted Prims: FAQ - Second Life Wiki
軽減するために気をつけたほうがよいこととして、
・常時動くスクリプトを再検討する
・プリム数を減らす
・テクスチャサイズを小さくする（512×512以下）
・パーティクルはなるべく控える
・過度のスカルプティ
恐らくこの他にも挙げれば枚挙にいとまがないと思うのですが、全部実行しようとすると、
モノ作るなSLやめろという、本末転倒な結果になってしまうんですね。
そんなのはやですね。
ということで、どれをどれだけ気をつければよいのでしょうか。
上記に挙げた項目の上から四項はわかりやすいです。
自分が表現したいことに支障をきたさないギリギリのラインまで最小化すればよいです。
一番下、「過度のスカルプティ」・・・これがわかりにくいですね。
過度ってどれくらい？スカルプだからといって？負荷に関して標準プリムとどう違うのさ！
という感じでイラっときますね。え、こない？
前フリが長くなりましたが今回は「Sculpted Prims（以下スカルプ）」に関して、
Second Life WikiのSculpted Prims: FAQを参照しながら今一度考えてみます。
■スカルプとは
少ないプリム数で有機的で複雑な形状を表現できてしまうアレです。
どうやってあの形を描画しているかというと、「スカルプトテクスチャ」と呼ばれる
あのグラデーションがかったテクスチャのRGB値を、それぞれx,y,z値に換算してモデリング、描画しています。
ちなみにRGBとはRed,Green,Blueのイニシャルです。
レッド吉田はグッドジョブの略じゃないです。私はグッドジョブだと思いますが。
例えば、z軸に対してうっすーいスカルプを作りたい場合は、画像編集ソフトの色調補正などで
青色を調整してやればいいですね。
では負荷に関して、前回同様、サーバー（SIM）とクライアント（各PC）の観点から考察します。
間違ってたらごめんなさい！しかも答えは出ないかもしれません！
■スカルプの負荷ついて
・サーバー（SIM）側
サーバー（SIM）に与える負荷として考えられるのは物理に関する項目ですが、FAQによると、
物理エンジンにおける運動・衝突の扱いは、そのスカルプと大体同じ大きさの"lopsided sphere"と
同じだということです。
"lopsided sphere"ってよくわかりません。不均衡な球？歪んだ球？
さらに、「将来それ以上の詳しい説明をするかもしれません」と書いてありますが、
これが書かれたのは恐らく一年くらい前じゃないかと・・・。
前記事でサーバー管理者（SIMオーナー）であるSincrea氏のコメントにあるように、どんなプリムでも
物理属性を与えるだけで結構な負荷になるということらしいですので、
これは「スカルプだから」ということにはならないのかもしれません。
・クライアント（各PC）側
クライアント（各PC）に与える負荷としては形状・テクスチャの読込み・表示に関するものですが、FAQによると、
1000の頂点（32×32？）を持つスカルプのレンダリング負荷は"中空トーラス"と同程度ということらしいです。
"中空トーラス"の頂点も1000くらいあるということですよね。
前記事でmagnumさんに教えていただいたポリゴン換算に非常に納得したわけですが、
ということは、"中空トーラス"も過度に使うとラグの原因になるということでしょうか・・・。
いずれにしろ、「スカルプだから」負荷が高いとかラグが増すとかいうのは、いまいちピンと来ないわけです。
確かにスカルプは標準プリムと違って、別にスカルプトテクスチャを読込み処理をしなくてはいけないので
その分負荷はあるわけですが、リンデンが推奨する64×64サイズのスカルプトテクスチャなどは、
普段512×512等の標準テクスチャをガリガリ処理している私たちにとって、それほど憂慮すべき
要因にはならないのではないかとも思います。
頂点数の少ないキューブのみで構成されたオブジェクトと1000近い頂点数のスカルプのみで構成された
オブジェクトを描画する際は、確かに差（ラグが発生する発生しない等）が出ると思います。
じゃあキューブのみで構成されたオブジェクトと中空トーラスのみで構成されたオブジェクトを比べた場合は？
というと恐らくスカルプの場合と同じなのでは・・・という気がしてきました。
lslWikiにこんな一文がありました。
To make sure one's created objects aren't causing extra rendering lag, avoiding lots of polygons and textures is a good idea, but most people have computers that can keep up these days.
とても主観的なコメントですね。
しかしながら「そうなんだ～」とも思っちゃいましたね。
以上、所詮机上の空論でございます。
次回は実際に実験してみたいと思いますが、ああめんどくさい。
順番は逆ですが参考文献はこちら
・Lag - lslWiki
・Region Performance Improvement Guide/ja - Second Life Wiki
・Sculpted Prims: FAQ - Second Life Wiki
2008年02月20日
ラグ考察 １
最近、「セカンドライフのラグ」について、ダラダラと調べておりました。
LSL WikiのYahooおとぼけ翻訳先生や、先人たちの和訳を参考に自分なりにまとめてみます。
こういった技術情報は現状、能動的にならないとどうやら得られないようで、
ソラマメはどちらかというとその点受動的な印象を受けます。
ま、こんな記事はつまんないから流行らないのはわかりますがねっ！
SL重くてツマンネーの原因と対策を考察するのも大事です。
■SLにおけるラグについて
SLにおけるラグとは、ビュワーがカクカクしたり重くなったりする、いわゆるフレーム落ちの現象です。
原因と対策は主に二種類にわけられます。
サーバー（SIM）によるものと、クライアント（各PC）によるものになります。
■ラグの原因
・サーバー（SIM）によるもの
サーバー（SIM）は独立したCPUとして稼働しています。
当然計算をいっぱいすればするほど重くなります。
サーバー（SIM）が計算するものとして、スクリプト、物理計算が必要なオブジェクトなどがあげれるようです。
スクリプトに関しては、計算している時（動いている時）にサーバー（SIM）が稼働しますので、
常時動かなければいけないセンサーやリスナー系のスクリプトは、サーバーに（SIM）に負担をかけます。
たとえば、何秒ごとにこのアニメーションを再生！というA.Oや、何秒ごとに半径何mにいる
アバター情報を取得する来客センサーなど・・・。
逆に、そんなに動かないスクリプトはそんなんでもないということで、決してスクリプト=悪ではありません。
物理計算が必要なオブジェクトについては、サーバー（SIM）にRezしたプリムはその時点で衝突判定計算が
行われ続けますので、単純にRezされたプリムが多ければ多いほど高負荷ということになりますよね。
違うかな・・・。
さらに重力プリムやフレキシブルプリムとなると、えらい計算が必要になるんでしょうね。
あれ？でもこれはクライアント（各PC）の処理になるのかな・・・？両方かな？
しかしそう考えると、臨時プリムを同じ場所にダブらせて延々とRezし続けるプリムセーバーなんかは、
サーバー（SIM）に大変負担をかけるということになるでしょうね。
ちなみに臨時プリムは土地プリムに加算されませんが、アバターがそのオブジェクトにSitすると
途端に土地プリムに加算されるようです。これは気をつけなければいけませんね。
・クライアント（各PC）によるもの
テクスチャやプリムの読込み・表示性能はクライアント（各PC）のスペックや回線速度に依存します。
当然、必要以上に大きいサイズのテクスチャや、必要以上のプリム数でできたオブジェクトなどを表示する時は、
クライアント（各PC）に負荷がかかり、クライアントのスペックが満足でない限りラグを発生させます。
特にアルファ（透明）のテクスチャは高負荷なようです。
また、光源処理も各クライアント（各PC）が処理します。あとはパーティクル処理ですね。
各クライアントがゴリゴリのハイスペックマシンであれば、これは何の問題もありません。
しかし、まずそうではないですよね。
■ラグの対策
・サーバー（SIM）に対する・・・
常時動いているスクリプトの効率化。
たとえば、自動ドアを作りたい場合、センサーよりタッチイベントなどを使いましょう。
どうしてもセンサーを使う場合、必要な秒数間隔を再検討しましょう。範囲についても同様です。
リスン関数も同様に最小限に抑えましょう。
物理プリムの効率化
本当にそこにそのプリムが必要かどうかを再検討しましょう。
植物などのフレキシブルプリム等も同様に。
・クライアント（各PC）に対する・・・
PCを買い換えましょう。
これが一番手っ取り早いですが、そんなわけにもいかねーよバカか！と私に言われてもLSL Wikiによると
そう結論付けるしかないのですががががががっががが。
自分のビュワーの設定を見直しましょう。
環境設定をスペック以上の設定にしていませんか？私は結構していますウヘヘ。
では具体的に、土地オーナーとして、ユーザーとして、作り手として、
どのようなことに気をつければよいのでしょうか。
Second Life Wiki Region Performance Improvement Guideを見てみました。
上記も踏まえてまとめると・・・
土地オーナーとしては
・負荷の高いスクリプトを取り除く
・負荷の高いコリジョン（オブジェクト？）を取り除く
・大きなテクスチャを取り除く
・プリム数を減らす
・ヒュージプリムは使わない
ユーザーとしては
・負荷の高いスクリプトを取り除く
・アタッチメントしているプリムを減らす
・光源（フェイスライト）数を減らす
・パーティクルはなるべく控える
作り手としては
・常時動くスクリプトを再検討する
・プリム数を減らす
・テクスチャサイズを小さくする（512×512以下）
・パーティクルはなるべく控える
・過度のスカルプティ
ヒュージプリムは負荷やラグどうこうの前に問題があるようなので、
機会があればちゃんと調べてみようと思います。
過度のスカルプティ・・・
過度の標準プリムとどう違うの？スカルプティだったら何がラグに影響を及ぼすの？
次回このあたりを検証しつつ、超つまんねー記事は続くのであります。
LSL WikiのYahooおとぼけ翻訳先生や、先人たちの和訳を参考に自分なりにまとめてみます。
こういった技術情報は現状、能動的にならないとどうやら得られないようで、
ソラマメはどちらかというとその点受動的な印象を受けます。
ま、こんな記事はつまんないから流行らないのはわかりますがねっ！
SL重くてツマンネーの原因と対策を考察するのも大事です。
■SLにおけるラグについて
SLにおけるラグとは、ビュワーがカクカクしたり重くなったりする、いわゆるフレーム落ちの現象です。
原因と対策は主に二種類にわけられます。
サーバー（SIM）によるものと、クライアント（各PC）によるものになります。
■ラグの原因
・サーバー（SIM）によるもの
サーバー（SIM）は独立したCPUとして稼働しています。
当然計算をいっぱいすればするほど重くなります。
サーバー（SIM）が計算するものとして、スクリプト、物理計算が必要なオブジェクトなどがあげれるようです。
スクリプトに関しては、計算している時（動いている時）にサーバー（SIM）が稼働しますので、
常時動かなければいけないセンサーやリスナー系のスクリプトは、サーバーに（SIM）に負担をかけます。
たとえば、何秒ごとにこのアニメーションを再生！というA.Oや、何秒ごとに半径何mにいる
アバター情報を取得する来客センサーなど・・・。
逆に、そんなに動かないスクリプトはそんなんでもないということで、決してスクリプト=悪ではありません。
物理計算が必要なオブジェクトについては、サーバー（SIM）にRezしたプリムはその時点で衝突判定計算が
行われ続けますので、単純にRezされたプリムが多ければ多いほど高負荷ということになりますよね。
違うかな・・・。
さらに重力プリムやフレキシブルプリムとなると、えらい計算が必要になるんでしょうね。
あれ？でもこれはクライアント（各PC）の処理になるのかな・・・？両方かな？
しかしそう考えると、臨時プリムを同じ場所にダブらせて延々とRezし続けるプリムセーバーなんかは、
サーバー（SIM）に大変負担をかけるということになるでしょうね。
ちなみに臨時プリムは土地プリムに加算されませんが、アバターがそのオブジェクトにSitすると
途端に土地プリムに加算されるようです。これは気をつけなければいけませんね。
・クライアント（各PC）によるもの
テクスチャやプリムの読込み・表示性能はクライアント（各PC）のスペックや回線速度に依存します。
当然、必要以上に大きいサイズのテクスチャや、必要以上のプリム数でできたオブジェクトなどを表示する時は、
クライアント（各PC）に負荷がかかり、クライアントのスペックが満足でない限りラグを発生させます。
特にアルファ（透明）のテクスチャは高負荷なようです。
また、光源処理も各クライアント（各PC）が処理します。あとはパーティクル処理ですね。
各クライアントがゴリゴリのハイスペックマシンであれば、これは何の問題もありません。
しかし、まずそうではないですよね。
■ラグの対策
・サーバー（SIM）に対する・・・
常時動いているスクリプトの効率化。
たとえば、自動ドアを作りたい場合、センサーよりタッチイベントなどを使いましょう。
どうしてもセンサーを使う場合、必要な秒数間隔を再検討しましょう。範囲についても同様です。
リスン関数も同様に最小限に抑えましょう。
物理プリムの効率化
本当にそこにそのプリムが必要かどうかを再検討しましょう。
植物などのフレキシブルプリム等も同様に。
・クライアント（各PC）に対する・・・
PCを買い換えましょう。
これが一番手っ取り早いですが、そんなわけにもいかねーよバカか！と私に言われてもLSL Wikiによると
そう結論付けるしかないのですががががががっががが。
自分のビュワーの設定を見直しましょう。
環境設定をスペック以上の設定にしていませんか？私は結構していますウヘヘ。
では具体的に、土地オーナーとして、ユーザーとして、作り手として、
どのようなことに気をつければよいのでしょうか。
Second Life Wiki Region Performance Improvement Guideを見てみました。
上記も踏まえてまとめると・・・
土地オーナーとしては
・負荷の高いスクリプトを取り除く
・負荷の高いコリジョン（オブジェクト？）を取り除く
・大きなテクスチャを取り除く
・プリム数を減らす
・ヒュージプリムは使わない
ユーザーとしては
・負荷の高いスクリプトを取り除く
・アタッチメントしているプリムを減らす
・光源（フェイスライト）数を減らす
・パーティクルはなるべく控える
作り手としては
・常時動くスクリプトを再検討する
・プリム数を減らす
・テクスチャサイズを小さくする（512×512以下）
・パーティクルはなるべく控える
・過度のスカルプティ
ヒュージプリムは負荷やラグどうこうの前に問題があるようなので、
機会があればちゃんと調べてみようと思います。
過度のスカルプティ・・・
過度の標準プリムとどう違うの？スカルプティだったら何がラグに影響を及ぼすの？
次回このあたりを検証しつつ、超つまんねー記事は続くのであります。
2008年02月15日
プロポーズされました
2008年02月15日
ガッと来て
ダーッとなってグワーッと来て、目がぐわんぐわんなって、グロッキーにはなりたくなかったので、
少しの間オフライン&ベータグリッド作業に専念し、ブログも小休止しようとしていたその矢先、
一通のメールが、マイコンに舞い込んできました。
―――――――――――――――――――――――――――――――――――――――――――――
Second Life Partner: Proposal from Horishi Hax
Dear Geteee Gausman,
You have received a Second Life partner proposal from Horishi Hax. Please
visit the link below to view the proposal:
http://secondlife.com/community/partners.php
This proposal will expire on Thursday, February 14, 2008.
--
PLEASE NOTE: DO NOT REPLY TO THIS EMAIL - Your reply will not be recieved.
You must visit the link above to accept or deny the proposal.
--
Best Regards,
Second Life and the Linden Lab Team
http://secondlife.com
―――――――――――――――――――――――――――――――――――――――――――――
？？？
―――――――――――――――――――――――――――――――――――――――――――――
親愛なるGeteee Gausman様
あなたは Horishi Hax からSLパートナーとしてプロポーズされました
下記リンクからプロポーズを確認してください
http://secondlife.com/community/partners.php
---
・・・
---
第2の生命とリンデン研究室チーム
http://secondlife.com
―――――――――――――――――――――――――――――――――――――――――――――
by Yahoo先生
ハァ？
少しの間オフライン&ベータグリッド作業に専念し、ブログも小休止しようとしていたその矢先、
一通のメールが、マイコンに舞い込んできました。
―――――――――――――――――――――――――――――――――――――――――――――
Second Life Partner: Proposal from Horishi Hax
Dear Geteee Gausman,
You have received a Second Life partner proposal from Horishi Hax. Please
visit the link below to view the proposal:
http://secondlife.com/community/partners.php
This proposal will expire on Thursday, February 14, 2008.
--
PLEASE NOTE: DO NOT REPLY TO THIS EMAIL - Your reply will not be recieved.
You must visit the link above to accept or deny the proposal.
--
Best Regards,
Second Life and the Linden Lab Team
http://secondlife.com
―――――――――――――――――――――――――――――――――――――――――――――
？？？
―――――――――――――――――――――――――――――――――――――――――――――
親愛なるGeteee Gausman様
あなたは Horishi Hax からSLパートナーとしてプロポーズされました
下記リンクからプロポーズを確認してください
http://secondlife.com/community/partners.php
---
・・・
---
第2の生命とリンデン研究室チーム
http://secondlife.com
―――――――――――――――――――――――――――――――――――――――――――――
by Yahoo先生
ハァ？
