MH+ Aluminum Collar (fix and update)

昨年にリリースしたMH+ Aluminum Collarに不具合が見つかったので修正と僅かな変更を加えました。というのも、自分用のCollarのアニメ再生部分を設定していたら、どうもファイルが少し欠けているというのが判明して、もしかしなくてもコレの元になっているCollarも抜けているのでは?と確認してみたら案の定、同じように欠損しているファイルがありました。

具体的に何が欠けていたかは、アニメ再生時の高さ調整用のファイルが部分的にしか入っておらず、正しく高さ調整が出来ないという問題が起こります。高さを調整しようと意図的に操作しない限り分からないので露見しなかったのだと思います。


[A]タイプ
[B]タイプ
[C]タイプ

何れも修正対象でした。
欠損しているファイルを補填しただけです
収録しているOpenCollarのバージョンは3.997のままです。

FREE版も同様に欠損しているファイルの補填で
収録しているOpenCollarのバージョンは3.997のままです。

こちらはオマケとしてハロウィン仕様の時のカボチャの部分をベルとみなして表示のOn/Offが出来るようにしました。これによりFREE版でも[A]タイプとほぼ同じ外観になります。([A]タイプはちゃんとしたベルが付いています)


ただ、もしかするとOC3.997でのLeash用のパーティクルがアセットから消えているように思えるときがあったので、パーティクルが出ないままかも知れません。(これはちょっと未確認です)

MH+ Alive-C terminal update v1.6 (minor change)

terminal装置のアップデートを行いました。

特にクリティカルな不具合への対処ではありません。既にv1.5を利用している場合は、そのままでも構いません。

頻発しそうな問題でないのでアップデート品の配信は行っていません。
必要な場合は再配送ターミナルから各自で受け取ってください。




◆主な変更/修正内容
 ・OnLine状態の時でServerURL取得時に応答無し、または破損したURL情報の場合に停止してしまう場合の対処
 ・再接続のリトライ回数を500→1000へ拡大(概ね2.7時間まで繰り返します。それでも回復しない場合はエラー停止(赤文字))
 ・設定変更にて各項目設定時に毎回、前メニューに戻らないように変更



今週のローリングリスタートでAlive-Cのサーバーが設置してあるSIMの起動が遅く、妙だなぁと思っていましたが、とりあえず再起動はしたものの動きが妙で同じSIMに設置してあったオンラインチェッカーは反応しているもののタイマー動作が停止したような感じで正常とは言い難い状況でした。仕方なくオンラインチェッカーは手動でリセットを掛けたのですが、その後に予想通りSIMの再起動が行われたようで、Alive-Cのサーバー側も再びリスタートしたのですが、その時にAlive-Cターミナルの何台かが応答無し状態の沈黙に入ってしまう場合があるというのが見つかりました。恐らくはHTTP通信でヘッダーだけ返却されて中身が無いという状態なのではなかったかと想像していますが(WEBブラウザとかではしばしば見かける空白の画面となるような場合)実際何が起きたかは不明です。状態として画像のような1回目から止まったままという見た目になります。

ターミナルV1.5では、こうなった場合、本体にタッチして【停止】→【開始】とすれば復旧できます。

けれども確実な自動運転としたいので、ちょこっと修正してみました。
リトライ回数を更に倍にしたのはLindenさんのローリング作業時間が、どうも1時間チョットじゃ足りないんじゃないかと不安になるので、さらに2倍の待ち時間2.7時間としました。
そしてURL取得時の破損データまたは、応答がなかった場合に備えて再処理させるように細工しました。

この改変により、さらに大穴を生じているかも知れないのでV1.6としてリリースはしますが、置き換え推奨ではありません。上記の画像の状態で停止する事が頻発する場合に置き換えてみてください。

MH+ Alive-C terminal update v1.5 (major change)

terminal装置のアップデートを行いました。

特にクリティカルな不具合への対処ではありませんが内部仕様に大幅な変更を加えています。
出来るかぎりアップデートしてください。


既存のユーザー宛にCasperVendからアップデート品を一斉配信済みです。
なお[M]版および[P]版を利用されている方にも送信しています。
このため[M]版または[P]版と[無印版]を両方とも利用している方には今回、重複して配信されますが誤配信ではありません。


対象は
●Alive-C terminal (無印版) → v1.5
●Alive-C terminal for MODERATE (M版) → 廃止 (無印版と統合)
●Alive-C terminal Portable (P版) → 廃止

◆主な変更/修正内容
 ・レーティング区分での設置条件を廃止(Moderate版との統合、Personal版の廃止)
 ・サーバー側と同等の自己URL監視機能を追加(2スクリプト化)
 ・集計停止状態と集計しないで設置する場合の区別が曖昧なため動作ステート遷移の見直し
 ・non full-Bright版の添付を廃止(メニューより表示部のフルブライト切換を追加)
 ・見た目の筐体のテクスチャを変更(新旧の見分けが付きにくいため)
 ・動作中でも設定内容が確認できるようにメニュー追加


