4:2:4のイメージっす

ポリゴン数が多すぎる場合にはCOLLADAが良いかもしれないっす。
不要な部分を取り除くために一旦、HTMLで出してるんっすけど、
XML形式になってるので、コメントアウトが使えるんっすよね。
ちょっと考えてみるっす。
どうもぺんぎんっす( ◎v◎ )


設計:実装:テストにかかる時間の比率が4:2:4になってたっす。
ちょっと作って動かす、ちょっと作って動かす…とやってるので、
4:4:2くらいの感覚なんっすけどね。
自分が「とりあえず完成」って言ってる場合には、
全体の8割くらいが出来た状態と思ってくださいっす。

もうちょっと細分化すると、
大雑把にどんなものを作るのかを決めるのに全体の10%、
機能面とかを煮詰めるのに全体の15%、
外側をどうするのかに5%、
どう作っていくのかの作戦を決めるのに10%、
これで40%っす。
設計が終わったら実装にかかるっす。これが全体の20%っす。
残りはテストっす。
ちょっと作ったら動かしてみるのに15%、
部品をくっつけて動かしてみるのに5%、
全体を通しで動かしてみて、評価するのに20%っす。


SLの世界だと設計ナシでいきなり書き始める人も多いと思うので
まったく参考にならない数字だとは思うんっすけどね。

時間当たりのテキスト出力量っす

llGetMassMKSっていう関数が来てたっす。
体積に比重を掛けた値を返すっす。
物理周りはそろそろやらないとっす。
どうもぺんぎんっす( ◎v◎ )


SimToTextでは1回のOwnerSayは100バイト程度のテキストで、
Sleepなしで一気に必要ポリゴン数分出してるっす。
このことがパケットロスを引き起こしちゃうっす。

Sleepを0.1秒ずつかけて毎秒1KB程度の出力にしたところ、
影響が感じられなくなったっす。
ギリギリを攻めるのか、それとも余裕を持たせるのか、
悩ましいところではあるっす。
良い感じのところを探らないといけないっすね。


毎秒10ポリゴン分の出力になるので、13万ポリゴンでは3時間半。
出力し終わると変な達成感があるかもっす。

SimToTextの利用制限っす

自分は制作じゃなくて製作してるっす。
クリエーターじゃなくてメーカーっすね。
何か作ってることには変わりないんっすけどね。
どうもぺんぎんっす( ◎v◎ )


SimToTextはSIM形状データの二次的著作物にあたるっす。
じゃあ、原著作者は誰？となるんっすけど、場合によるっす。
SIMオーナーかもしれないし、土地の所有者かもしれないっす。
土地がグループでの所有の場合もあるっすね。
とにかく権利関係がややこしいことになってるっす。

誰が作ったか分からないので、スクリプトから
チェックして弾くことができないっす。
せいぜい許諾を取ることを促すメッセージを流すくらいっす。
でも、これじゃあ対策として不十分っすよね。

llGetParcelDetailsのPARCEL_DETAIL_OWNERフラグで
返ってくるkeyと一致しないと使えないとやってしまうと、
ほとんどの人が使えない状況になるっす。
正式に許諾を得たのに使えないということになっちゃうっすね。


今のところは
・他の住人に許諾を取ることを促すメッセージを出す
・出力したデータを利用できる範囲を制限する
という対応にしようと考えてるっす。
イマイチなんっすけどね。

SimToTextのGUIっす

SIMの地形データをテキストとして出力するやつっす。
PrimToTextと併せて「Toシリーズ」っす。
「Forシリーズ」も今後作って行くんっすけどね。
どうもぺんぎんっす( ◎v◎ )


操作周りは全然作ってないっす。
SimToTextの詳細度は0から5の6段階なので、
全部パイメニューにしちゃうのはダサいと感じるわけっす。
収まるんっすけど、しっくり来ないっす。

最有力はパイメニューの隣に0から5の数字を描いたボタンを
設置する併用型っす。
プリム数は多くなるっすけど、一度に2つを見て、操作できるっす。
↑↓ボタンの方法は表示のさせ方に凝らないといけないので、
今回は採用しないっす。
モノによってはプリム数のメリットが無くなっちゃうっすからね。


