◒◒◒がちゃ屋◒◒◒

  

オープンから１５ヶ月ほどやってきた「らきぼ屋」ですが、
当初の目的であったＬＢ１００枚も無事に達成することができまして
この度閉店することとなりました。

これまでに足を運んで頂きました皆様方、本当にありがとうございました。　m(_ _)m
  

２系ビューアあたりで突然登場したインベントリのシステムフォルダですが、
種類によってはそんなに頻繁にアクセスもしないのにルートにずらーっと
並んでるのがウザい！っ方も居るんじゃないでしょうか？

そんな訳で、システムフォルダの消し方です。
（削除ではなくて、単なる非表示です＾＾）

１．メニューから「ミー＞環境設定」を選ぶ。


２．出てきた窓の「詳細」タブを選択して、「アドバンスメニューを表示」
　　をチェックして「ＯＫ」ボタンを押す。


３．メニューから「アドバンス＞デバッグ」を選ぶ。


３．出てきた窓の左側のリストに「DebugHideEmptySystemFolders」というのが
　　あるので、それを探してクリックする。


４．窓の右側に「TRUE/FALSE」のラジオボタンが出るので「TRUE」を選択。
　　（この窓はもう閉じてＯＫ）


あとは消したいシステムフォルダの中身を別のフォルダに移動したり
削除したりして空にしておくと、そのフォルダは表示されなくなります。
（「コーリングカード」は中身を消しててもリログ後に復活するみたいです；；）
  

お庭の池などに設置いただける鯉を作りました＾＾
環境に優しい１プリで、バリエーションは１０種類です。

クネクネと泳ぎながら、円周軌道をグルグル回ります。
アニメーション中のサーバ負荷はゼロで、非常に環境に優しく
なっています＾＾


オーナーのタッチで設定メニューが出ます。
　・リサイズ：　１０～１０００％
　・回転半径：　０．１ｍ～３ｍ

※メッシュですので、大きくリサイズすると換算値が１プリを
　越えてしまう場合があります

設定メニューは必ず「CLOSE」で閉じてください。
（これを押すことで回りはじめます）


がちゃ屋へ行ってみる

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

ちょっと技術ネタなど。
この商品は生プリ１＋メッシュ１の合計２プリ構成なんですが、
とある事情でスクリプトはルートじゃない子プリムのほうに入れてるんですね。

と言いますのも合計の換算値が１．４ぐらいでほんとギリギリ１なんですが、
スクリをルートプリムに移動すると、なんと１．５になっちゃって２プリ扱いに
なるんですよー。。

スクリの数が０から１に変化する時に、サーバ負荷として０．５が加算されるのは
知ってたんですが、ルートプリムと子プリムで少し差があるようです。
以上、マメ知識でしたー＾＾
  

全体的な浸透率は知るところではないですが、すっかりメッシュも
定着しましたよねー＾＾
時代が進むにつれてＰＣの平均的なスペックも上がっていると思います。

スカルプでの製作に比べ、メッシュではＬＯＤごとの形状を定義できる
ようになったため、製作の自由度はかなり向上しています。
＃無駄な作業が増えてるとも言いますがｗ
しかし、、、
これはモノを作ってる方が一様に悩むポイントだと思うんですが、
　・はたしてＬＯＤはいくらまで保証すれば現実的なのか？
という点です。

もちろん屋内に設置する小物と建物のような大物では根本的に基準が
違ってきますが、１立方メートル程度の置き物を想定した場合、
はたしてどれぐらいのＬＯＤが妥当なんでしょう？


まず、根本的な「何で崩れるの？」という話ですが、これはカメラを
引いた場合には視界に大量のオブジェクトが入ってしまい、頂点を省略しないと
レンダリング負荷が非現実的な域に達してしまうためです。
各オブジェクトのＬＯＤはレンダリング時にカメラからの距離や大きさに
よって動的に計算される訳ですが、この部分のアルゴリズムは半ばＡＩであり
理想的実装に達するのはまだまだ先でしょう。
省略対象となる頂点の自動決定についても同様です。
ですのでＬＯＤＦでの調整の機会を残し、後は運用にまかせてしまう
というのは、まぁ仕様としては妥当に思います。

LODFactorというパラメータは、まぁ名前の通りＬＯＤの係数なんですが、
崩れ具合をほぼ支配的に制御できるぐらいの強い効力があります。
これはビューアが動いているＰＣのスペックによって自動的に初期値が
決定されていますので、今時のＰＣであれば３～４が選択されているでしょう。
崩れるのがイヤーンな人は重くても我慢して４にしてるかもですし、
崩れてもいいから軽く！って人は１に設定しているかもです。
つまり、各ユーザの崩れ具合は製作者からは読めないほどに幅があり、
どのあたりが妥当なのかはほとんど見当すらつかない状況です。