◆[M]版、[P]版の統廃合について
 まずP版の廃止ですが、Alive-C[P]運用開始から1件程度しか利用実績が無く、移動体からの利用あるいは一時的な利用や匿名での利用というものに興味を示される方が居なかったというのが本音ですが、継続するにしても他の無印版や[M]版と仕組みが少々異なるのため改良などで維持していく手間が面倒になってしまったと感じるようになり、そういうコンセプトがあったという事実だけにとどめ、封印してしまおう♪という次第です。仕掛け的にはエロ系HUDのトラッカーとかなどでグリッドワイドで遊ぶツールのように使えるはずですが、レイプや出会いなど特化した目的を持ったものではないので利用される事はなかったのだろうと思います。

 M版の統合(というか仕組み的には廃止)ですが、これは単純に利用者が少なかった事や、AdultとModerateで分けてしまった事により従来の「カオスなSecondLife」が表現できなかったこと、UIの操作として表示対象を選択するというスタイルが今のタップ&スワイプの時代には合っていない事など気に入らない所が沢山あるので、シンプルに1種類にしたっていいじゃないって考えに至りました。そもそもAdultコンテンツが表示できる人達ならばModerateやGeneralのコンテンツを同時表示しても良いのだし、もとからAlive-C Viewerでは使用前に「Over 18?」のチェックも付けているという前提もあるのだから・・・。


◆v1.5での設置条件
以前までは(主に無印版で)土地のレーティング区分に基づき、諸般の条件が妥当かシステム的にチェックしていましたが、v1.5からはレーティング区分による区別を行わないこととしたので殆どの制限はありませんが次の2つだけは継続しています。

・区画面積が128SQM未満の場合は利用できません
・区画のオーナーがLinden総督(Governor Linden)の場合は利用できません


//////////
いまだに、まだAlive-Cターミナル装置はSIMのリスタートなどで挙動不審になることがしばしば見られるので、やむをえず2スクリプト化により安定を図るように大幅に改造しました。機能的には何一つ変わっていないのでバージョン番号は少し上げただけですが、内部的にはステータス遷移を【初期】-【設定変更/オフライン】-【オンライン】としていたのを【初期/設定変更】-【オフライン】-【オンライン】と明確に内容で分けるように振り分けました。まぁ、それでも中身はかなりゴチャゴチャして読みにくいソースですけどね。 Alive-Cサーバーの方は今年の2月に外部WEBを移設してからは安定して動作しています。今日までに一度も触ってないんですが、しっかり稼働していますよ。このAlive-Cサーバーの方には既に正常に動作しているか自己チェックをするロジックが入れてあるのですが、それと同等となるように、今回、Alive-Cターミナル装置にも自己チェックを組み入れてみました。正常に動作するのか、はてまたターミナルでも効果があるのか、長期的に見ていくことになりますが、現時点でこれがBESTだという対処であり、まだまだ実験的だと言わざるを得ません。

MH+ Alive-C viewer update (v1.5)

MH+ Alive-C viewerがVersion 1.5となりました
terminal側の修正に合わせた変更です


変更点は
----- v1.5 (2016/12/14) -----
・Adult / Moderate / Personal の区分切換廃止
・装着時のウィンドウ・スナップもどきの動作を廃止
・サーバーURL取得時のエラーカウントを3→2に短縮


新バージョンは各地にあるCasperVendの再配送ターミナルから受け取ってください。
(近くにない場合はMH+ Labsの店内にあるre-delivery端末をご利用下さい。)

出歩けないアバターな場合はマーケットプレイスのご利用もどうぞ~

ログイン型チップジャー(改)

お店として機能させるにはチップジャーが不可欠かなぁと。ダンサーさんやモデルさんなんかだとMyチップジャーをアバターに装着していたりもしますが、あれはなんだか守銭奴みたいでスマートじゃない気がするんですよねw かといって備え付けで個人持ちのチップジャーだと利用者の数分、ジャーの受け皿が必要だったり、個別に受領した金額が分かってしまう事から、よからぬ摩擦を生んでしまったりで、よくない部分の方が多いかなぁと感じます。その場限りの楽しみならば、チップジャーも一時的な物の方がスマートですよね。そういう趣旨でログイン型のチップジャーがいいかなぁと。ちらっとマーケットプレイスで探してみたりしましたが安価な物だと作者がチップをピンハネするような設定になっていたりして、どうも安心感に欠けるのと、どのように動作するのか理解するのが面倒に感じて自分で作る事にしました。