オブジェクトの色・カタチも考えないとっすね。

SIM画像のURLっす

13万ポリゴンのSIM地形は近いうちにやってみるっす。
コピペは何回かに分けないといけないかもしれないっすね。
どうもぺんぎんっす( ◎v◎ )


SIMの画像はSIMの座標が分かっていれば取れるっす。
世界地図を眺めていても分からないかもしれないっすけどね。
Map APIのページにもサンプルスクリプトが載ってるんっすけど、
使いやすくURLを返す関数にしてみたっす。

string GetSimImageURL()
{
    string url = "http://map.secondlife.com/";
    vector pos = llGetRegionCorner();
    string x = (string)((integer)(pos.x / 256.0));
    string y = (string)((integer)(pos.y / 256.0));
    url += "map-1-" + x + "-" + y + "-objects.jpg";
    return url;
}

あとはSayさせるなりしてくださいっす。


SL自体の規約は読んだと思うっすけど、
APIのToSまで読んでる人は少ないんじゃないかと思うっす。
URLを貼り付けておくので、見ておくと良いっすよ。
http://wiki.secondlife.com/wiki/Linden_Lab_Official:API_Terms_of_Use

SIM画像の取得っす

いろいろあって、久しぶりの投稿っす。
ネタが無くなったわけじゃないんっすよ。
どうもぺんぎんっす( ◎v◎ )


SIMの形状(起伏だけっすけどね)を出力されてみたっす。
となると、テクスチャも貼り付けたくなるっすよね。
wikiの方で調べてみると、Map APIが用意されてたっす。
http://wiki.secondlife.com/wiki/Linden_Lab_Official:Map_API_Introduction

画像だけが欲しいので、単に画像のURLにアクセスすれば良いっす。
ご丁寧にLSLから取得するものも書いてくれてるっす。
まぁ、stringをreturnしたほうが使いやすいっすけどね。


PrimToTextもSimToTextも作らないといけないっす。
これからもかなり忙しくなるっすね。

256プリムからのlistenっす(3)

形状データのテキストサイズ削減はうまくいきそうっす。
200バイト程度まで減らせそうで、目標はクリアっす。
これも後で書くっすね。
どうもぺんぎんっす( ◎v◎ )


そもそも論として、256のsayはlistenできないっす。
待ち行列には64個までしか入らないという制約のためっす。
too muchなんたらーっていうエラーを吐いて、
溢れたsayは捨てられることになるっす。

でも256プリムからのsayを受けたいわけっす。
256プリムをリンクして1オブジェクトになっていると仮定して、
リンク番号×0.05秒ずつsayしているのが今の方法っす。
これはダメっすよね。
逆のパターン、1プリムオブジェクトが256個あった場合、
全然機能しなくなるっす。

プリムのkeyを種とするハッシュ関数を作って、
ハッシュ値からsayするタイミングを決定させるっていうのが
より確実そうなので、ちょっと組んでみるっす。



やることがたくさんあるので、計算部分が順調に遅れてるっす…

256プリムからのlistenっす(2)

LSLCONに出す作品群の調整をしてるっす。
PrimToTextはテキストとしてSayさせられないので、
ノートカードに出力結果をコピペして配布するっす。
大量のチャットログが流れるっすからね。
どうもぺんぎんっす( ◎v◎ )


今回は文字列の処理っす。
プリムの形状データをコンパクトにして送りたいわけっす。

圧縮・解凍じゃなくて、不要な部分を取り除いただけっす。
300バイトを250バイト以下に持っていければ書くっすけどね。
考えてるアルゴリズムはあるんっすけど、
圧縮率がどうなるか計算してみないと分からないっす。

「不要な部分」というのは小数点以下の末尾0と、
半角スペースの2種類っす。
vectorやrotationの中にも半角スペースがあったりと、
この2種類を除去するだけで10バイト単位でごっそり減るっす。
これでもまだダメなんっすけどね・・・


ヒープ枯渇でスクリプトが死んじゃったら、
通常のエラーメッセージの他に、何かもう一言、
出力しようと思うっす。

256プリムからのlistenっす(1)

PrimToTextの進行もそろそろ書かないとっすね。
もう12月っすか…
どうもぺんぎんっす( ◎v◎ )