さらにこれはリンデン側の問題ですが、せっかく低ＬＯＤ用に専用モデルを
定義できるようになったものの、それらしいモデルをちゃんと作ると
プリム換算値がえらいことになってしまい、ＵＰにも設置にも非常に高い
コストががかかってしまうようになります。
ですので現状は、保障するつもりのないＬＯＤについてはとにかく頂点を
省略しまくって、形状すら見えなくなるぐらいまで省略させるしか現実的な
解はないような状況だったりしています。


あくまで参考ではありますが、僕が個人的に決めているガイドラインを
ご紹介しますと、
　・ＬＯＤＦを1.0に設定する
　・本来想定されるサイズでＲｅｚする
　・近くをウロウロしてみて、我慢できるかどうか？
な感じで決めています。
この基準ですと、屋内小物でＬＯＤ３保証ってのはナシです。
（ＬＯＤ２までは保証しないと、崩れまくってどうにもなりません）


ちなみにプリム換算値の挙動についてはずっと考察しているのですが、
あからさまに特徴的な点はいくらかありまして、
　・全体のサイズが大きいとやたら高くなる
　・低ＬＯＤでの頂点数が多いとやたら高くなる
というものです。
もちろんどちらの挙動もレンダリングコストとしての意味合いでは
それなりの根拠がありますので全然ダメダメではないのですが、
若干カーブがおかしいように感じます。

もちろんプリム数に対する感覚は千差万別ですし、これはもはや価値観
でしょうからmustな話にはならないとも思うのですが、一つの観点として
　・客がプリムを浪費するとリンデンが儲かる
というものがあり、この図式は揺るぎない事実だと思うんですね。
僕はそれを理由として省プリにこだわっていますｗ


大物については今のところスカルプの優位性が若干残っており、
住み分けの機会が残っているあたりが、なんとも面白い感じです。
ただ、スカルプでは物理効果の換算がおかしなことになってきており、
球体判定にもかかわらず1.8とかになる場合があります；；；
（生プリでの球の物理効果は0.1です）
単体プリムでもhavokから外せるようになると良いのですが。。
  

なーんとなくですが、ＳＬでのオブジェクトの不正コピーについて
書いてみようかと思います。

先日、実際にFireStromをビルドしてみてデバッガで追っかけたり
軽くコードを改変したりしながら様子を見てみましたが、少なくとも
　・テクスチャ画像
　・スカルプマップ
これらについては他人のオブジェクトであっても、非常に簡単に
ＵＵＩＤを知ることができます。
ご存知の方も多いとは思うのですが、テクスやスカルプはＵＵＩＤさえ
知っていれば、スクリで簡単にオブジェクトに設定できるんですね。
（つまりフルパのデータを持っているかのように使えてしまいます）

メモリ上で暗号化されてる訳でもなく、サーバから参照専用のキーを
貰ってる訳でもなく、それどころかアクセサまでバッチシ揃ってる
コードを改変して利用することができる環境な訳ですから、保護対策
なんて一切ないと言っていいでしょう。

版権回りの問題を懸念してメッシュを見送ってスカルプを導入した
割には、はてさて、、セキュリティ的に何の工夫もないコードを
オープンにした意義は何だったのか、、なんとも謎です。
商品としてがんばって描かれてるテクス屋さんなどの心情を考えますと、
権利を保護するつもりのないリンデンにはなんとも憤りを感じます。


がしかし、ここで根本に立ち戻りますと、これはあらゆるデジタルデータに
ついて言えることですが、根本的にコピーは可能なんですね。
正常系においてデコードおよび再生ができないとコンテンツとしては
意味を成さない訳であり、そうなのであれば同じ手順を踏めば必ず
ローデータにアクセスできるため、原理的にデジタルコピーは可能となります。

ＳＬで言えば、ローカルでのレンダリングが前提である以上、頂点配列を
知らないと形状が表示できませんし、ピクセル配列を知らないと面が
塗れないのでローデータへのアクセスはどうしても避けられません。
この部分に悪意のあるコードを仕込まれてしまうと、ＵＵＩＤなどの
リンデン的なアセットとしては保護できたとしても、同一データを再ＵＰ
されてしまうと、結局デジタルコピーは成立しちゃうんですね。
　・別アカでの同一データのＵＰを封じる
なんて仕様もアリかもですが、デジタルデータとはいえその多くは
アナログデータの表現でしかないため、僅かに変更したデータを
どう扱うのか等これまた非常に難しい問題が出てきます。


そんなこんなで、ローカルレンダリングである以上は根本的なコンテンツ
保護はできないんだから、半端に工数かけたところで無駄じゃね？ｗ
とリンデン自身が割り切ってしまって良いのかどうか。。
さて、あなたはどう見ます？ｗ

僕自身の個人的見解は、リンデンの経営状況により、、ですかねー。
十分に利益が出てるならセキュリティ改善に努めて欲しいですし、
芳しくないなら、、残念ですが現実的に無理でしょう。
セキュリティ対策というのは完璧ではないにしても、やっただけ
それなりの効果は必ずあります。
なんとかリンデン様にはがんばって頂きたいところです＾＾
  Read More...