幸いな事に手元に(いつ入手したのか覚えてませんが)ログイン型チップジャーの動作するフルパーミッション物があったので、それをベースにして改造するというながれで楽でした。
もともとがフルパーミッションだったので、特にライセンス条項の明記もなかったですが、たぶんBSD系なのかなぁと思い。こちらで弄ったソースも公開するという運びです。

主な変更点は
・ノートカードからdataserver経由で1行ずつ読み込む部分をノートカードの名称からダイレクトに取得するようにした
・配分が不正値のとき再処理ではなく強制的に最大値または最小値で置換するようにした
・タイマーの使い方を最大ログイン時間の判定用途ではなくオンライン確認間隔とした
・チップジャーの使用者がログインしているか、また、有効な距離内に居るかのチェックを追加した
・ほとんどのメッセージの日本語化
・IMを使う部分をRegionSayToで置き換え、ラグの発生を少なくした


設定値はノートカード記載から
ノートカードの名称そのものがパラメータとすることで
設定内容が他の人にも明確に可視となり
dataserverも使わない事から省エネです

設定値の内容は左から

金額1,金額2,金額3,金額4,グループチェックの要否,配分の割合


//LOGIN型のチップジャー for Momoiro

integer total;
float   percent;
string  tipjar_name;
string  tipjar_disp;
key     tipjar_key = NULL_KEY;
integer check_group = FALSE;



updateText(){
    string str;
    vector color = <1.0,1.0,1.0>;

    if( tipjar_key == NULL_KEY ){
        str = "\n";
    }else{
        str = tipjar_disp + " さんの Tip Jar\n";
        color = <0.0,1.0,0.0>;
    }

    if( total > 0 ){
        str+= (string)total + " donated so far.";
    }else{
        str+= "Empty";
    }
    
    if( tipjar_key == NULL_KEY && total == 0 ) str = "";

    llSetText(str, color, 1.0);
}


default{
    state_entry(){
        llRequestPermissions(llGetOwner(), PERMISSION_DEBIT );
    }

    on_rez(integer num){
        llResetScript();
    }

    run_time_permissions (integer perm){
        if(perm & PERMISSION_DEBIT){
            state wait_jar;
        }
    }
}

state wait_jar{
    on_rez(integer num){
        llResetScript();
    }
    state_entry(){
        llSetTimerEvent(0.0);

        string temp_ss = llGetInventoryName(INVENTORY_NOTECARD,0);

        if(temp_ss != ""){
            //設定内容の読み込みノートカード名から
            //書式は pay1, pay2 ,pay3, pay4 ,Groupの可否 ,支払い割合
            //pay金額に-1で当該ボタンは非表示
            list temp_list = llParseString2List (temp_ss, ["|",","], []);
            llSetPayPrice(llList2Integer(temp_list,0),[llList2Integer(temp_list,0),
                                                       llList2Integer(temp_list,1),
                                                       llList2Integer(temp_list,2),
                                                       llList2Integer(temp_list,3)]);
            temp_ss = llToLower(llStringTrim(llList2String(temp_list,4),STRING_TRIM));
            if(temp_ss == "group" || temp_ss == "true"){
                check_group = TRUE;
            }else{
                check_group = FALSE;
            }
            percent = llList2Integer(temp_list,5) / 100;
            if(percent > 1) percent = 1.0; //100%を越える設定の場合は強制的に100%にする
            if(percent < 0) percent = 0.0; //負数の割合の場合は強制的に0%にする
        }else{
            llSetPayPrice(PAY_DEFAULT,[]);
            check_group = FALSE;
            percent = 1.0;
        }


        if( tipjar_key != NULL_KEY ){
            llRegionSayTo(tipjar_key,0, "ログアウトしました。");
        }
        tipjar_key = NULL_KEY;
        tipjar_name = "";
        tipjar_disp = "";
        total = 0;
        updateText();

    }

    touch_start(integer count){
        integer success = FALSE;

        if( check_group ){
            if( llDetectedGroup(0) ) {
                success = TRUE;
            }else{
                llRegionSayTo(llDetectedKey(0),0, "現在グループモードがOnです。異なるグループでは利用できません。");
            }
        }else{
            success = TRUE;
        }

        if( success ){
            tipjar_key  = llDetectedKey(0);
            tipjar_name = llDetectedName(0);
            tipjar_disp = llGetDisplayName(tipjar_key);
            if(tipjar_disp == "") tipjar_disp = tipjar_name;
            total = 0;
            llRegionSayTo(tipjar_key,0, "ログインしました。");
            llRegionSayTo(tipjar_key,0, "チップの配分は " + (string)llRound((percent*100)) + "% を受け取れます。");
            state run_jar;
        }
    }

    money(key giver, integer amount) {
        //未ログイン時は配分無しでオーナーへ
        llSay(0, "☆。彡 "  + llGetDisplayName(giver) + " さんから " + (string)amount + "L$ いただきました♪ ありがとうございます!");
        total += amount;
        updateText();
    }
}