計算もやらないといけないっすけど、
まずはSay/listenの部分を強化したっす。
送信テキストと、データの格納部分をパワーアップしたっす。

256プリムは余裕じゃないかと思われる方もいると思うっす。
でも考えてみると64KBしか使えないわけっすから、
1プリムあたり256Bytes未満にしないといけないんっすよね。

形状データはllGetPrimitiveParamsの値をCSVで送ってるっす。
つまりはテキスト(string型)なんっすよね。
なので、文字数+αがそのまま消費メモリ量になるっす。

考えるべきは一番文字数が多くなるときっす。
これはトーラス、チューブ、リングのとき最も多くなるっす。
integer 2
float 4
vector 8
rotation 1
これだけ入ってるっす。
floatは小数部が必ず6桁表示されることを考えると、
1(整数部)+1(小数点)+6(小数部)の8文字が最低でもあるっす。
vectorはfloatが3つと、"<"・">"それと内部区切りの", "があるので
30文字が少なくともあるっす。
もうすでに256文字はオーバーしちゃってるっすね。
このままじゃダメなわけっす。

で、やったのが
・送信テキストの無駄を省く
・できるだけ多く格納できるようなスクリプトを1本作る


具体的な話は長くなりそうなので明日にするっす

さくさくと新関数6つを見るっす

いつの間にか増えてた新関数の話っす。
まだメイングリッドに来てないのもあるので注意っす。
そこら辺はLSL Portalを見てくださいっす。
どうもぺんぎんっす( ◎v◎ )


6つあるので、ざざーっと見て行くっす。

http://wiki.secondlife.com/wiki/LlSetContentType
llSetContentTypeはhttp_requestイベントで受け取るメディアタイプを
text/plainとtext/htmlから選択できるようにするっす。
これ、使いようによっては革命が起きるんじゃないっすか？

http://wiki.secondlife.com/wiki/LlSetVelocity
http://wiki.secondlife.com/wiki/LlSetAngularVelocity
llSetVelocity/llSetAngularVelocityは物理オブジェクトに
等速直線運動/等加速度運動をさせるっす。
動き始めはllSetForceで、ある程度まで加速したらllSetVelocityで
等速に切り替えるとそれっぽい動きができるかもっす。

http://wiki.secondlife.com/wiki/LlSetKeyframedMotion
llSetKeyframedMotionは非物理オブジェクトの動きを
まとめて記述できるっす。この関数は昨日も書いたっすね。
llSetLinkPrimitiveParamsFastを何回も呼び出さなくても済むっす。
ただ、動きについてだけなので、色が変わったり、
形状が変わる場合には使えないっすね。

http://wiki.secondlife.com/wiki/LlSetMemoryLimit
llSetMemoryLimitは使用するメモリ量に自ら制限をかけられるっす。
なんというか「競技向き」っすよね。
通常は使う必要が無いんっすけど、アスリートだけが使う感じっす。
設定した制限値を超えたらDEBUG_CHUNNELでShoutされちゃうんっすかね？

http://wiki.secondlife.com/wiki/LlManageEstateAccess
llManageEstateAccessは土地へのアクセス権限をいじれるっす。
ライブイベントなんかだと、外からは見えるけど聞こえない、
聞きたければ「入場料」を払え！みたいなことが……。
Payが扱いやすくなったっすからね。


自分の中で注目度が高い順番に並べたっす。
とは言え、使い方次第っすけどね。
ちなみに、今年追加された関数の中では、
llRegionSayToが一番の衝撃だったっす。
皆さんはどうっすかね？

llSetKeyframedMotionっす

テンプレートをいじったので、次回からフォントが違うっす。

ちょっとは見やすくなるんじゃないっすかね?

どうもぺんぎんっす( ◎v◎ )

しばらくブログを書かないうちに、新関数がいくつか追加されたっす。

明日まとめて書くっすね。

今回はその新関数の1つ、llSetKeyFramedMotionの話っす。

llSetKeyFramedMotionについてはLSL Portalをどうぞっす。

http://wiki.secondlife.com/wiki/LlSetKeyframedMotion

非物理オブジェクトの動きをまとめて記述できる関数っす。

