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 が一定なのか変化するのか、っていうイメージっす。