state run_jar{
    on_rez(integer num){
        llResetScript();
    }

    state_entry(){
        updateText();
        llSetTimerEvent(120.0);//存在チェック間隔
    }

    money(key giver, integer amount) {
        llSay(0, "☆。彡 "  + llGetDisplayName(giver) + " さんから " + (string)amount + "L$ いただきました♪ ありがとうございます!");
        total += amount;
        llGiveMoney(tipjar_key,(integer)(amount*percent));
        updateText();
    }

    touch_start(integer count) {
        if((llDetectedKey(0) == tipjar_key) ||
           (llDetectedKey(0) == llGetOwner()) )  {
            state wait_jar;
        }
    }

    timer(){
        //同一SIM内に居るか?
        if(llKey2Name(tipjar_key) != ""){
            //居る場合は距離を確認 (120m以内とする)
            if(llFloor(llVecDist(llList2Vector(llGetObjectDetails(tipjar_key,([OBJECT_POS])),0),llGetPos())) <= 120){
                return;
            }
        }
        llSetTimerEvent(0.0);
        llInstantMessage(tipjar_key, "近くに居ないため強制ログアウトします。");
        tipjar_key = NULL_KEY;
        state wait_jar;
    }

}


注記:<と>の文字がうまく書けなかったので2バイト文字化しています。コヒペする場合はお手数ですが置き換えてください。

Different logic FaceLight (using RLV and Projector function)

弁当が公式仕様になったのでアバター弄りやアイテム作成で忙しく過ごしている事でしょうが、私はマイペースに先のフェイスライトの記事で触れたプロジェクターランプへの換装を自分用のアイテムに反映していました。ライトの構造をプロジェクター仕様にするだけでは新しいとは言いたくないので(プロジェクターについては2011年から存在していたので)さらにRLV機能を使った新発想のフェイスライトを作ってみました。RLVと聞くとボンデージ系の何かの機能が付いていると思われるでしょうが、清く正しい() RLV利用法を示すということも含めてみましたw。



少し話しが昔話になりますがフェイスライトの自作は以前からやっていて、最初に公開したのは2008年の1月
このときの仕様は
・昼夜の2パータンでそれぞれに光量の上限値と下限値をもつ
・昼夜の2パータンでそれぞれに光の色を指定できる
・指定範囲の値で太陽または月の高さを元に光量を可変設定する
という内容でした。

暫くはこれで使っていたのですが次のような問題を抱えていました。
▲太陽または月の高さからでは昼夜は分かるけれど日の出か日の入りなのか分からない
▲太陽が真上の時(真昼)それなりに明るいが、真下の時(深夜)真っ暗なのではなく月の明かりがあって逆に明るい

そうこうしているウチにWindLightというものが導入されて、やたらと明るくなり(2008年の4月頃)
これでは太陽の東西位置から日の出/日の入りを判別するだけじゃパターン不足になると考えて
リアル時間の4時間でSLの1日という間での太陽の変化を「太陽の色の変化」として観測し、適応した補正色で補おうとか考えるようになりました。
太陽の色温度の観測(日の出編)
太陽の色温度の観測(日の入り編)
このとき既にRLVでのWindLight設定値を取得する機能があったのですが、殆どの人がRLVクライアントではなく(当時はオリジナルのRestrainedビュワー1つしか無かったので)環境もWindLight無効などが多くRLVで何かをするというのはありえませんでした。
光源で色を付けるというのを楽しんでみたりしていましたが、光が強すぎて描画が潰れてしまったりとか調整がとても面倒なものでした。
それでも太陽周期にあわせて補正をするという方式では陽が地平線より沈んでいても実は明るい日の出や日の入りに確実に対応が出来るというものでした。

しかしそれでも問題として
▲太陽や月に対して正面を向いている時と反対の時で顔に影がかかり光量の補正が合わない

これに対応すべく、「アバターが向いている方向と太陽の角度から補正量を加減する」ということをやろうとしたのですが、アバターの向きと顔の向きは必ずしも同じではないので棚上げとなりました。そして冷静に考えると、そんなにリアルタイムに補正して何になる?との自問自答で「リアルタイム補正は無駄でしかない」という結論に至ったのです。日の出や日の入りなどの環境変化のタイミングに遭遇した事があるでしょう。SLの中でのそれらは、僅か数十秒でしか発現せず、あっというまに日が沈む(陽が昇る)のです。それに昼間のほうが長いのだから端的に昼/夜の2パターンで充分だろうと・・・。

そういう考えで以降は、どんな状況でも的確に照すために光源の数と位置に拘り、3灯式で昼夜2パターンのフェイスライトに落ち着いたのです。(このライトはジャンクコーナーにあります)