llSetLinkPrimitiveParamsFastを何回も呼び出さなくて済むっす。

色とかカタチが変わる場合には使えないっすけどね。

動きをループさせたりするオプションも付いてるっすよ。

この関数のwikiを見て、なるほどと思ったのが、

[座標]・[姿勢]・[秒数]の3つで「動き」というものが表現されるという点っす。

当たり前と言えば当たり前なんっすけどね。

一般的な動きの表現方法は、1コマあたりの再生時間を決めておいて、

そのコマでの座標・姿勢を記述していく方法っす。

1秒あたり何コマっていう「FPS(フレーム・パー・セカンド)」というのは

聞いたことないっすかね?

この方法だと、止まっているときは同じ数値が繰り返し出てきたり、

再生時間に対してデータ量が比例して増加したりと、ムダがあるっす。

[座標]・[姿勢]・[秒数]の3つで書く表現方法だと、中間の状態は

計算してやらないと出ないという問題があるっすけどね。

時間とメモリのトレードオフの関係にあるわけっす。

SLはメモリの制約が厳しいので、時間を犠牲にメモリの得を取った方が

良いケースが多いっす。

llSetKeyframedMotion以外に使える記述方法かもしれないので、

覚えておくと良いかもっすね。

d/dt が一定なのか変化するのか、っていうイメージっす。

HUD型汎用リモコンっす

PrimToTextは来週あたりに機能限定版を出すっす。

UIをもうちょっといじるっす。

どうもぺんぎんっす( ◎v◎ )

LSLCON向けのネタっす。

アイデアだけ先に出しちゃうっす。

作る時間があるか微妙なもんっすからね。

入力用HUDを付け替えるのが面倒なんっすよね。

なので、全部1つにまとめられないかと思ったわけっす。

HUDとオブジェクトに必要な機能はそれぞれ2つっす。

HUD

　1.送信に使うチャンネルを設定する。

　2.アバターが入力した情報を送信する。

オブジェクト

　1.受信に使うチャンネルを指定する

　2.HUDからメッセージを受け取る

簡単な話、「チャンネル」と「メッセージ」を取り決めれば良いっす。

チャンネルに関してはHUDに入力機能を持たせれば良いだけなので、

問題になるのはメッセージの方っすかね。

ざっと並べてみると

　・数値(0-9、小数点、+/-)

　・方向(8方向+真ん中)

　・Yes/No

　・Prev/Next

最低限これだけあれば良いんっすかね。

あとはこれを規格化すれば良いっす。

メッセージを受けるlistenイベントを作っておけば使い回せるっす。

オブジェクトを作る側にもメリットはあるっすね。

流行ってくれないとダメなんっすけどね。

llCastRayのページが更新されてたっす

PrimToTextの効果音を作ってたっす。

あっても無くても、さほど変わらないんっすけどね。

要望があったので、一応作ったっす。

どうもぺんぎんっす( ◎v◎ )

http://wiki.secondlife.com/wiki/LlCastRay

このページっす。

日本語のページはまだできてないっすね。

始点と終点を指定して、その間に引っかかったモノを返すっす。

イメージは「赤外線センサー」っすかね。

スパイものでお馴染みのやつっす。

この関数はより強力で、貫通するっす。

しかも、「誰が」「どこで」引っかかったのかまでも分かっちゃうっす。

llSensorとの大きな違いは、結果がlistとして返ってくるところっす。

イベント間を行き来しないので、組み立てしやすくなるかもっす。

あと、最大で256個まで引っかけれるのも大きいっすね。

sensorイベントに上がって来る最大数より、ずっと多いっす。

接触のcollision、投げ網のsensor、そして赤外線のllCastRay。

お店にある自動ドアに変化が出てくるっすかね？

ボックス大工事開始っす

大きな山場を迎えたっす。

ここを乗り切れば、他のは問題無くできるはずっす。

正念場っすね。

どうもぺんぎんっす( ◎v◎ )

ボックスのパスカットを作ってたところ、テキストが64KBになったっす。

1,450行くらいあるっすから、そろそろとは思ってたんっすけどね。

このままでは書き足せない状態なので、大工事を行うっす。