そんな経歴がありましての今回、新しいロジックのフェイスライトは「環境光を直接に昼夜の判定材料にする」 という仕組みと、「光の照射についてプロジェクター方式を採用」というのが進化した部分です。

環境光とは何ぞや?
WindLight設定のアンビエントの現在値のことです。

左の画像の例ではかなり明るいけど夜なんです


こちらは同じ夜でも深夜設定

このように太陽の高さでは、どちらも夜なのに
周りの明るさが全然違うという状況ですが
アンビエントの現在値が違うので
こちらの方が暗い画面だと判断できます

なおWindLight設定の作り手によっては
環境光を下げずにガンマ値だけ下げて
夜間の演出を作っている場合もあり
環境光の数値だけでの判断は出来ません


つまり、どういうことをやろうとしているかは「クライアントで見えている現在の画面の状態のうち環境光の部分に着目して昼か夜かを判別する」という目論見です。太陽や星の明るさや色をどんなに変化させても(強くしても)環境の方で光を抑えると暗くなるので太陽と星は無視とします。またどちらから照らされているかは顔の向きが不定なので東の角度や太陽(または月)の現在位置も無視します。参照するのはアンビエントの赤、緑、青の各色と風景の現在ガンマ値です。

昼夜対応のフェイスライトを付けていて、環境設定を深夜にしたら顔だけ光ったままだった。という状況があると思いますが、これはクライアントの環境を変化させてもSIMの太陽位置はそのままだからということに起因しています。クライアントの描画状態から周囲の明るさを判別すれば、クライアント側で設定を変えていても、ただしくフェイスライトが追従するという事。現在ではWindLight設定を個別に変える事があたりまえになっているので、もはやSIMの太陽に依存するようなフェイスライトでは役に立たないでしょう。撮影用途での固定照明としてならばそれでもいいと思いますが常用するとなるとやはり2パターンぐらいは光量調整が機能して欲しいと思います。

そのクライアントのWindLight現在値を得るのにRLVの機能を使います。具体的にはgetenv_XXX系のコマンドを使うことで調べる事が出来ます。

ここまで記事を読んでくれたあなたへプレゼント。
実際に作成し、使用しているフェイスライトを放出します。
MH+ Labs からのX'masプレゼントとしますので、その日までは椅子の上に置いておきますね。

下品な箱だとか言わないように~
(誰も六角ボルトの頭を2つ重ねて箱っぽくしたとか思わないでしょうww)


取扱説明書は含めていないので以下に記します。

■仕様
・光源数:1灯式
・光源方式:プロジェクター式(白色円形)
・光量のみ昼/夜で2パターン変化
・指定した閾値で昼夜判断
 =環境光のR、G、Bの何れかが閾値(環境)以下の場合は夜と見なす
 =画面ガンマが閾値(ガンマ)未満の場合は夜と見なす
 =上記の何れでもない場合は昼の扱い
・ライトの更新はOn_Rez時、指定した秒数間隔、テレポートなどでのSIM変更検出時
・コントロールは取得しないのでスクリプト禁止区域ではライト更新動作停止とする


→照射範囲とか色、照射角度、強度 などプリム固定値は直接に編集する事で変えられます

→1灯式ですが、ライト設定時にLINK_SETで変更をかけるので、複数光源としたい場合はプリムを別途リンクして増やしてください。なお、その場合はルートプリムの色設定が他のプリムに全てコピーされます(子プリム毎に色や強度を変える事は出来ません)

→便宜上、プリムは編集可能、スクリプトは編集不可としていますが、プリムの編集でライトのOFFを行った場合、ライトの設定値およびプロジェクターとしている投影画像など全て光源に関する設定が破棄されてしまうのでチェックOFFしないよう注意してください

→初期状態では若干赤みが掛かった色が付けてあります



■使い方
アバターに装着(Attach)するだけ~
光量など設定値はプリムの概要説明(desc)の部分にて行います
装着位置は鼻推奨

■指定書式
全   最小値(夜);最大値(昼);更新間隔(秒);閾値(環境);閾値(ガンマ);WindLight名称;
(1)  最小値(夜);最大値(昼);更新間隔(秒);閾値(環境);閾値(ガンマ);
(2)  最小値(夜);最大値(昼);更新間隔(秒);
(3)  最小値(夜);最大値(昼);
(4)  固定値
(5)  なし


→全指定および(1)の場合はRLV必須(ただしRLV未検出の場合はRLVなしとして動作)

→(2)~(5)の場合はRLVは無効でも可能(この場合はSIM太陽の高さで昼夜判断します)

→最小値(夜)、最大値(昼)は1.0~0.0の間で指定(1.0が明るさ最大、0.0は真っ暗闇)

→更新間隔は10秒以上を最低限は確保推奨。(クライアントと通信します)

→ 閾値の環境とガンマはAND条件ではなくORです。どちらかで引っかかれば発動です

→設定するWindLight名についてはOn_Rez時のみ発動します
 (これは任意のWindLightを固定的に設定する機能が無いビュワーのためにあります。FireStormやSingularityのようなクライアント側で固定機能が付いている物だと弊害があるかも知れませんので、その場合は記述しないでください。なお、この設定で変更するのはRLV機能を使ってのWindLight変更設定となります)

→(4)での固定値1つだけの場合、タイマー動作は行わず常に指定値での動作となります

→(5)での全省略の場合、最小値=0.15、最大値=0.4、更新間隔=30秒 として扱います

→値の設定は概要説明(desc)の部分で行うので装着状態では変更が反映されません。
  値を設定変更する場合は、いったん取り外してインベントリー上で編集するか土地にREZして概要説明(desc)の部分を変更してください




RLVと聞くとスグにエロぃ事を考えてしまう方が居るのが嘆かわしいのですが、このように「クライアント側と何かをやりとりする」という使い方もあるので色眼鏡で見て欲しくないとの思いもあります。
また、RLV機能を有効にすると誰かに勝手に裸にされたり、勝手に行動をさせられたりするのではないかとの不安を抱いている方も少なくないでしょう。はっきり言います、それは間違った認識ですRLV機能を有効にしただけでは何も起こりませんので安心してください。

RLVで環境光を調べて、いい感じになったと思ったのはつかの間の自惚れで、新たな問題点としては影付きレンダリングであるのでアバターが日影に居るのか日に当たる位置に居るのか判別が付かない事です。ま、しかたないねーw






2016年でもフェイスライトは手放せない

MMORPGじゃ「照明」については、あぁ昼だね日が落ちて夜だねぇぐらいしかなく、天候などで見た目が少し変わるぐらいで殆ど意識する事はないと思いますがSecondLifeにおける「照明」についてはユーザー自身が設定を変える事も出来るので何かと工夫されているのではないでしょうか。もっとも身近な照明としては太陽と月の2つがあります。これはシステム側で提供しているので全ての人に影響を与えます。(その太陽と月ですらSIM持ちなら動かせますけどね) それ以外に光源としては6個までが最低限は使えるというのがSecondLifeの基本的な仕様です。光源として有効になるのは、ビュワー側で月と太陽以外で自分に最も近いものから扱われ、上限を超えた光源は処理されません。そんな光源の利用方法の1つとして「フェイスライト」があります。

注記:
(6個というのはOpenGLで提唱している最低限の使用可能な光源数=8個 - 太陽と月の数 で自由に使えるのは6個という意味合いです。また、最低限と表記しているのはアドバンスでない古いビュワー環境でも許容される数であって現行の仕様では光源数に制限はありません)


■フェイスライトとは何ぞや?
旧レンダラーで描画したとき、月と太陽しか扱わないためアバターの顔などに妙な影が出る現象を光を当てる事で影を極力飛ばしてしまおうという考えで、光源をアバターの顔の前などに付けます。そのアイテムをフェイスライトと呼びます。体全体を照射するアイテムではボディライトとか別称があるものもあります。


旧レンダラー
(Advanced Lighting Model 無効状態)

フェイスライト 無し

環境は Midday を選択

アバターはクラシックアバター(非MESH)

このように頬が出張ってボコボコ感が目立ちます

アバターモデルはテスト用に使っている2号さん


旧レンダラー
(Advanced Lighting Model 無効状態)

フェイスライト 有り(3灯白色)

環境は Midday を選択

アバターはクラシックアバター(非MESH)

細かな部分で凹凸はあるものの光で飛ばしてすっきりした見た目



新レンダラー
(Advanced Lighting Model 有効状態)

フェイスライト 無し

環境は Midday を選択

アバターはクラシックアバター(非MESH)

環境光を取り入れ自然な影が掛かるのでとても落ち着きがあって、ふんわりしてますね


新レンダラー
(Advanced Lighting Model 有効状態)

フェイスライト 有り(3灯白色)

環境は Midday を選択

アバターはクラシックアバター(非MESH)

顔がはっきり見えるので好まれる方も居れば不自然だとして好まない方と意見が分かれそうです



さらっと4つの画像で示しましたが、これがSecondLifeの遷移でもあります。

旧レンダラーは仕様的にはOpenGL2.0の内容で、使える光源も8個迄(太陽と月を含む)となっています。多くのSecondLifeの解説で任意の光源数が上限6個と記されているのは、このためです。

新レンダラー(Deferred rendering)は仕様的にはOpenGL3.0以上を要求します。使える光源数はビュワーの環境次第で制限無しという内容なので一部のビデオカードでは対応しなかったりします。