まずは関数化っす。

四角形ABCDの頂点はfor文の中で計算してるので、

A = f(i, j)

B = f(i, j+1)

C = f(i+1, j+1)

D = f(i+1, j)

と表す事が出来て、関数fを作ってやればテキスト量を減らせるっす。

ただ、プリムのサイズや姿勢の情報もfに持って行かないといけないっす。

引数として渡しても良いんっすけど、A・B・C・Dの4つで同じことを

書くことになっちゃうっす。

ここはプリムの形状データをグローバル変数に格納しておくことにするっす。

関数fからグローバル変数を参照してもらうっす。

この作戦でテキスト量が3割くらい減ると見てるっす。

そのために加筆・修正・削除しないといけないのは全体の6割っす。

軽いハックで済めば良いんっすけど、これ以上は犠牲も大きいっすね。

ボックスの完成が近いっす

この週末でケリを付けるっす。

ここからスピードアップしてやるっす。

どうもぺんぎんっす( ◎v◎ )

ボックスの中空で残っていた「三角形」が書けたっす。

あとはパスカットでボックスは完成っす。

次は球を作る予定っす。

ボックスと球は使用頻度が高いと思うので、かなり便利になるはずっす。

あ、あと、rotationの講座を準備し始めたっす。

算数をできるだけ使わないようにはしたいっすね。

具体的には「軸」と「回転角」にフォーカスするっす。

vectorとは違う、行列の感じも伝えられたらと考えてるっす。

いつやるか、どこでやるかは全くの未定っす。

準備だけ始めたというところっす。

期待せずに待ってると良いっすよ。

0.25 alpha → 0.30 alphaの更新

・ボックス　1,382行(0.25 alphaは931行 +451行)

コンフィグメニュー追加っす

外側はこれでほぼ出来上がったっす。

あとは内側、算数の部分っす。

メモリは足りるみたいっす。

どうもぺんぎんっす( ◎v◎ )

設定を変更できるようになったっす。

変更できるのは「出力形式」「詳細度」「出力スピード」「レイヤー」

の4点っす。

出力スピードはスリープを使って調整してるっす。

チャットの順番が前後したり、飛んだりしないようにもできたり

するんじゃないっすかね？たぶん・・・

コンフィグもパイメニューっす。

現在の設定値を示すために、半透明なプリムを使ってるっす。

設定を変えるたびにプリムが動くっす。

OwnerSayでも出るので不要だったかもしれないっすけど、

第三者から見て分かるようにしたかったもんっすから、

プリムによる表示も付けたっす。

というわけで、算数がんばるっす。

現在の行数

・リング　377行

・スフィア　272行

・シリンダー　323行

・プリズム　461行

・トーラス　304行

・チューブ　525行

・ボックス　931行

・メインの制御スクリプト　1,216行

・サブの制御スクリプト　32行

・設定の保存と再起動スクリプト　149行

・プリム側　63行

バージョンα0.18の更新点っす

「パイメニューでやる」と方針は決まったっす。

(x,y)を(r,θ)で表すだけっすから、難しいところもないっす。

テクスチャを作らないといけないのは一緒っすからね。

どうもぺんぎんっす( ◎v◎ )

前に配布したバージョンはα0.07っす。

そこからの更新点をまとめてみるっす。

1.ボックスにデフォルト(四角形)形状の中空設定が可能に

2.ボックスで一部の表裏が逆になるバグを修正

3.本体にテクスチャを貼ってみた

4.SIMの<0,0,0>地点基準から本体のルートプリム基準に変更

こんなところっすかね。

主にボックスをいじったっす。

ついでに各スクリプトの現時点での行数も載せておくっす。

コメントも含むっすから全く参考にならない値っすけどね。

メモリ消費量の参考程度にはなるんじゃないっすか？

llGetFreeMemoryの値を取るだけのためにログインするのが

面倒なだけなんっすけどね。

ちなみに一番行数の多いボックスでも残り39KB残ってるっすよ。

まあ、どの形状の座標が計算しにくいかは分かるっすかね。

・リング　363行

・スフィア　258行

・シリンダー　309行

・プリズム　447行

・トーラス　290行

・チューブ　511行

・ボックス　843行

・メインの制御スクリプト　711行

・サブの制御スクリプト　32行

・設定の保存と再起動スクリプト　100行

・プリム側　63行

思ったより大作になりそうな予感っす…

全然進まないっす

RLが忙しく、時間が全然取れなかったっす。

山は越えたので、ちょっとずつペースを戻して行くっす。

どうもぺんぎんっす( ◎v◎ )

そろそろコンフィグで変更できる項目を決めたいところっす。

追加・変更の要望があれば自分に言ってくださいっす。

現在出てきてるのは

　・出力形式

　・プリムをレイヤーごとに分けて出力するかどうか

　・出力スピード

この3つっす。

パイメニューには8項目まで入れられそうなので、問題無いっすね。

肝心の計算部分はボックスのデフォルト穴形状で中空が出来たっす。

サークルに取りかかってるところっす。

座標はカンタンに出るんっすけど、どう結ぶかが難しくて進まないっす。

for文の中身が許せないほどに汚くなっちゃうんっすよねぇ・・・

アルゴリズムそのものの見直しが必要っす。

明日、バージョンアップによる変更点をまとめるっす。

土日はお絵描きっすかね？

→にある予定リストの入手法っす

サーバーリリース情報について聞かれる事が多くなったっす。

右のGoogleカレンダーのやつっす。

ソラマメで利用しても良いっすね。

どうもぺんぎんっす( ◎v◎ )

Googleカレンダーのことなので、アカウントが必要っす。

アバター名でアカウントを持っていると何かと便利っすよ。

このブログの右、予定リストの下に[+Googleカレンダー]の

ボタンがあると思うっす。

Second Life Grid Status Reports

http://status.secondlifegrid.net/

にもあるので、どっちでも良いっすよ。

ボタンを押すと、Googleカレンダーが開くっす。

左下の「他のカレンダー」に加わってるっす。

[▽]を押して、カレンダー設定を選んでくださいっす。

後は[色やサイズなどをカスタマイズします]っていうのをクリックして

好きなように変えればOKっす。

インラインフレームのタグが自動生成されるっす。

事前にメンテナンスやアップデートがあることが分かれば、

不運な出来事に遭遇する可能性も減るっす。

確認してからログインするクセを付けると良いかもっすね。

三角形と四角形っす

もうPrimToTextのままで行くっす。

良い名前も浮かばないっすからね。

どうもぺんぎんっす( ◎v◎ )

ボックスに穴形状:三角形で中空を入れた場合、

プリズムに穴形状:正方形で中空を入れた場合、

頂点の結び方が悩ましいっす。

三角形と四角形になるっすからね。

ボックスに三角形の穴をあける場合を考えるとき、

内側の三角形はパスカットをイメージすると良いっす。

頂点の位置はボックスに1/3(≒0.333)、2/3(≒0.667)の

パスカットを設定したときのボックスの断面上にあるっす。

つまりこういうことっす。

説明しやすいように名前も付けたっす。

補助線がいっぱい出てるっすけど、それらは垂直二等分線っす。

特に三角形の各辺の垂直二等分線と四角形の辺との交点は

黒丸を付けたっす。FGの垂直二等分線はAを通るので

辺ではないっすけどね。

上の図から何が分かるかと言うと、

「E、F、Gの各頂点から一番近い頂点はA、B、C、Dのうちどれ？」

っていうのが分かるっす。

垂直二等分線を引いたのはこのためっす。

EはAが一番近く、

FはBが一番近く、

GはDが一番近い、

となるっす。

これからやることは、穴あき正方形を三角形に区切ることっす。

いわゆる三角ポリゴンってやつっす。

まずは近いもの、AE、BF、DGを結ぶっす。

Cは余ったので、CF、CGと結んでおくっす。

残りは四角形AEGDと四角形ABFEの部分っす。

四角形AEGDは「AGとDE、短いのはどっち？」で、短い方を選択するっす。

四角形ABFEも同様に「AFとBE、短いのはどっち？」をやるっす。

自分は図を書いてCADで計測するズルをしたんっすけど、

良い子は頑張って計算してくださいっす。

図のような7つの三角形になるっす。

PrimToTextでもこんな風に分割してやるっすよ。