いつ頃から新レンダラーが実装されたかは公式ビュワーのV2版でSL Viewer v2.7.1 (232828) がリリースされた2011年6月14日まで遡ります。いわゆる「影付きレンダリング」が実装された頃です。実装当初はよほどハイエンドなPCで無いかぎりは影付きで常用なんてとんでもない話しでした。これによりSecondLifeは廃PCでないと楽しめないという印象を与えました。


いまではPC環境が進化して殆どがAdvanced Lighting Modelを有効にして常用している人が普通であって、あえて旧レンダラーで使っている人は居ないでしょう・・・


■フェイスライトなんて不要ジャンw
そうなんです、Advanced Lighting Modelの機能でWindLightの設定を適切に行う事で、全く同じ古いアバターでもフェイスライトなんて付けなくてもいいんですよね~w

じゃあ何故フェイスライトなのか。
私が推奨する理由は「ムードランプ」としての効用です。
すなわち白色ではなく、太陽光な色や、暖色などをライトとしてあてることでスキン+タトゥーの組合せやスキン+グロス+反射の効果といったMESHボディの特権的な機能、それらの規定値だけでは得られない微妙な変化が照明をあてることで得られます。同じボディで同じスキンなのに何か違う・・・。そこに拘ってみたいのです。

先の 新レンダラー ALM有 フェイスライト有
ライトの色を白色から、ややピンク色にした物です。
色は(R255, G200, B255)を指定

黄色っぽい肌がほんのり赤みが出る感じですね


こちらは、やや青みがかった色を付けました
色は(R200, G200, B255)を指定

白人っぽくなったかな?

ほかにもWindLightの設定値によっては顔に凹凸が目立つなどの理由で今でもフェイスライトを常用している人も居る事でしょう。けれども多数の人がもはやフェイスライトは古いアイテムであり無用な物だと考えられていますが、このようにちょっと色を付けることで差をつけることに使えるのです。


■フェイスライトは光害だ~
フェイスライトは光源なのですから少なからず周辺に影響を与えてしまいます。イカ釣り漁船のような1人で全ての光源を消費してしまうような多すぎるライトや、照明範囲がやたらと広大な広すぎるライト、そして真昼のような明るさの眩しすぎるライトについては光害と呼ばれ嫌われます。そんな歩く太陽のような方は見かけなくなりましたが、どんなに控えめにしても電球と変わりないですからね。

もはや歩く電灯
深夜設定なのにこの明るさ lol

眩しすぎ+広すぎの 例です


それでもこのフェイスライトは
かつてLAQという高名なスキン屋さんで
配布されていた物だったりします
ある意味記念物ですね

照射範囲が広すぎですw

フェイスライトを付けていて
何かに近寄ったとき
それが自分のライトに照らされて
明るくなってしまった・・・
なんていう場面を経験した事があるでしょう

対象が建物とか静物なら気にしなければいいのですが
それが他の人のアバターであった場合
ライトがあたってしまって
妙な感じになってしまったり
気になってしまいます


その原因はこの光源が
旧来からのポイントライトだから
全方向360度に向けて
光を放つことにあります

どんなに範囲を小さくしても
ポイントライトでは
照射する必要のない部分まで
照らしてしまう事は避けられません

■プロジェクターで照射範囲を限定する
Advanced Lighting Modelの機能で「プロジェクター」を設定する事で上記画像のようなスポットライトのような効果を与え、結果として照明の照射範囲を限定する事が出来ます。この機能をフェイスライトに応用した物を新型フェイスライトと呼ぶ人も居ますが、かつてのフェイスライト全盛の時期のように全ての人に必要というアイテムではないのでアバター用プロジェクターライトとか効果用ライトと呼んだ方がいいかも知れませんね。

そもそもプロジェクターですから、本来は画像などを光として物体に対して照射する機能です。

照射する角度は任意に変えられますが少なくともポイントライトとの違いは、どんなに広くしても光源より後ろ側には光は無い事です。


詳しい設定についてはLindenのLighting and shadows解説が詳細です(英文ですが・・・)

このプロジェクターをフェイスライトとして使用するにあたり気付いた点をいくつか上げると

・プリムの形式は無関係でプリムがボックスであってもシリンダーであっても同じだった
・黒地に白丸とすると一見では丸く照射されているように見えるが黒い部分は実際には黒色が投影される事になるのでアバターの顔など白っぽい物だと黒い部分で暗くなる気がする
・透明をプロジェクターに貼りつけると、まったく光が出なくなる(おそらく丸く照射するには透明背景に白丸の画像が最適)
・プロジェクターのプリムの面も照射対象になってしまう。このため何かテクスチャが貼ってあるプリムをプロジェクターとする場合、目立つ場所だとチラつきが厄介
・プロジェクターの設定値(画像も含めて)は、スクリプトから参照/更新する機能が無い



理由は分からないけれど、プリムのサイズを変化させると何故だか照射範囲にも影響がある

各色の箱サイズ
緑:0.5 x 0.5 x 0.5
赤:0.5 x 0.2 x 0.5
黒:0.5 x 0.5 x 0.2
橙:0.2 x 0.5 x 0.5

このことから縦長、あるいは横長に照射したい場合、貼りつけるプロジェクター画像をスリットのような形状にしなくてもプリムの形によって実現できるということが分かる。姿見のような全身照射するようなものも可能でしょう。プロジェクターの設定値をスクリプトでは変える事は出来なくともプリムのサイズを変える事で変化が得られるのであれば、旧来のスタジオライトやダンスステージの演出効果的に使う事にも応用できそう。

■Do it your self
そんなところで、今でもフェイスライトを使っている人に向け、「プロジェクターランプのススメ」とします。自作するきっかけになればいいかな。ビュワーの環境がそれぞれ違うし、個人の好みもそれぞれ違うから、これがBESTだ!とか、この設定が鉄板だ!というのは無いでしょう。ましてやスキンやシェイプもみんな違う世界ですからね。

もう連打ゲーはやらないのでTAFを元に戻したら調子いいぞ

古くからWindowsのPCでMMORPGなどをプレイしている人だとネットワークの設定で「TcpAckFrequency (TAF)」というのを聞いた事があるでしょう。そして弄ってある人も少なくないのではないかな。ナンダソレハ?という聞いた事がない人はMicrosoftの概要説明が詳細です。

私のPCも TcpAckFrequency = 1 な設定にしてあって、今まで特に困った事もなく弄ってある事すら忘れていたのですが今更ながら通信先相手の反応が遅い(LEVEL3 NetのArizona にあるSecondLifeのSIMサーバー群です)状況で、もしかしたらこの設定なのかとデフォルト値の=2にしたら乗り物移動でのSIM越で落ちてしまう事が発生しにくくなりました(あくまでも私のPC環境での感触です)

高速・大容量なダウンロード向けに調整している環境だと逆にTcpAckFrequencyは、もっと大きい値を設定済みかも知れませんね。特に古くからのPC環境を継続して使っている人は忘れてしまっていることでしょう。

そもそも連打する事が有効な場面などあるのか?という疑問があると思いますが、オンラインFPSゲームのように厳密に各人のPING値や入力頻度を精査する機能が無い普通のMMORPGでは今では殆どのゲームでアイテムの使用間隔ディレイやスキルの使用間隔ディレイがあたりまえのように付帯していますが古いゲームではそういうディレイという考えがないものもあったのです。過去にプレイしたタイトルで顕著だったのはRO(ラグナロク・オンライン)というMMORPGがそういうタイプでした。ゲーム中で回復アイテムの使用ディレイが大容量POTには使用クールタイムが付いていたのですが、小容量の回復アイテムにはクールタイムが無かった事から「小容量の回復アイテムを連打する」という状況が自然と生まれ、小容量の回復アイテムであるニンジンやジャガイモを数百個も持ち歩く戦士様という世界でした。さらには効率よく連打する目的で各種連打系のツール類も作られ、その後のMMORPG界では外部ツールの使用有無をチェックするような流れに変わっていったのです。(RO専用では自動芋とかあったよねw)

接続先サーバーが近くにあって反応が良くTcpAckFrequencyの設定が効果がある世界ならともかく、少なくともSecondLifeでは必要がなく寧ろSIM間接続などに悪影響が出てしまうので設定値を弄っているSL住民さんは元に戻しましょう。

みあたらないから作った7連ピクチャーフレーム

シンプルに横にずらっと並んだレイアウトのフォトフレームをマーケットプレイスで探したのですがSecondLifeで設定可能な面数(マテリアル)の上限8面を有効に使った7枚パネルでストレート並びという単純な物が見つからなかったので、さらっと作った物です。

張り付ける画像が主体で枠はどうでもよく、出来るかぎり単純で描画負荷のない物という考えで単なる直線ですw 
いや、それでいい。 よかったらどうぞ~
2プリムをリンクして1LIで14パネルの例です(単体では0.5LI)
初期の状態で0.5LI換算のギリギリ上限の大きさにしているので
単純な2プリムリンクならば、もう少し大きくしても1LIに収まると思います
四捨五入なので1.5 LIまでは1LIですからね~
そのままの比率を維持して縮小した場合、
最小サイズは X=1.11 Y=0.01 Z=0.15 です。
(手前の小さい物がそれです)
奥行きというか厚さ(Y軸)を弄れば
もっと小さくすることもできます。
逆に元より大きく拡大した場合は
その分、LI数を食いますので大きさ見合いで
調整してください


Popular Posts of the Month