極北国ぺんぎん

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

2011-12-19T22:55:00.002+09:00

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

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

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

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

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

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

2011-12-17T23:30:00.002+09:00

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

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

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

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

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

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

2011-12-15T23:41:00.002+09:00

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つを見るっす

2011-12-14T23:49:00.003+09:00

いつの間にか増えてた新関数の話っす。
まだメイングリッドに来てないのもあるので注意っす。
そこら辺は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っす

2011-12-13T23:51:00.008+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

良いケースが多いっす。

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

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

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

HUD型汎用リモコンっす

2011-07-22T22:47:00.002+09:00

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

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

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

LSLCON向けのネタっす。

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

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

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

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

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

HUD

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

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

オブジェクト

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

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

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

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

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

ざっと並べてみると

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

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

　・Yes/No

　・Prev/Next

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

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

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

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

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

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

2011-07-09T23:07:00.002+09:00

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

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

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

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

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

このページっす。

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

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

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

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

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

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

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

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

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

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

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

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

ボックス大工事開始っす

2011-07-06T22:57:00.003+09:00

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

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

正念場っすね。

どうもぺんぎんっす( ◎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割っす。

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

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

2011-07-01T23:52:00.003+09:00

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

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

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

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

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

次は球を作る予定っす。

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

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

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

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

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

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

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

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

0.25 alpha → 0.30 alphaの更新

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

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

2011-06-26T23:46:00.003+09:00

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

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

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

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

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

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

の4点っす。

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

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

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

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

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

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

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

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

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

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

現在の行数

・リング　377行

・スフィア　272行

・シリンダー　323行

・プリズム　461行

・トーラス　304行

・チューブ　525行

・ボックス　931行

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

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

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

・プリム側　63行

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

2011-06-11T23:12:00.002+09:00

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

(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行

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

全然進まないっす

2011-06-10T21:25:00.003+09:00

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

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

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

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

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

現在出てきてるのは

　・出力形式

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

　・出力スピード

この3つっす。

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

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

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

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

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

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

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

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

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

2011-05-23T22:41:00.002+09:00

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

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

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

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

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

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

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

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

Second Life Grid Status Reports

http://status.secondlifegrid.net/

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

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

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

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

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

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

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

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

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

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

三角形と四角形っす

2011-05-21T23:30:00.002+09:00

もう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でもこんな風に分割してやるっすよ。

組み立て完了っす

2011-05-02T22:12:00.002+09:00

1日の夜、組み立てできたっす。

全体の完成度は20%ってところっすかね。

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

バージョン0.02でとりあえず動くモノになったっす。

コンフィグメニューのインターフェースが未定だったりと、

まだまだ作らないといけないものはたくさんあるっす。

日ごとに0.01ずつバージョンを上げるようにしてるので、

アップデート予定の金曜日には0.07になってるはずっす。

サボらなければの話っすけどね。

今日の更新分、つまり0.02→0.03の更新ポイントっす。

・テクスチャを見えない面に配置

　　キャッシュを使った「先読み」のテクニックっす。

　　表示の高速化につながるっす。

名前、PrimToTextのままで行くっすかね？

llGetNumberOfSidesの使い道っす

2011-04-29T23:28:00.002+09:00

日曜日にPrimToText(仮)のα版配布っす。

出力とアップデートの機能だけっす。

テストしてもらわないと分からないっすからね。

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

あんまり使われない関数にスポットライトを当てるっす。

プリムの面の数を取得するllGetNumberOfSides関数っす。

面の数を直接どうこうするって、おそらく無いっすよね。

間接的にfor/while文で威力を発揮するっす。

例えば、プリムの透明度を変更して、さらに元に戻すとき、

元に戻すわけっすから、透明度は取っておかないといけないっすね。

llGetAlphaでALL_SIDESを使うわけにはいかないので、

全ての面で個別に取ってくる必要があるっす。

そこでllGetNumberOfSides関数っす。

全ての面で個別に→面の数だけfor/whileで

と考えればカンタンに書けるっすよね。

これは透明度だけじゃなく、色やテクスチャにも応用できるっす。

リンク版のllGetLinkNumberOfSides関数もあるっす。

たまには普段使わない関数のリファレンスも眺めると良いかもっす。

Pinは固定?っす

2011-04-27T22:00:00.002+09:00

メモリ関係の新関数が出てきたので、今度からメモリ量も表記するっす。

プリム数を表記するのと同じ感覚っす。

流れは向かうと思うんっすけどね。

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

本体にバージョンチェンジの仕掛けを入れるっす。

Pinを使うことになるっす。

前から思ってたんっすけど、皆さん、Pinの値は固定なんっすかね?

固定しちゃうと、バレたら書き換え放題になるっすね。

ユーザー側で自由に書き換えるようにするなら、

こんな回りくどい方法ではなく、Mod権限を付与すれば良いっす。

バレたときの心配をするより、公開したときのメリットを

考えてみてるんっすけど、思い浮かばないんっすよね。

メリットが無いのなら、やらないだけなんっすけどね。

今週はインターフェース作成週間っす

2011-04-25T23:55:00.003+09:00

もうすぐ大型連休っすね。

連休前に試作型を作って配布したいっす。

実際に試してもらうのが一番っすからね。

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

HUDは使わない方針で進めてるっす。

プリムをいじりながら操作することになるので、邪魔になるっす。

使えるのはオブジェクトへのTouchと、ダイアログくらいっすかね。

llTextBoxはビューワによっては使えないんっすよね。

必要な大項目は「出力」、「プリムをRez」、「設定」の3つっす。

「設定」の中項目は

・出力フォーマット

・おおよそのプリム数

・出力スピード

・アップデートする

の4つで、アップデート以外の3つにはさらに小項目が続くっす。

今のところ3層っす。

いくつか候補があるんっすけど、

候補1.ダイアログ

候補2.ダイアログ+パネル

候補3.パイメニュー+パネル(自信あり!)

というわけで候補3.でやるっす。

評判が悪ければ作り直すっす。

パネルにしちゃうとプリム数が少し多くなる欠点はあるんっすけど、

それ以上に分かりやすいと思うっす。

今週は頂点座標を求める算数はお休みっす。

試作品を完成させるっす。

日曜日をお楽しみにっす。

ボックスの穴っす

2011-04-24T22:13:00.003+09:00

トーラス、リング、チューブのrevolutionsが抜けてたっす。

LSL Portalを見て書いてたんっすけど、日本語ページには

revolutionsが抜けてたっす。

編集しておいたので、後から観る方は大丈夫なはずっす。

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

中空はシリンダーから手を付けようと思ってたんっすけど、

ボックスでひらめいた事があるので、ついでにやったっす。

こんな感じっす。

ボックスが面倒なのは、for文で回しにくいからっす。

円とか楕円だと、周囲をぐるっとやるとき、三角関数一発っす。

ボックスはポンっとは出来ないので、4辺それぞれ別に作ったっす。

でも似たような処理になるので、まとめられるならまとめたかったっす。

メモリ量も減るっすからね。

上面の縁だけをまず考えるっす。中空はあとっす。

z = prim_size.z / 2 平面っすね。

xとyが動くっす。

4つの辺は

x = prim_size.x / 2(固定)

y = [prim_size.y / -2, prim_size.y / 2]

x = [prim_size.x / -2, prim_size.x / 2]

y = prim_size.y / -2 (固定)

x = prim_size.x / -2(固定)

y = [prim_size.y / -2, prim_size.y / 2]

x = [prim_size.x / -2, prim_size.x / 2]

y = prim_size.y / 2 (固定)

どっちか止まって、どっちか動いてるっす。

じーっと見てると、なんだか一次式が見えてきたっす。

prim_size.x ・ {(-1 or 1) × 0.5 + (0 or 1) × i / 分割数}

prim_size.y ・ {(-1 or 1) × 0.5 + (0 or 1) × i / 分割数}

2×2の4パターンではなく、ペアの取り方は

(1, 0), (-1, 0), (-1, 1)

の3通りになるっす。

ここまで分かればもう1つfor文を書いて、まとめられるっす。

この方法、パスカットに取りかかるときに苦労が少なくなりそうっす。

中空+パスカットが考えただけでもゾッとする面倒くささなので、

今のうちに技をかけておくっす。

20m? 100m? いやSIM全域っす

2011-04-23T22:53:00.003+09:00

ソラマメが復旧したみたいなので、新関数のネタを書いたっす。

こっちはこっちで「どう使うか」を書くっす。

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

PrimToText(仮)に使って下さいと言わんばかりの新関数っす。

llRegionSayToは便利すぎるっす。

SIM全域に散らばるプリムの形状データ、全部取れるっす。

Sayの20m、Shoutの100mなんてケチなことは言わないっす。

データ送信用のスクリプトが入っていればの話っすけど。

方法っす。

1.本体からチャンネルAで存在確認命令を送る(llRegionSay)

2.プリムは命令を受けたら、llRegionSayToで本体に存在を知らせる

3.本体はプリムの数をカウント、オーナーに出力するか尋ねる

4.本体からチャンネルBで形状データ送信命令を送る(llRegionSay)

5.命令を受けたら、llRegionSayToで本体に形状データを送る。

チャンネルAとBは固定っす。

問題があるとすれば、命令やデータの送受信に失敗したときっす。

「失敗したのでもう一度命令」を送る必要があるっすね。

そのくらいかと思うっす。

まだメイングリッドに適用されてないので、完成時に使えないかもっす。

たぶん自分の完成の方が遅いと思うんっすけどね。

ちょっと心配っす。

進捗状況

・ボックス

　　パスカット　×

　　中空　×(方針決定済み)

　　ひねり　○

　　テーパー　○

　　上部層　○

・シリンダー

　　パスカット　×

　　中空　×

　　ひねり　○

　　テーパー　○

　　上部層　○

・プリズム

　　パスカット　×

　　中空　×

　　ひねり　○

　　テーパー　○

　　上部層　○

・球体、スカルプト

　　パスカット　×

　　中空　×

　　ひねり　○

　　くぼみ　×

・トーラス

　　パスカット　×

　　中空　×

　　ひねり　○

　　穴寸法　○

　　上部層　○

　　プロフィールカット　×

　　テーパー　○

　　半径　×

　　回転体　×

・チューブ

　　パスカット　×

　　中空　×

　　ひねり　○

　　穴寸法　○

　　上部層　○

　　プロフィールカット　×

　　テーパー　○

　　半径　×

　　回転体　×

・リング

　　パスカット　×

　　中空　×

　　ひねり　○

　　穴寸法　○

　　上部層　○

　　プロフィールカット　×

　　テーパー　○

　　半径　×

　　回転体　×

vector型の文字を含んだCSV形式のstringっす

2011-04-22T23:29:00.004+09:00

今回はタイトルが長ったらしいっすね。

ピッタリなのが思い浮かばなかったっす。

いつものことっすけどね。

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

新関数についてはソラマメでやるっすよ。

こっちは細々とやっていくっす。

プリムの形状データはlistenで受け取ることになるっす。

カンマで区切られた文字列、つまりCSV形式を使いたいっす。

プリムの位置をSay、次は姿勢をSay…なんてやってられないっすからね。

1回でまとめてやるっす。

カンマで区切ると言っても、vectorの中の区切りもカンマになるっす。

CSV形式の文字列をlistに変えるllCSV2List関数があるわけなんっすけど、

そのままやっちゃっても良いのかと調べてみたっす。

ダメなら区切り文字にカンマ以外の文字を使うだけなんっすけどね。

https://wiki.secondlife.com/wiki/LlCSV2List

LSL Protalの記述を見ると、そのままで良いんっすね。

vector、rotationはきちんと区切ってくれるみたいっす。

ただし、文字列としてlistに格納されるので、ちゃんとキャスト

してやらないといけないっす。

ここら辺はintegerでもfloatでも同じっすね。

1つラクできるっす。

トーラス2回転半ひねりっす

2011-04-21T22:15:00.002+09:00

丸々1週間かかったっす。

算数の力がだいぶ衰えたみたいっすねえ…

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

では成果っす。

これはin-worldのプリム変形では作れないカタチっす。

パラメータは

サイズ： X=0.500　Y=0.500　Z=0.500

穴寸法： X=1.00　Y=0.50

ひねり： B=900°　E=0°

残りのパスカット、上部層、中空とかはデフォルトのままっす。

調子に乗って2回転半ひねったっす。

スクリプトから出力してるからこそ出来るっすね。

算数の話なので、分かればカンタンなんっすけどね。

トーラスを作る3つのステップは合ってたっす。

　1.楕円を作る

　2.平行移動する

　3.回転させる

ひねりの処理は1.と2.の間に入るっす。

楕円を回転させることが、ひねることになるわけっす。

楕円の回転で間違ってたっす。

昨日の記事を見てもらえば良いんっすけど、

　x=a・cosθ

　y=b・sinθ

っていう楕円を回転させるのに、θ→θ+ひねり分としてたっす。

つまり

　x=a・cos(θ+δ)

　y=b・sin(θ+δ)

とやってたわけっす。

θが0から2πまで動くところを、δから2π+δまで動かすだけっすから、

できる軌跡は同じになるっすよね。

やるならベクトルの大きさを三平方で求めて、さらに

x軸とのなす角をatanで出して、それを回転させ…

なくてもrotationを使って回転させれば良いっす。

atanとかを使った方法は、良い子は1度だけならやっても良いかもっす。

rotationを直接記述しても良かったんっすけど、llAxisAngle2Rot

っていう便利な関数があったので、それを使ったっす。

同じタイプのチューブやリングも似たような感じになると思うっす。

明日までに出来るっすかね？

トーラスのひねりっす

2011-04-20T23:30:00.002+09:00

詰まったので、UIをどうするのかを考えてたっす。

いくつか案があるので、作ってみて評判を聞いてみるっす。

やれるところからやっていくっす。

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

球のひねりは解決できたっす。

次はトーラスのひねりっす。

SLのトーラスは、楕円に楕円なんっすよね。

楕円を楕円の周囲に沿って回転させた軌跡になるっす。

やり始めたとき、2.7秒ほどボールペンが止まったっす。

いきなりの難関だったっす。

トーラスの基本形は3ステップからなるっす。

媒介変数表示していくと分かりやすいかもっすね。

1.楕円を作る

　　x = a・cosθ

　　y = b・sinθ

　　z = 0

2.平行移動する

　x = a・cosθ

　y = b・sinθ + R

　z = 0

3.回転させる

　x = a・cosθ

　y = (b・sinθ + R)cosφ

　z = (b・sinθ + R)sinφ

θ = -(μ + π/2)とおくと

x = -a・sin(-μ) = a・sinμ

y = {b・cos(-μ) + R}cosφ = (b・cosμ + R)cosφ

z = (b・cosμ + R)sinφ

見た目は違うっすけど同じことっす。

本題のひねりは、自分の予想では最初の楕円を作る時、

θ → θ+ひねり分としてやれば良いんじゃないかと思ったっす。

小円(楕円になってるんっすけどね)が傾いて、

大円(これも楕円っす)には変化が無いように見えたからっす。

媒介変数表示がマズイのか、それとも組んだスクリプトがマズイのか。

うまくいかないっすねえ。

形状タイプの分類っす

2011-04-15T23:15:00.002+09:00

上部層の実装中っす。

チューブだけがちょっと違う感じなんっすけど、

他は似たようなことをやるので問題ないっす。

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

プリムのタイプは8種類あるっすよね。

だいたい分かると思うっすけど、3つに分けられるっす。

　　・ボックス系(ボックス・シリンダー・プリズム)

　　・球系(球・トーラス・リング・チューブ)

　　・スカルプテッド

チューブは穴の空いたシリンダーとカタチは似てるっすけど、

似てるのはカタチだけっす。

頂点計算はトーラスの応用編みたいな感じっす。

llGet/SetPrimitiveParamsのパラメータも違うっすよね。

スカルプテッドは球の基本形(中空・パスカット・ひねり・くぼみなし)として

出力することにしてるっす。

作ってるのは7種類になるっすね。

今後「ボックス系」「球形」って書いてたら、上の分け方で書いてると

思ってくださいっす。

進捗
~~1.リング「基本形」「穴寸法」バグ取り~~　　　完了!
~~2.チューブ「基本形」「穴寸法」~~　　　完了!
3.トーラス・リング・チューブ「ひねり」「上層部」「テーパー」　10%完了
4.ボックス・シリンダー・プリズム「中空」「パスカット」
5.球・トーラス・リング・チューブ「中空」「パスカット」
6.球「くぼみ」
7.トーラス・リング・チューブ「プロフィールカット」
8.トーラス・リング・チューブ「半径」「回転体」

引数のリレーっす

2011-04-14T22:58:00.003+09:00

上層部の変数だけ用意して、計算式に入れてなかったっす。

平行移動なので難しくはないっすね。

書き換え量は多いっすけどね…

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

Prim2Text(形状, サイズ, 位置, 姿勢, 出力形式)

{

　　　……

　　Output(頂点A, 頂点B, 頂点C, 出力形式);

　　　……

}

っていう関数を作ってあるっす。

出力形式っていう引数が複数回出てくることになるので、

もっとうまい方法が無いかと考えてたっす。

引数として渡さないとなると、考えられるのは

グローバル変数に出力形式の値を格納しておくことっす。

うっかり代入して値を書き換えないよう、関数を作った方が良いっすね。

string 出力形式;

Set出力形式(string s)

{

　　出力形式 = s;

}

string Get出力形式()

{

　　return 出力形式;

}

Prim2Text(形状, サイズ, 位置, 姿勢)

{

　　　……

　　Output(頂点A, 頂点B, 頂点C, Get出力形式());

　　　……

}

なんか重たいっすね。

負荷の話じゃなく、囲碁用語で言う「重たい」っす。

やりすぎと言うか、なんと言うか……そんな感じっす。

今の方法(リレーする方法)でも書けないことはないっすから、

とりあえずこのまま行くっす。

しっくり来ないっすけどね。

出力テストっす

2011-04-13T23:14:00.006+09:00

DXFエクスポーター(仮)となってたんっすけど、

他の形式でも出せるようにしたので、変えないと変っすね。

PrimToText(仮)とでもしておくっす。

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

基本プリム7種の基本形が出力できるようになったっす。

バグチェックも兼ねて、これまでの成果をカタチにしてみるっす。

くちばしは中空が設定されてるので出してないっす。

他はご覧の通りの感じっす。

0.3mくらいの小さいオブジェクトなので、誤差が結構出てるっす。

floatの仮数部23bitを絞り出す手もあるんっすけどこのままにしておくっす。

詳細度は「高」で出したっす。

気になるデータ量は、驚愕の1.35MBっす。

ついにMBの単位に突入しちゃったっす…

3,272回のllOwnerSayっす。

「まとめてポン」の部分が出来てないので、データの結合は全手動っす。

詳細度を1段階下げて「中」にすると、データ量は半分くらいになるっす。

さらにもう下げて「低」にするとまた半分、「高」の1/4くらいになるっす。

ホントなら「中」「低」の出力結果も載せれば良いんっすけど、

めんどくｓ…

進捗
~~1.リング「基本形」「穴寸法」バグ取り~~　　　完了!
~~2.チューブ「基本形」「穴寸法」~~　　　完了!
3.トーラス・リング・チューブ「ひねり」「上層部」「テーパー」
4.ボックス・シリンダー・プリズム「中空」「パスカット」
5.球・トーラス・リング・チューブ「中空」「パスカット」
6.球「くぼみ」
7.トーラス・リング・チューブ「プロフィールカット」
8.トーラス・リング・チューブ「半径」「回転体」

出力形式っす

2011-04-12T22:57:00.004+09:00

機能についての要望があれば今のうちっすよ。

後からだとLSL独特の面倒臭さが邪魔をするっす。

提案してもらえれば、レスポンスは返すっすよ。

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

とりあえずDXF(R12以前)形式で出力させようとしてたんっすけど、

ご要望にお応えしてWavefront OBJ形式も追加っす。

テキスト形式で出せるなら、リクエストしてもらえば作るかもっす。

DXF R13以降の形式も未実装っすけど、作るのは決まってるっす。

実装済み

　　・DXF(R12以前)

　　・Wavefront OBJ

未実装(後でやる)

　　・DXF(R13以降)

未実装(ホントの未定)

　　・COLLADA

COLLADAもテキスト(XML形式)なので、出そうと思えば出せるはずっす。

コメントアウト出来るっすから、直接出力しちゃっても良いわけっすか。

前と後ろで文字数がプラスになるんっすけど、頂点座標の記述自体は

改行タグを書かない分、文字数がすくなくなるっすね。

DXFは面を1つずつ書いていくので、出力させやすいっす。

でも、COLLADAとかは頂点を最初にだーっと全部書いて、

あとから頂点の組み合わせを書くことになるっす。

まともにやると、頂点の座標を全部格納しないといけないっす。

64KBしか容量が無いっすから、これじゃダメっす。

まともじゃない方法は既に考えてあって、書き換えも少ないっす。

まともじゃないのが問題なんっすけどね。

1.三角形を構成する3頂点を出力

2.「出力する面の数」をインクリメント

3.プリムの構成頂点を全部出力するまで1.と2.を繰り返す

4.面の組み合わせを1-2-3、4-5-6、7-8-9…として、

　「出力する面の数」だけ繰り返し出力

なんかイケそうな感じっすよね。

というわけで「未定」から「後で実装」に格上げっす。

実装済み

　　・DXF(R12以前)

　　・Wavefront OBJ

・未実装(後でやる)

　　・DXF(R13以降)

　　・COLLADA

頂点が重複しまくる「まともじゃない方法」っす。

COLLADAだけじゃなく、Wavefront OBJ形式にも使えるだけに

タチが悪いっす…

進捗

~~1.リング「基本形」「穴寸法」バグ取り~~　　完了!

2.チューブ「基本形」「穴寸法」

3.トーラス・リング・チューブ「ひねり」「上層部」「テーパー」

4.ボックス・シリンダー・プリズム「中空」「パスカット」

5.球・トーラス・リング・チューブ「中空」「パスカット」

6.球「くぼみ」

7.トーラス・リング・チューブ「プロフィールカット」

8.トーラス・リング・チューブ「半径」「回転体」

プリムを外にっす

2011-04-11T22:54:00.003+09:00

自粛期間終了っす。

バリバリやっていくっすよ。

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

ブログを書いてなかっただけで、作業は進めてたっす。

「プリムの形状データを外部に持ち出す」ツールを作ってるっす。

コピーボットとは全く違うっすよ。

llGetPrimitiveParams関数を使って、プリムの形状をテキストの

データに変換して出力させるものっす。

進み具合をまとめると、こんな感じっす。

・ボックス

　　基本形　○

　　パスカット　×

　　中空　×

　　ひねり　○

　　テーパー　○

　　上層部　○

・シリンダー

　　基本形　○

　　パスカット　×

　　中空　×

　　ひねり　○

　　テーパー　○

　　上層部　○

・プリズム

　　基本形　○

　　パスカット　×

　　中空　×

　　ひねり　○

　　テーパー　○

　　上層部　○

・球

　　基本形　○

　　パスカット　×

　　中空　×

　　ひねり　○

　　くぼみ　×

・トーラス

　　基本形　○

　　パスカット　×

　　中空　×

　　ひねり　×

　　穴寸法　○

　　上層部　×

　　プロフィールカット　×

　　テーパー　×

　　半径　×

　　回転体　×

・チューブ

　　基本形　×

　　パスカット　×

　　中空　×

　　ひねり　×

　　穴寸法　×

　　上層部　×

　　プロフィールカット　×

　　テーパー　×

　　半径　×

　　回転体　×

・リング

　　基本形　△

　　パスカット　×

　　中空　×

　　ひねり　×

　　穴寸法　△

　　上層部　×

　　プロフィールカット　×

　　テーパー　×

　　半径　×

　　回転体　×

「基本形」っていうのはサイズ・位置・姿勢の3点セットっす。

○が付いてるのは実装済み、×は未実装っす。

△が付いてるのはバグ取り作業中のところっす。

全部○になってからリリースするので、もうちょっとかかりそうっすね。

作っていく順番は

1.リング「基本形」「穴寸法」バグ取り

2.チューブ「基本形」「穴寸法」

3.トーラス・リング・チューブ「ひねり」「上層部」「テーパー」

4.ボックス・シリンダー・プリズム「中空」「パスカット」

5.球・トーラス・リング・チューブ「中空」「パスカット」

6.球「くぼみ」

7.トーラス・リング・チューブ「プロフィールカット」

8.トーラス・リング・チューブ「半径」「回転体」

各工程3日から1週間くらいで作って、5月の中ごろ完了予定っす。

さらにインターフェースを考えたり、オブジェクトとして作ったり、

形状データをテキストに直しただけでは完成しないっす。

算数ばっかりやってるのもアレっすから、平行してやるっす。

完成は5月中にさせるっす。

完成時期を明言しておいて、自分にプレッシャーをかける作戦っす。

floatとstringっす

2011-03-20T10:22:00.002+09:00

LSLCONが始まったっすね。

27日までやってるっすよ。

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

LSL Portalを翻訳してたんっすけど、気になる文があったっす。

stringからfloatへのキャストについてっす。

Monoにおいて"nan"と"inf"は

1."-"を付けるとマイナスに

2.前方に空白があってもOK

3.後方には他の文字があってもOK

つまり、" -infABC"っていうのも通るわけっす。

llOwnerSay((string)((float)" -infABC"));

ってやると、-Infinityって出るっすね。

llTextBoxで入力されたものについて、直接floatにキャストしちゃうと

かなりマズイんじゃないっすかね？

まとめてポン!っす

2011-03-04T22:13:00.002+09:00

出張先から更新してみるっす。

サボってるんじゃないっすよ!

今、ド深夜っす。

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

「複数プリムの形状を1つにまとめてポン!」の

「複数プリムをまとめてポン!」の部分を作ってたっす。

「プリムの形状をポン!」の部分は来週からまた作るっす。

プ: 出力させるプリムに入っているスクリプト

メ: メイン制御スクリプト

サ: プリム形状を計算・変換して出力するスクリプト

とすると、

メ: プリムの存在を確認するためSay、受信するためlisten

プ: listenして返答のSay

メ: 出力するかどうかの確認ダイアログ

オーナー: ダイアログ入力

メ: ダイアログの入力をlisten

メ: プリムの形状を取得するためSay、受信するためlisten

プ: listenして形状データをSay

メ: listen

メ: 形状データをリンクメッセージで飛ばす

サ: 形状データを計算・変換して出力

という流れにしてるっす。

プリムのオーナー確認もやって、「対策」も立ててるっす。

メッシュのメイングリッド適用はまだ先みたいなので、

まだちょっと時間の余裕はあるみたいっす。

球も出来たっす

2011-02-28T23:35:00.005+09:00

ボックス、シリンダー、プリズムに続いて、球も出来たっす。

これで折り返しっすね。

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

球はカンタンなんっすよね。

極座標での媒介変数表示をそのまま使うだけっす。

「ひねり」は未解決っすけど…

どうしてもポリゴン数が多くなっちゃうのは仕方ないっす。

現状3段階ある「詳細度」のレベルを下げてもらうくらいしか無いっす。

ちなみに、詳細度:高だと、テキストの量は90KB弱になるっす。

では出力したデータをインポートさせて撮ったので、

詳細度での違いを見てみてくださいっす。

詳細度: 低

詳細度: 中

詳細度: 高

Hira 3D Viewer

http://www.hiramine.com/software/hira3dviewer/index.html

を使わせてもらったっす。

頑張って削る必要は無かったんっすね

2011-02-27T21:18:00.004+09:00

ちょっと勘違いしてたっす。

形状を出力させたいプリムに入れるスクリプトは1本だけなんっすけど、

このスクリプトでごちゃごちゃ計算させる必要は無いっすよね。

形状データだけを送れば良いだけのことっす。

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

[形状を出力させたいプリム]

・形状データ送信

[本体]

・制御

　　・プリムの存在確認

　　・形状データ受け取り

　　・計算用スクリプトへのデータ渡し

・形状データ出力用計算 × N

って作れば良いんっすよね。

ボックス用、シリンダー用、球用といった風に、スクリプトを分けると

データを渡しやすいし、何より分かりやすいっす。

プリズムに「ひねり」と「テーパー」を設定して出力させたデータを

インポートさせてみたのをプリントスクリーンしてみたっす。

Hira 3D Viewer

http://www.hiramine.com/software/hira3dviewer/index.html

を使わせてもらったっす。

やっぱり容量の壁っす

2011-02-26T22:52:00.002+09:00

DXF形式でプリムの形状を書き出す作戦は進んでるっす。

ボックス、シリンダー、プリズムまでは書いたっす。

残り球、トーラス、リング、チューブと4種類あるんっすよね。

でも残り容量35KB……足りないっす。

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

ボックスとかも「中空」「パスカット」を書いてないっす。

なので全然容量が足りないっす。

とは言うものの、今は書いてみてるだけの段階で、

共通処理の関数化はまだ手を付けてないっす。

おそらく全体の1/4は消えそうっす。

これでも消費30KB→24KB……うーん、微妙なラインっすねぇ。

スクリプトファイルの数を増やせばカンタンなんっすけど、

使いにくくなっちゃうっすね。

次の球も実装しながら、策を考えてみるっす。

BOXのtwistと側面の頂点数っす

2011-02-20T23:46:00.005+09:00

同じ「ひねり」なので、シリンダーと同じかと思ってたっす。

でも違うみたいなんっすよね。

調べてみたっす。

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

以下のデータは自分が目測で数えたものっす。

違う可能性もあるっす。

データを使う際に、必ず確認するようにしてくださいっす。

自分みたいなことをしない限り、使うことはないと思うんっすけどね。

「ひねり」の設定は[ B ]と[ E ]があるっす。

llGetPrimitiveParamsではTWO_PI倍したx要素、y要素が

それぞれBとYの値(角度)に一致するっす。

以下は[ B ] - [ E ]の絶対値と、側面の分割数の関係っす。

[ B ]と[ E ]はそれぞれ±180度まで設定できるっすから、

[ B ] - [ E ]の絶対値が取りうる範囲は0度から360度になるっす。

BOXのtwist 分割数

0- 44 　　　　　3

45- 58 　　　　 4

59- 73 　　　　 5

74- 88 　　　　 6

89-103 　　　　7

104-117 　　　 8

118-132 　　　 9

133-146 　　　10

147-161 　　　11

162-175 　　　12

176-191　　　 13

192-206 　　　14

207-220　　　 15

221-235　　　 16

236-249 　　　17

250-264 　　　18

265-279 　　　19

280-294 　　　20

295-308 　　　21

309-323 　　　22

324-337 　　　23

338-351 　　　24

352-360 　　　25

最大で25になるんっすけど、途中がシリンダーとは違うっす。

ほとんど14度増えるたびに分割数が1増えてるんっすけど、

たまに13度で増えるっす。

式がとっても気持ち悪いことになりそうっすよね。

データだけは取れたので、実装してみるっす。

経済的な箱っす

2011-02-19T23:38:00.003+09:00

頂点座標と格闘してるっす。

でも格闘というには大げさなんっすよね。

ただ面倒臭いだけっすから。

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

[Ctrl] + [Shift] + [R]でワイヤーフレーム表示になるっす。

元に戻すには同じコマンドを入力すれば良いっす。

やるからには、SLのプリムをそっくりそのまま出力したいっす。

そこで、いろいろとプリムをいじくり回してみてるっす。

ちょっと気になったのが、ボックスのポリゴン数っす。

デフォルトのボックスは、1面あたり4×4頂点、三角形が18個っす。

6面っすから、×6で合計108個の三角形で表現されてるっすね。

次に、テーパーを0以外に設定してみてくださいっす。

すると一気に1面あたり2*2頂点、三角形2個になるっす。

6面でも全部で12個の三角形っす。

ということは、テーパー入れてやれば描画コストが下がるわけっすか。

削れるところは削った方が良いんっすけどね。

ここまでやるっすかね？

インポート実験をしてもらったっす

2011-02-17T23:18:00.002+09:00

順調ではないっすね。

パスカットと中空が曲者っす。

来週あたり、何か閃かないっすかねぇ。

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

まだ閃かないので、先にインポートを試してもらったっす。

使ってるヒトが多いBlenderでやってもらったっす。

インポートは[autodesk DXF]っていうのを選ぶと良いみたいっす。

書き出しが

SECTION

ENTITIES

で、なーんにも無いのでバージョンが違ってもイケるんじゃないかと

根拠の無い予想をしてから作ったっす。

結果はインポートに成功っす。

とりあえずコレで大丈夫みたいっす。

パスカットと中空のやり方がイマイチ分からないので、

先に他の形状を作るっす。

明日はシリンダーができる予定っす。

DXF形式で出力してみるっす

2011-02-14T21:31:00.002+09:00

講座も終わったので、あとはLSLCONだけっすね。

モノはだいたい出来てるので、かなり余裕があるっす。

宣伝頑張らないとっすね。

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

自分の中で1つのテーマになってるんっすけど、

主にSLのモノって、外部からデータを持って来てるっすよね?

逆に、SLのモノを外部に持っていけたら面白くないっすか?

プリムの変形はカンタンっすから、いろいろラクできるかもっすね。

作戦は

1.LSLでDXF形式のテキストデータをHTMLで出す

2.テキストエディタ(メモ帳など)に貼り付け(拡張子は.html)

3.ブラウザで開く

4.テキストエディタ(メモ帳など)にコピペして保存(拡張子は.dxf)

5.モデリングツール(Blenderなど)でインポート

6.加工

7.COLLADA形式でエクスポート

8.SLへ

手順は長くて面倒なんっすけど、これで可能なはずっす。

あとはどれだけプリムの形状を精確に出せるかどうかっす。

算数勝負っすね。

changedイベントのテスト用角材っす

2011-02-12T14:11:00.002+09:00

今日はデジアカの卒業制作品評会っす。

21時からなので、時間があればどうぞっす。

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

たくさんヒトが来ると期待して、ちょっと実験してみるっす。

「短時間で複数回リンクセットの変更があったときに、

ちゃんと1つずつchangedイベントが起こるかどうか」

これを調べてみるっす。

仕掛けてあるのは座ってもらうために用意したイスっす。

座ったあとに、座ったアバターの位置と角度を調整してるっす。

実験の仕組みはカンタンっす。

位置・角度の調整を行うのは最後に座ったアバターとしておいて、

一斉に座ってもらって、位置や角度が変なヒトがいれば

「changedイベントがまとめて起こった」と判断されるっす。

ちゃんと1つずつ起こるなら、「座る→changedイベントで位置調整」が

全員分起こって、きちんと整列するはずっす。

気になってはいたんっすけど、なかなか実験できる機会はないので

結果が気になるっす。

構造体が無いんっすよねぇ

2011-01-11T22:52:00.002+09:00

自分のモノも作れる時間が取れるようになったっす。

本格的には2月に入ってからになると思うんっすけどね。

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

LSLにはlist型っていうのがあるっすけど、構造体は無いっす。

単にデータ型の組が必要な場合(構造体の定義が欲しいわけっす)、

いろいろと細工が必要になるっす。

しっくり来ないんっすけどね。

// 構造体っぽいものの初期化

list SetNewStruct(integer a, string b, vector c)

{

　　return [a, b, c];

}

// 構造体っぽいものの参照

integer GetStruct2Integer(list x)

{

　　return llList2Integer(x, 0);

}

string GetStruct2String(list x)

{

　　return llList2String(x, 1);

}

vector GetStruct2Vector(list x)

{

　　return llList2Vector(x, 2);

}

　　　　・

あとコピーは=演算子でイケるとしても、代入とかも書かないといけないっす。

メンバに" . "でアクセス出来ないのでこうなるわけなんっすけど、

そうだとしても冗長に思えるっす。

他には構造体の識別子(名前なので文字列になるっすよね)を

list型に全部ぶち込んで、llListFindListでindexを取る方法っす。

でもこれだと構造体っぽいlistの、一体何番目の要素がどの型なのか

はっきりしなくなるっす。

上の方法だと何番目がどの型なのかはっきりするんっすけどね。

作ろうとしてるのは多倍長演算の部分っす。

数値をどう扱おうか迷ってる段階なので、全然進まないっす…

10cmの隙間っす

2011-01-10T22:35:00.003+09:00

オフィスアワーから情報を仕入れてきたっす。

かなり影響が大きいっすね。

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

Beta Server Office Hourからっす。

http://wiki.secondlife.com/wiki/Beta_Server_Office_Hours/Minutes/2010-12-16

Havok 2k10っていう単語が見えるっす。

Havok7のときにも出てきたFalconさんが頑張ってるみたいっすね。

いつになるかはまだ分からないっす。

Havok 2k10については個別ページがあるっす。

http://wiki.secondlife.com/wiki/Havok_2k10_Beta_Home

まだBetaなので最終的な仕様とは異なる場合があるっすけど、

とりあえず目を通しておくと良いと思うっす。

「ほとんどのオブジェクトから『10cmの隙間』を失くす」(ぺんぎん意訳)

(原文はChangesの

we have removed the "10cm gap" from most objects.)

というのが大きな点っす。

10cmの隙間っていうのは、物理オブジェクトを何でも良いっすから

何かの上に乗せてみると分かりやすいっす。

物理オブジェクトの下に隙間が出来ると思うっすけど、

この隙間の幅が10cmになるっす。

スクリプトではcollisionイベントが上がるっすけど、

見た目ではくっついて見えないわけっす。

今度のHavok 2k10では、この隙間は無くなるっす。

http://wiki.secondlife.com/wiki/Havok_2k10_Beta_Home

に書いてあること以外で思いつくのはアバターについてっす。

10cm沈んじゃうんじゃないっすかね？

足回りのモノは使い物にならなくなる可能性は否定できないっすね。

装着位置をズラせば良いだけのことなんっすけどね。

これは調べがいがありそうっすね。

rotationへの持って行き方っす

2011-01-08T23:01:00.003+09:00

いつの間にか2011年っすね。

今年もちょこちょこ書くっすよ。

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

直接記述するのは面倒なので、別のカタチから持って行くっすよね。

とは言ってもllEuler2Rotでやってるのがほぼ全部っす。

他にもrotationへの持って行き方があるんっすけどねぇ。

自分はllAxisAngle2Rotも使ってるっす。

回転軸を明確にできるのが良いっすよね。

でもllAxis2Rotはイマイチ分かりにくい感じがするっす。

乗り物(飛行機系)で使われてるんっすかね？

単純なZ軸周りだけの回転はrotationを直接書いてるんっすけど、

皆さんはどうやってるっすかね？

数値入力用ボードっす

2010-12-24T20:42:00.002+09:00

課題提出数の予想は7なんっすけど、どのくらい集まるっすかね。

手ごたえが全く無いんっすけど…。

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

テンキーみたいなのを作ったっす。

llTextBoxが使えるようになったっすけど、「不正な入力」に対する

処理ってかなり面倒なんっすよね。

数値入力に関して、しばらく使えそうっす。

他のヒトにも使ってもらう方法を考えてたっす。

リンクメッセージで値を飛ばす事も考えたっすけど、

それだとMod権限が必要になっちゃうっす。

となるとリンクせずに、オブジェクトからRezして、

say/listenでやり取りする方法がベターじゃないかと考えたっす。

1.llRezObjectでボードをRez

(第5引数のinteger型パラメータに使用するチャンネルを書く)

2.rez_objectイベントにRezしたボードのkeyが渡るので

　使用するチャンネル、ボードのkeyを指定してlistenしておく

3.ボードで入力

4.ボードの「送信ボタン」を押す

5.ボードがon_rezイベントで受け取ったパラメータを使って、

　指定されたチャンネルでsay

6.listenで受け取る

こういう流れになるっす。

これくらいなら「パーツ」として使いやすそうなんっすけど

需要がどこまであるのか分かんないっすね。

rotationが交換可能なときっす(2)

2010-12-22T19:52:00.003+09:00

昨日の続きになるっす。
結論まで一気にやるっすね。
どうもぺんぎんっす( ◎v◎ )

昨日の記事を読んでない場合は読んでからの方が良いっすよ。
http://northernpenguin-ex.blogspot.com/2010/12/rotation.html

a * b と b * a の各要素を比較して
x要素について a.y * b.z = a.z * b.y　－①
y要素について a.z * b.x = a.x * b.z　－②
z要素について a.x * b.y = a.y * b.x　－③
ここからスタートっす。

場合分けするっす。
I　aがZERO_ROTATIONのとき
b.x、b.y、b.zの値によらず成り立つ。

II　a.x≠0 かつ a.y=0 かつ a.z=0 のとき
②より b.z=0
③より b.y=0
②または③より b.xの値によらず成り立つ。

同様にして、

a.x=0 かつ a.y≠0 かつ a.z=0 のとき

　b.x = b.z = 0 のとき、b.yの値によらず成り立つ。

a.x=0 かつ a.y=0 かつ a.z≠0 のとき

　b.x = b.y = 0 のとき、b.zの値によらず成り立つ。

III　a.x≠0 かつ a.y≠0 かつ a.z=0 のとき
②より b.z=0
　A　b.y=0 のとき
　③より b.x=0
　∴ bはZERO_ROTATION
　B　b.y≠0 のとき

　③より b.x≠0
　③の両辺を b.x * b.y で割ると
　a.x / b.x = a.y / b.y

　uを0以外の実数として a.x / b.x = a.y / b.y = u とすると

　a.x = u * b.x

　a.y = u * b.y　と書けるから

　A = (a.x, a.y, 0), B = (b.x, b.y, 0) とすると

　A = uB となる。

　∴O = (0, 0, 0)とすると、BはOA上にある

同様にして、a.x≠0 かつ a.y=0 かつ a.z≠0 のとき

a.x=0 かつ a.y≠0 かつ a.z≠0 のときも

　 bはZERO_ROTATION　または

　 BはOA上にある。

IV　a.x≠0 かつ a.y≠0 かつ a.z≠0 のとき

　A　b.z=0のとき

　①より b.y=0

　②より b.x=0

　∴ bはZERO_ROTATION

　B　b.z≠0のとき

　①より b.y≠0

　②より b.x≠0

　①の両辺を b.y * b.z で割ると

　a.y / b.y = a.z / b.z　－④

　②の両辺を b.x * b.x で割ると

　a.z / b.z = a.x / b.x　－⑤

　③の両辺を b.x * b.y で割ると

　a.x / b.x = a.y / b.y　－⑥

　④⑤⑥より uを0以外の実数として

　b.x = u * a.x

　b.y = u * a.y

　b.z = u * a.z　と書けるから

　A = (a.x, a.y, a.z), B = (b.x, b.y, b.z) とすると

　A = uB となる。

　∴O = (0, 0, 0)とすると、BはOA上にある

これで場合分けが完了っす。

キーは「BはOA上にある」、これっす。

IIもa.x = u * b.x のカタチに出来るので、これもまとめられるっす。

OAとかOBっていうのは回転軸を表すベクトルっす。

というわけで結論は

「回転軸が同じなら交換可能」

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

rotationが交換可能なときっす

2010-12-21T22:24:00.005+09:00

rotationではa * b と b * a が一致しないことが多いんっすけど、

逆に一致することもあるわけっす。

どんな条件があるのか考えてみたっす。

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

まず、明らかなのは

　・a = b のとき

　・b = ZERO_ROTATION / a のとき

これらは見た瞬間に分かるっすね。

他の場合が無いか、考えてみるっす。

作戦はa * b と b * a を計算して、x、y、z、sの各要素を比較するっす。

式が4本出るので、そこから考えて行くっす。

とりあえず積を出すっす。

どっちか片方書けば、もう片方はaとbを入れ替えれば良いっすね。

というわけでa * bを計算するっす。

c = a * b とすると、

c.x = a.s * b.x + a.x * b.s + a.y * b.z - a.z * b.y

c.y = a.s * b.y + a.y * b.s + a.z * b.x - a.x * b.z

c.z = a.s * b.z + a.z * b.s + a.x * b.y - a.y * b.x

c.s = a.s * b.s - a.x * b.x - a.y * b.y - a.z * b.z

s要素はaとbを入れ替えても同じになるっすね。

ということは実質3本の式になるっす。

x、y、z要素についてもaとbを入れ替えたら同じになる部分は

緑で表示しておいたっす。

比較するときに両方で出てくるので、消える部分になるっす。

a * b と b * a の各要素を比較して

x要素について a.y * b.z = a.z * b.y　－①

y要素について a.z * b.x = a.x * b.z　－②

z要素について a.x * b.y = a.y * b.x　－③

①②③を満たすようなbを選べばa * bとb * a は一致するっす。

もうちょっと変形しないと見えないっすね。

福袋っす(2)

2010-12-17T20:16:00.002+09:00

LSLで無茶してみましたシリーズ最新作っすね。

自分の方法を載せておくっす。

問題点も書いておくっすね。

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

何をやるかは前回の記事参照っす。

深さ優先探索で書いてみたっす。

list CONTENTS_AND_VALUES = // 景品(?)名, 価値 [価値の大きいもの順!]
  ["product10", 50,
  "product09", 50,
  "product08", 40,
  "product07", 40,
  "product06", 30,
  "product05", 30,
  "product04", 20,
  "product03", 20,
  "product02", 10,
  "product01", 10];
integer RANGE_MIN = 90; // 設定値の下限
integer RANGE_MAX = 110; // 設定値の上限

integer item_count; // コンテンツにある景品(?)総数

list bag; // 袋の中身
list result; // 探索結果格納用

// 初期化
Init()
{
  item_count = llGetListLength(CONTENTS_AND_VALUES) / 2;
}
// 探索制御
integer Search()
{
  integer i;
  for(i = 0; i < item_count; ++i)
  {
      bag = [i];
      DPS(i, llList2Integer(CONTENTS_AND_VALUES, i * 2 + 1));
  }
  if(result)
  {
      return TRUE;
  }
  else
  {
      return FALSE;
  }
}
// 深さ優先探索
integer DPS(integer prev, integer total)
{
  integer i;
  integer value;

  for(i = prev + 1; i < item_count; ++i)
  {
      // ピックした後の状態
      bag = [i] + bag;

      // 評価値を計算
      value = llList2Integer(CONTENTS_AND_VALUES, i * 2 + 1);
      total += value;

      // 再帰
      if(IsRange(total) || DPS(i, total))
      {
          result = [llDumpList2String(bag, ",") + "合計" + (string)total] + result;
      }

      // ピック前に戻す
      total -= value;
      bag = llDeleteSubList(bag, 0, 0);
  }
  return FALSE;
}
// 評価
integer IsRange(integer value)
{
  if(value >= RANGE_MIN)
  {
      if(value <= RANGE_MAX)
      {
          return TRUE;
      }
  }
  return FALSE;
}

default
{
  state_entry()
  {
      Init();
      if(Search())
      {
          llOwnerSay((string)llGetListLength(result));
          llOwnerSay(llDumpList2String(result, "\n"));
      }
  }
}

結果は全部まとめて1つのlistに格納しておいて

ダンプしてOwnerSayさせてるっすから、途中で切れちゃうかもっす。

関数DPS内のresultに結果を入れてる部分で

逐一OwnerSayさせた方が良いかもっすね。

60通りの組み合わせが出力されるはずっす。

これで全部網羅してるかというと、そうではないっす。

0,1合計100

っていうパターンがあるっすよね。

範囲内に収まってるっすけど、まだイケるっすね。

8番目または9番目の価値10を加えることも出来るっす。

自分の方法はこのオマケの部分を考慮してないっす。

また改良するかもしれないっすけど、とりあえずこんなもんで…

福袋っす(1)

2010-12-16T21:30:00.002+09:00

提出された課題をチェックしてたらこんな時間っす。

今回のネタに関するスクリプトは書けてないっす。

明日になるっすね。

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

とっても面白そうなネタが投下されたっす。

福袋なんっすけど、もちろん自分の商品じゃないっすよ。

福袋を箱詰めする際の、その組み合わせ方についてっす。

今日は問題提示だけになりそうっす。

中に入れるモノにはそれぞれ「価値」が割り振られてるっす。

いくつかモノを組み合わせて価値の合計が「設定値」の

範囲内に収めたいわけっす。

ついでにその組み合わせ方を列挙もしたいっす。

あ、同じモノを2つ以上入れるのはナシっす。

組み合わせ方のパターンは膨大になって面倒なので

スクリプトで解かせようというものっす。

具体的に問題を見て行くっす。

list CONTENTS_AND_VALUES = // モノの名前, 重み

[

　　　"product01", 10,

"product02", 10,

"product03", 20,

"product04", 20,

"product05", 30,

"product06", 30,

"product07", 40,

"product08", 40,

"product09", 50,

"product10", 50

];

こんな感じのlistが与えられるっす。

要素数も変わると思ってた方が良いっすね。

これと「設定値」、例えば[合計90から110]が共に与えられた時

考えられる組み合わせを全部出せという問題っす。

組み合わせの1つとしては

product03　20

product06　30

product10　50

で、価値を合計すると100になるので設定値を満たすっす。

パターン数は

モノを1個選ぶ……₁₀C₁

モノを2個選ぶ……₁₀C₂

モノを3個選ぶ……₁₀C₃

　・

モノを10個選ぶ……₁₀C₁₀

これの合計数になるっす。(面倒なので計算はしてないっす)

モノが10種類なので大したことないんっすけど、

20種類、30種類となるとかなりの数になるっす。

product03-product06-product10の組み合わせを発見したら、

product03-product10-product06

product06-product03-product10

product06-product10-product03

product10-product06-product03

product10-product03-product06

っていう組み合わせも見つけちゃう可能性があるっす。

これは価値大→価値小の順に探索を進めて行けば

防げるっす。同価値の場合はlistのインデックス順っす。

product03-product06-product10のケースだと

product10-product06-product03の1通りになるっす。

自分は深さ優先探索でやろうと思ってるんっすけど

皆さんならどうやるっすかね？

新しい土地を探さないとっす

2010-12-15T21:21:00.003+09:00

多倍長演算はロマンあふれる円周率計算と共に

着々と進んでるっす。

無いと困るものでは無いんっすけどね。

あれば便利かも程度のもんっす。

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

いろいろあって、自宅兼作業場兼店舗を撤去したっす。

これで自分の借りてる土地がなくなったわけっす。

久しぶりに土地が無い状態に戻ったわけなんっすけど、

inするときに「ホーム」を選べないのは地味に痛いっす。

MarketplaceのMagic Boxも置くところが無いのも

痛いと言えば痛いっす。

現物が置けないので、Magic Box単体では置きたくないっす。

月々L$1,000で1,024sqmくらいの土地があれば教えてくださいっす。

あ、ベーシックアカウントなので、レンタルっす。

もうちょっと精度ほしいっすよね

2010-12-12T21:31:00.002+09:00

土曜日の「いつもの会」は新関数についてちょっとやったっす。

講座の受講者が誰か来るかと思ってたんっすけど、

結局誰も来なかったっす。興味無いんっすかね？

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

LSLのfloat型は単精度浮動小数っす。

C言語などでのdouble型に相当する型がLSLには存在しないっす。

integer→float→integerとキャストすると元の値と違ったり

することもあって、何かと不便っす。

いっそのこと多倍長演算の仕組みを作れば良いんっすけど、

それは大げさ過ぎる気がするっす。

作ったとしても、他のスクリプトからは参照できないわけっすから、

各スクリプトファイルに作った関数をコピペしていくことになって、

何やってるか分かんなくなるっす。

C#が来てくれればある程度の問題は片付くと思うんっすけど

いつになるか分かんないっすから、大げさにやるっすかねぇ。

多倍長演算、やってみるっす。

10.11.30サーバーからの新関数っす

2010-12-11T21:47:00.004+09:00

ちょっと乗り遅れた感があるっすね。

新しく加わった関数より、新しく加わったフラグが大きいっす。

両方とも記事で触れるっすけどね。

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

もう来てる(=使える)ので、リンクは関数のページにしておくっす。

まずは新関数のllGetEnvからっす。

http://wiki.secondlife.com/wiki/LlGetEnv

この関数はRegionのバージョン情報を取得する関数になるっす。

使い道はそんなに無いとは思うんっすけど、

changedイベントでリスタートを検知したついでに

バージョンチャンジによるリスタートなのか、それとも

オーナーやエステートマネージャーによってリスタートされてのかを

判別するのには使えそうっす。

判別した後のことは知らないっすよ。

もう1つがllGetObjectDetailsの追加フラグっす。

http://wiki.secondlife.com/wiki/LlGetObjectDetails

追加されたフラグは3つあるっす。

OBJECT_RUNNING_SCRIPT_COUNT

　　オブジェクトに入ってる「実行中」のスクリプトの本数を

　　取得するためのフラグっす。

OBJECT_TOTAL_SCRIPT_COUNT

　　オブジェクトに入ってるスクリプトの本数を取得できるっす。

　　OBJECT_RUNNING_SCRIPT_COUNTとは違い、

　　「実行中」でないスクリプトもカウントするっす。

OBJECT_SCRIPT_MEMORY

　　オブジェクト中のスクリプトが消費しているメモリ量を

　　バイト単位で取得するためのフラグっす。

便利なのは引数にアバターのkeyを入れることも出来て、

装着物の合算値を得ることが出来ることっす。

データを集めてみても良いかもっすね。

まだ来てない関数にllCastRayっていうのがあるっす。

Ray(光線)をCast(投げる)ってことっすから、~~パーティクルっぽいっす。~~

collisionみたいな、sensorみたいな…のを関数でやるっぽいっす。

ベータグリッドで適用済みのRegionもあるみたいっすから、

試してみてくださいっす。

rotationも変わらないっすよね(1)

2010-11-23T23:57:00.005+09:00

2か月半ぶりっすね。

講座が終わったので、こっちも書いていくっす。

まだもうちょっと講座関係の書きものが残ってるんっすけどね。

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

PRIM_ROT_LOCALなんてフラグが追加されてたので、

ちょっと解説っぽいのを書いておくっす。

自分は元々rotationバグなんて無いと思ってるっすから、

そのことについてっす。

vectorもrotationも似たようなもんなので、vectorからっす。

珍しく図を描いてみたっす。

だいたい見れば分かるっすよね。

OがSIMの南西角、高度0mの(0, 0, 0)

Pがルートプリムの位置

Qが子プリムの位置っす。

SLPPの引数に入れるのはPQっす。

これの表し方にグローバル基準とかローカル基準とかあるっす。

どっちでも同じPQなのが注意点っすね。

ベクトルなら上に例のアレを付けるべきなんっすけど、

いろいろと面倒なので大文字で許してくださいっす。

まずは「グローバル」からっす。

これは単純っす。

PQをOPとOQで表せば良いっす。

PQ = OQ - OP

これでOKっす。

「Oから見てQの位置に移動させる」

っていうのをこの式は表わしてるっす。

次は「ローカル」っす

「P(ルートプリム)から見てQの位置に移動させる」

ということをしたいわけっすね。

ということは、QをOPだけ平行移動した点をQ'とすると

PQをOQ' + なんとか　のカタチにすれば良いっす。

PQ = OQ - OP ―①

QをOPだけ平行移動した点がQ'だから

OQ + OP = OQ'―②

∴OQ = OQ' - OP ―③

③を①に代入すると

PQ = OQ' - OP - OP

具体的な数字を入れてみるっすかね。

(算数の話なので、floatなのに.0無いね！とかはナシっす)

O = (0, 0, 0), P = (1, 2, 3), Q = (4, 5, 6)

としてみるっす。

ルートプリムが今、Pの位置にあって、

子プリムをQの位置に移動させたいと思ってるわけっす。

「グローバル」でやってみるっす。

PQ = OQ - OP

　　　= (4, 5, 6) - (1, 2, 3)

　　　= (3, 3, 3)

「ローカル」でもやるっす。

OQ'は②式からOQ' = OQ + OP　っす。

さっき書いた「Pから見てQの位置」っていうのはこの部分っす。

OQ' は計算すると (4, 5, 6) + (1, 2, 3) で (5, 7, 9) っすね。

PQ = OQ' - OP - OP

　　　= (5, 7, 9) - (1, 2, 3) - (1, 2, 3)

　　　= (3, 3, 3)

当然一致するわけっす。

ほら、何となくrotationと同じ雰囲気っすよね？

短く伝えるって難しいっすね

2010-08-30T22:46:00.002+09:00

まだ講座の1回目も始まってないっすけど、

すでに2回目の原稿を作ってるっす。

卒業制作の課題も決まりつつあるっすよ。

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

講座は1回につき75分っす。

この時間に合わせて原稿の量も調整することになるっす。

やってみると結構難しいんっすよねぇ。

原稿をコピペしてSay/Shoutするのに1行10秒かかるとすると、

1分で6行、40分で240行の計算っす。

ずーっとしゃべってる訳にも行かないっすから、40分ちょいくらいを

大体の目安に書いてるっす。

文字数はあんまり関係ないっすね。

読みにくくなければOKっす。

書く前にあらかじめ「やること」について時間配分をしておいて、

それに合わせて説明文を書いてるっす。

重要なことには、それだけ多くの文字数を割けるわけっす。

でも行数がすぐに足りなくなっちゃうんっすよねぇ…

書き上がった1回目の原稿は250行8,000字超に仕上がってるっす。

本気で書いたので、うまく伝わると良いんっすけどねぇ。

算数はやらないっすよ

2010-08-29T23:01:00.002+09:00

サードパーティのビューワで何かあったらしいっすね。

Philipさんもblogに書いてたっすね。

Dos攻撃に関するセクションに引っかかったとあるっすね。

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

講座のアンケートを見てると、「オブジェクトの動き」についての

要望が多数来てたっす。

モノは何であれ、オブジェクトに移動・回転をさせたいということっす。

これはみっちり算数をしたいということなんっすよね?

それ以外に考えられないっす。

自分は一向に構わないんっすよ?

週末の土曜日に大人が集まって三角関数でゴリゴリやるってのは

なかなか見れない光景っすからね。

LSLは演算子が強力なので、三角関数を使う機会はほとんどないっす。

でも「使わなくても出来る」だけであって、きちんと三角関数での演算も

理解した上でやるっていうのが筋っすよね?

特にrotationで言えることっす。

講座でやるとなると、受講者の一番下のレベルに合わせる必要があるっす。

「sinもcosも分かりません」が含まれていた場合、

そこからスタートすることになるっす。

これってスクリプト講座っすか?

「たのしいさんすう講座」っすよね。

というわけで算数はやらないんっすけど、

オフィスアワーではネタを持ってきてくれれば、

いくらでもやるっすよ。

文字だけで説明できるかは分かんないんっすけどね。

人数多いっすね

2010-08-28T23:19:00.003+09:00

9/4(土)からいよいよ自分の講座が始まるっす。

受講者多すぎるっす…

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

アンケートが帰ってきたのは76名分っす。

つまり受講者も76名いるってことっす。

40名ほどかと思ってたんっすけど、倍っす。

まともに講座はできないっすね。

実際にどうするかはソラマメに書いておくっす。

こっちはこっちで別なことを書くっす。

人数が多くなっても、質問は一切受け付けないとやってしまえば

どうにでもなるっす。

でもそれじゃあ面白くないわけっす。

講師も受講者も両方っすね。

オフィスアワーの時間でやろうとしていたことの3割くらいは

出来なくなるかもしれないっすけど、なんとかやりたいことは

全部やりたいっすね。

来年も大きな変化がありそうっすね

2010-08-23T23:08:00.002+09:00

人員整理の話も一段落ついて、次のステップの話も出始めたっすね。

blogからネタを拾ってきたっす。

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

http://blogs.secondlife.com/community/features/blog/2010/08/20/the-future-of-teens-and-second-life

Teen Gridが年末に廃止されるらしいっす。

SLCCの講演で話されたみたいっすね。

Main Gridに入れるのは18歳以上と規約に書いてあるっす。

それを16歳以上と範囲を拡大するみたいっす。

高校生ならOKになるわけっすね。

すでにMain Gridの住人となってるヒトへの影響はというと、

ほとんど無いんじゃないかと思うっす。

年齢で差別したりということは無いっすからね。

ただ、レーティング区分が厳格化されるんじゃないかと妄想してるっす。

Generalのところは酒もタバコも、もちろんドラッグもダメとやっておいて、

そこに将来Teen Grid対象年齢だった13-16歳のユーザーを入れるっす。

将来的にはありえそうなんっすけど、来年1月に16-18歳のユーザーが

来る段階では、おそらく年齢認証をしていないMain Gridのユーザーと

同じ状態になるんじゃないかと思うっす。

つまりはAdult区分以外はアクセス可能となってるっす。

まぁ、妄想の域は出ないんっすけどね。

16-18歳のユーザーが定着するのか、気になるところっすね。

盤の切れ目っす

2010-08-22T22:14:00.002+09:00

デジアカの入学式が終わったっす。

いよいよ本格的に動き始めるっす。

デジアカについてはソラマメで書くっすね。

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

リバーシについてっす。

手を加え出したらキリが無いっす。

マスの数は8×8で64マスあるっす。

でもinteger型(32bit符号付き整数値)しかないので面倒っす。

uint64とか、せめて配列でもあればラクなんっすけどね。

仕方がないのでinteger型の変数2つでビットボードを作るっす。

盤の上半分と下半分に分けて、それぞれ左上から右下に向かって

bitを割り当てていくっす。

A1が1つ目の変数のLSBで、H4が1つ目の変数のMSB、

A5が2つ目の変数のLSBで、H8が2つ目の変数のMSBっす。

石をひっくり返す処理で、横方向(行方向)を調べるのは簡単っす。

でも縦方向(列方向)とかナナメ方向を調べるのが面倒っす。

面倒というか、頭がこんがらがってるだけなんっすけどね。

1つ目の変数の上位8bitと2つ目の変数の下位8bitは接してるので

縦方向(列方向)を調べるときにはシフトしてやる必要があるっす。

ここで引っかかってるっす。

あと、盤面を2つの変数に分けたので値の取得や更新が1処理で

できないのがイライラポイントっす。

listを使えば見た目は1つで済むんっすけど、実際には

llLIst2Integerで取得→integerで演算→llListReplaceList

ってやることになるっす。

出来なくもないんっすけど、LSLはいろいろと面倒っすね。

全手動トランプっす

2010-08-21T23:07:00.003+09:00

デジアカの入学式は中止みたいなカタチになっちゃったっすね。

制服は講座の1回目で配布するらしいっすよ。

まだの方はそちらでどうぞっす。

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

アリかナシかで言えばナシのネタっす。

でも応用範囲は広そうっす。

全手動トランプは文字通り全ての操作をスクリプト制御じゃなくて、

手動で行うトランプっす。

Trans権限だけ付けたトランプ(52枚+ジョーカー)を用意すれば良いっす。

とは言え、カードを配るのはスクリプトでやった方が良さそうっす。

インベントリーでは名前順、または日付順に並んじゃうので

シャッフルするのが困難っすからね。

ここで言う「配る」はllGiveInventoryを指してるっす。

なのでTrans権限が必要なわけっす。

すごく面倒なんっすけど、ほとんどのゲームは出来るはずっす。

いや、二度とやりたくないくらい面倒っすね。

注意事項としては、遊び終わったらカードの枚数を確認することっす。

誰かが持って行って失くした、とかならないようにっすね。

ケース(InventoryDropを許可)を作っておいて、そこに入れるように

するのも有効な方法かもしれないっすね。

これなら枚数のカウントもスクリプトで簡単に出来るっす。

このネタはナシっすねぇ…

実質、週2回っすね

2010-08-19T22:04:00.002+09:00

店舗兼自宅があるSIMに1.42が来てたっす。

SIMの境界線をうろちょろしてみたんっすけど、

確かにラグは少なくなったかもっす。

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

9月からいよいよスクリプト講座が始まるっす。

講座は隔週でやるんっすけど、それとは別にオフィスアワーを設けるっす。

質問とかを受け付ける時間っすね。

自分の予定では土曜日に講座をやって、

水曜日と、土曜日の講座の無い日をオフィスアワーにしようと

思ってるっす。

なので実質週2回あるわけっすね。

オフィスアワーは質問に答えるだけじゃなくて、

LSLの仕様の話だったり、＋αのこともしようと思ってるっす。

講座は初心者向けなんっすけど、オフィスアワーはそこそこ書けるヒトに

向けてやるようなことをイメージしてるっす。

あらかじめネタを考えておく必要がありそうっすね。

あ、そーそー。

Philipさんのアバターのスタイリストを募集してるみたいっすよ。

リンクを貼っておくっす。

http://blogs.secondlife.com/community/features/blog/2010/08/18/philip-linden-20

Server1.42っす

2010-08-18T23:08:00.002+09:00

もう既に始まったっすけど、サーバー1.42へのアップデートがあるっす。

1.40が来たときほどの衝撃的な変化は無いっすね。

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

詳細はリリースノートをどうぞっす。

http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Server/1.42

LSLの新関数は今回はナシっす。

リリースノートもすっきりしてるっすね。

目玉はSIM間の移動とかによるラグの軽減っすね。

テレポートだけじゃなく、横切ったときについても軽減したみたいっす。

SIMを横切ったときについて改善されたっていう記憶はあまりないっす。

テレポートなら過去に何回も改善されてるっすね。

Second Life Community Convention(SLCC)の

Philipさんの講演のログをじっくり見てみたいんっすけど、

なかなか時間が取れないっすねぇ。

SofTalkでボイスチャットっす

2010-08-13T23:47:00.002+09:00

こういうネタはひょっとすると始めてかもっすね。

さほど詳しくないんっすけど、いじってたら出来たっす。

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

SofTalkはニコニコ動画の「ゆっくり実況」としても有名っすね。

テキストをwave形式にしてくれるフリーソフトっす。

これでSLのボイスチャットが出来ないかと思ったわけっす。

何の脈絡もなく、唐突にやりたくなったっす。

方法は実に単純で、

　1.マイク入力ができる状態で、ステレオミキサーをONにする

　2.マイクじゃなくて、ステレオミキサーを「規定のデバイス」に

　3.スピーカーのマイク入力のミュートを解除

とすれば出来たっす。

あとはSofTalkでテキストを打って「再生」すれば流れるっすよ。

3.のスピーカーの設定はRearなんたらとかFrontなんたらに

なってる場合もあるっす。(実際、自分がそうだったっす)

注意点は、スピーカから聞こえてくる音がそのままSLに流れちゃうっす。

なので裏で「何か」やるときは十分注意してくださいっす。

言わなくても分かるっすよね？

今のところ活用する予定はないんっすけど、ネタとしては面白いっすね。

C#は意外と早く来るかもっす

2010-08-11T23:09:00.002+09:00

デジアカの受講申し込みの締め切りまで1週間っす。

自分にも新しい情報は入ってこないっす。

謎すぎるっすね。

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

C#プロジェクトは凍結がオフィスアワーで発表されたっすけど、

なんとなく早い時期に復活もありえそうな気配っす。

なんとなくっすよ。

ここ最近のKellyさんのオフィスアワーのログを見てると、そんな気がするっす。

http://wiki.secondlife.com/wiki/User:Kelly_Linden

Babbageさんがゾンビ化する前の段階の自分の予想は、

早ければサーバー1.44でテスト段階まで来るんじゃないかと思ってたっす。

ご存じの通りの現状っすからこれは無さそうっすね。

じゃあいつ頃かと言われると、全く読めないっす。

あと1年待てば何か分かるんじゃなかとか、そんなレベルっす。

でもいつまで待っても来ないわけじゃあ無さそうな感じっす。

ま、気長に待ってるっす。

llTextBoxはもうすぐ来るんっすかね?

2010-08-09T22:54:00.003+09:00

ネタを仕入れてきたっす。

鮮度はあんまり良くないんっすけどね。

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

Kellyさんのオフィスアワーのログをチェックしてたっす。

http://wiki.secondlife.com/wiki/User:Kelly_Linden/Office_Hours/2010-07-19

どうやらllTextBoxはサーバー上では動いてるみたいっすね。

llTextBoxについてはずいぶん前からwikiに載ってるのでどうぞっす。

http://wiki.secondlife.com/wiki/LlTextBox

(U)マークが付いてるっすね。

自分のビューワは公式のSecond Life 2.1.0 (207030)なんっすけど、

既にスクリプトエディタではllTextBoxの文字は赤く表示されて、

しかもコンパイルも通るっす。

もちろん望んだ結果にはならないんっすけどね。

試してみると良いっすよ。

Kellyさんが言うには、後はビューワ側の対応待ちらしいっす。

ビューワの事については他の皆さんが調べてくれると思うので

その調査を待つっす。

でも使うとなると混線しないっすかねぇ。

key指定だけじゃかなり不安っす。

Rubber-StoneとFlesh-Stoneっす

2010-08-06T23:53:00.002+09:00

明日、デジアカの講義をリハーサルしてみるっす。

準備は大事っすからね。

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

動摩擦係数の測定実験で、明らかに数値がおかしいところがあるっす。

それが箱F-土台Sと箱R-土台Sのときの値っす。

FleshとRubberは摩擦係数がほぼ同じらしいということは

これまでの実験で分かってるっす。

でも箱F-土台Sと箱R-土台Sは約0.18離れてるっす。

これは明らかな異常値っす。

ここの部分だけ再実験してみるっすかね。

なんかいろいろ時間がないっすね

2010-08-04T23:26:00.003+09:00

デジアカの受講申し込みは8/19までっす。

メールを送っても返事は来ないらしいっす。

19日が受講申し込みの締め切りなので、20日になっても

グループ招待が来なければ連絡した方が良いっすね。

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

ちょっと忙しくなってきたのでリバーシAIの作成は延期するっす。

途中なので、どこまで進んでたのか分かんなくなりそうっす。

今年中に出来れば良いんっすけどねぇ。

ヤバいくらい忙しい時にはブログなんて書く暇もないっすから、

まだ「ちょっと忙しい」というレベルっす。

9月以降はここに書ける分かんないっすね。

予定がビッシリ入ってるっす。

っという内容の記事が150投稿目になったっす。

ネタを探してこないとダメっすね。

ネタは3つほどあるんっすけど…

2010-08-02T23:16:00.002+09:00

自分のTwitterのアカウントをフォローしても無駄っすよ。

つぶやかないっすからね。

どうしてもと言うならWassrのアカウントをどうぞっす。

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

しばらくネタになりそうなのは「デジアカ」「依頼品」「趣味の作品」

の3つっす。

どれもグダグダと、かつ長々と書けるっす。

叩けばホコリが…じゃないっすけど、ネタは無尽蔵っす。

とは言うものの、デジアカ関連のはソラマメに書くことに、

依頼品は完成してからブログで延長戦をしたい、

趣味の作品についてのグダグダはSLユーザーに需要が無い

……う～ん。

オフィシャルブログとかで面白そうなネタがあれば書くっすけど、

しばらくは叩いて出たホコリがメインのホコリっぽいブログになるっす。

思い出せないのか、それとも…っす

2010-07-31T23:59:00.002+09:00

bitboardに直した方が頭の体操になるっすね。

32bitの符号付き整数2つをつなげてるっすから、

妙なテクニックが必要になってるっす。

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

HUDでアバターを指定位置へ移動させるにはllMoveToTargetを

使えば簡単にできるっす。

でも、指定のrotationに回転させるってどうやるんっすかね?

座ってないっすからllSetLinkPrimitiveParams(Fast)は使えないっす。

llRotLookAtはHUD自体が回転したっす。

他の物理関係の関数を使用した場合、指定したrotationに到達したか

どうかのチェックが必要で、かつ細かく連発することになるっす。

アバターが気持ち悪い動きをするので、この方法は使いたくないっす。

llMoveToTargetみたいに簡単にできる関数を見逃してるんっすかねぇ。

それとも、そもそもそんな関数が無いんっすかねぇ?

7割書き換えるっす

2010-07-30T23:34:00.002+09:00

出来ることならやりたくなかったんっすけどね。

奥の手っす。

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

リバーシを引き続き作ってるっす。

実は探索して結果を返すところまでは出来てるっす。

でも問題は速度なんっすよねぇ。

石が4つ置かれた初期盤面から4手読みさせたところ、

平均して5.6秒かかってたっす。

中盤では同じ4手でもノードの展開数は跳ね上がるっすから

これじゃあ遅すぎるわけっす。

そこで、現在64要素のlist1つで表現している盤面を

2要素のlist2つで表現する方法に変えるっす。

bitboardってやつっすね。

わざわざlistでやるので気持ち悪いんっすけど、

LSLのinteger型が32bitなので仕方ないっす。

目標は初期盤面から4手読みで1秒以内っす。

ということは速度を5倍以上向上させないといけないっすね。

もしあらゆる手段を使ってもダメなら、深さを4から2に変えるっす。

これは最後の手段っすね。

動摩擦係数(Havok 7)っす

2010-07-29T23:37:00.005+09:00

1.40.4が全域適用されたので実験したっす。

Havok4のときの結果は前に書いたっす。

比べてみると良いっすね。(あんまり変わってないっすけど)

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

方法はHavok4のときと全く同じなのでコピペっす。

[方法]

1.llSetForceでとりあえず動かす

2.llSetForce(ZERO_VECTOR, FALSE)を実行

3.現在位置と速度を取得

4.止まるまで待つ

5.止まったら位置を確認

「運動エネルギーが摩擦力による仕事に全て変わった」として、

1/2mv² = μ'mgL

整理して

μ' = v² / 2gL

(μ':動摩擦係数, v:最初の速度, g:重力加速度(=9.8), L:移動距離)

という計算から求める。

・1セット7回の試行

・7回の試行のうち最大値をそのセットの値とする

で、10セット行ってみた結果が↓っす。

**10セット分の集計**
箱-土台	最小値	最大値	平均	標準偏差	中央値
S-S	0.558389	0.625028	0.591373	0.026299	0.588103
M-S	0.403648	0.435557	0.416047	0.011017	0.415439
G-S	0.358687	0.368062	0.361732	0.004303	0.359595
W-S	0.510505	0.565133	0.539083	0.018935	0.544879
F-S	0.532399	0.635523	0.600847	0.032738	0.601467
P-S	0.339902	0.402113	0.373375	0.019872	0.373200
R-S	0.334738	0.468658	0.416322	0.043050	0.424146
S-M	0.376186	0.443406	0.414127	0.020795	0.416319
M-M	0.256901	0.267467	0.261841	0.003190	0.262087
G-M	0.215483	0.227015	0.221312	0.003751	0.222878
W-M	0.347730	0.369481	0.356886	0.007541	0.353187
F-M	0.400925	0.445923	0.423707	0.017372	0.422570
P-M	0.313242	0.329052	0.323484	0.006252	0.325682
R-M	0.397827	0.471527	0.426896	0.026352	0.429242
S-G	0.342789	0.364226	0.353114	0.007470	0.354795
M-G	0.218975	0.226897	0.221807	0.002749	0.220832
G-G	0.178997	0.186264	0.182606	0.002791	0.181759
W-G	0.305589	0.320378	0.315749	0.005759	0.319785
F-G	0.369080	0.399671	0.381964	0.011072	0.378474
P-G	0.252126	0.270482	0.262287	0.005889	0.262184
R-G	0.363569	0.389073	0.377633	0.009121	0.378585
S-W	0.523125	0.565399	0.537925	0.015813	0.541454
M-W	0.319756	0.370439	0.350097	0.016855	0.351838
G-W	0.306236	0.327062	0.317252	0.007308	0.319103
W-W	0.452460	0.504664	0.471510	0.018114	0.464441
F-W	0.488737	0.567489	0.528534	0.025983	0.525334
P-W	0.416600	0.446154	0.428300	0.012415	0.424277
R-W	0.469199	0.536698	0.511458	0.024257	0.514511
S-F	0.572372	0.632154	0.599994	0.019148	0.600879
M-F	0.400892	0.437555	0.422820	0.012406	0.428644
G-F	0.358422	0.394345	0.371395	0.012178	0.374071
W-F	0.505438	0.550946	0.525378	0.015940	0.525057
F-F	0.603197	0.675531	0.628161	0.023074	0.623332
P-F	0.451103	0.509668	0.478783	0.022862	0.471104
R-F	0.589573	0.655833	0.611079	0.023804	0.616158
S-P	0.372899	0.402781	0.387664	0.009097	0.389129
M-P	0.310546	0.331952	0.319970	0.006468	0.319418
G-P	0.259572	0.268057	0.264639	0.002960	0.264829
W-P	0.406565	0.447081	0.424840	0.013214	0.427467
F-P	0.435581	0.489691	0.475577	0.019960	0.481683
P-P	0.346188	0.366909	0.359167	0.007030	0.359720
R-P	0.477034	0.518234	0.498277	0.012790	0.500961
S-R	0.401700	0.458935	0.426180	0.022779	0.414204
M-R	0.407225	0.429482	0.421081	0.007993	0.422630
G-R	0.346984	0.364003	0.355765	0.006245	0.353202
W-R	0.490846	0.566586	0.529422	0.025313	0.530752
F-R	0.591343	0.642965	0.611081	0.021990	0.603284
P-R	0.482538	0.509736	0.497900	0.011063	0.500562
R-R	0.612431	0.647615	0.631416	0.013400	0.630602

llDeleteSubListとllList2Listっす

2010-07-27T22:13:00.004+09:00

listを扱う関数に同じようなのがあるっすね。

今回のタイトルの通りっす。

正解かどうかは別にして、自分なりの使い分けを書いておくっす。

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

"Delete"と付いてるので渡したlistも変わっちゃいそうなんっすけど、

実際にはコピーを渡してるので元のlistには変化がないっす。

というわけで、2つの関数は同じことをしてるわけっす。

自分の使い分けは

別のlistに代入するときはllList2Listを

元のlistの要素を削除するときにはllDeleteSubListを

という風にしてるっす。

2種類とも使ってるっすよ。

例えば、ギザギザリストを番兵を使って作ったとするっす。

list a = [1, 2, 3, -1, 4, 5, -1, 6, -1, 7, 8, 9, -1];

みたいな感じっす。これは-1を番兵としてるっす。

これを区分けして処理していくことを考えるっす。

　[1, 2, 3]

　[4, 5]

　[6]

　[7, 8, 9]

としたlistを取りたいわけっす。

ここで自分ならどうするかというと、

integer sentinel; // 番兵のインデックス
while(a) // while(llGetListLength(a) != 0) と同義
{
   sentinel = llListFindList(a, [-1]);
   処理(llList2List(a, 0, sentinel - 1));
   a = llDeleteSubList(a, 0, sentinel);
}

こうやるわけっす。

(色付けはhttp://lsl-users.jp/codehighlight/を利用したっす)

なんとなく雰囲気は伝わったと思うんっすけど、どうっすかね？

無事帰還っす

2010-07-25T22:16:00.002+09:00

帰ってきてくれると信じてたっす。

むしろ帰ってくるのは分かってた、という感じっす。

分かっていたとしても帰ってきてくれると嬉しいもんっすね。

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

リバーシのAIの話っすよ。

何か別なことを想像したりしてないっすか？

再帰呼び出しで探索をしてたんっすけど、returnされてこなかったっす。

予想通り無限ループが発生してたっす。

簡単に説明すると、盤面を走査してるときに同じ場所ばっかり調べてたっす。

iとjでそれぞれタテとヨコを調べてるっす。

ループで回してるっすから、これでナナメも走査できるっす。

for(i = -1; i <= 1; i++)

{

　　for(j = -1; j <= 1; j++)

　　{

　　　　その方向にひっくり返る石があるか判定(石の位置, i, j);

　　}

とまぁ、ざっくりこんな感じのことをやってたっす。

判定関数の作り方がマズくて、i=0,j=0のときに無限ループっす。

対処として、i=0,j=0を除いてループを全部書き下したっす。

8方向についてだけっすからラクに書き換えられたっす。

ループじゃない分、ちょっとだけ速くもなるっすからね。

さらに今日はもうちょっと進んだっす。

初期盤面からの探索で、正しい着手可能点を返してきたっす。

盤面評価がいい加減でも、とりあえず探索できたっす。

あとのチェック項目は

　・パスの処理

　・終局の処理

　・評価関数の強さ

　・全体の実行速度

とりあえず大きいのはこんなところっす。

今日はかなり進んだ気がするっす。

行ったまま帰ってこないっす…

2010-07-24T23:09:00.002+09:00

デジアカの生徒募集が開始されたっすね。

募集は来月19日までなので、お早めにどうぞっす。

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

帰ってこないのはヒトじゃないっすよ。

ネガアルファ法で探索させようとしてたんっすけど、

怪しげなループに陥っていて、抜け出せないまま帰ってこないっす。

これくらいのバグは想定内っすけどね。

作成中のリバーシのAIの話っす。

考えられる可能性はたくさんあるんっすけどね。

一番下のノードに到達したのに判定を誤ってるとか、

途中の処理で無限ループが起きてるとか、いろいろっす。

要は凡ミスしてる可能性が大っす。

ちょこっとずつ直していくっす。

土日で仕上げるっす

2010-07-23T22:05:00.002+09:00

viewer2.1.0 (207030)を入れてみたっす。

今のところ不都合は無いっす。

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

一気にリバーシの探索部分を書き上げたっす。

書いただけなのでバグ取りはまだっす。

一発OKなんてのは期待してないっす。

地道に潰していくっす。

LSLでネガアルファ法を実装したことのあるヒトは

世界でも10人いないんじゃないっすかね？

そもそも再帰なんて使わないっすからね。

入力用のテストデータを作って休みのうちにカタチにしたいんっすけど、

たぶん無理っすね。

評価関数の手直しもしたいっすからね。

プリム数は減らさないっす

2010-07-22T23:22:00.003+09:00

Viewer 2.0.1からベータが外れてたっすね。

ビューワについてはあんまり書く気はないっす。

たぶん他の方が書いてるっすからね。

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

リバーシのAIを書いてるっす。

大体想像できると思うっすけど、一般的なスクリプトに比べて、

とんでもなく容量を食ってるっす。

合計すると全体で100KBを余裕で超えるっす。

もちろんMonoコンパイルでの話っす。

数値計算が主なので重い処理はほとんど無いんっすけどね。

でも、これだけ容量を食ってると何か対策が必要かもっすね。

http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_10_21

メモリ消費量について話が出てたので紹介するっす。

ポイントを書き出してみるっす。

・1つのFull Regionには800MBが割り当てられている

・Regeion内のアバターもオブジェクトも、このリソースを使う

・アバターのメモリ使用量の99パーセント点(※)は10MB

　(※ パーセント点(percentile)は百分位数のことで、

　　パーセンテージとは別物なので注意っすよ。

　　ざっくり言えば上位1%は10MB以上使っていて、

　　その他の99%の使用量は10MB以下ってことっす)

公平にリソースが分配されたとき、その範囲内であれば文句無いっすよね？

ということで、「プリム数あたりのメモリ消費量」を指標としてみるっす。

リバーシは装着型じゃないっすから、これを使うっす。

装着型のオブジェクトには別の指標が必要っすね。

先のリンクの内容から許容範囲を出してみるっす。

Full Regeionの場合、まず、800MBのうち400MBをアバターに、

残りの400MBを土地のオブジェクトに割り当てるっす。

400MBは99パーセント点上のアバター40人分になるっす。

その残った400MBを平等に分配するっす。

つまり15,000で割れば良いっすね。

400MB / 15,000prims ≒ 27KB/prim

っていう値が出るっす。

HomesteadはFull Regionの1/4のプリム数っすから、

メモリリソースを4つのHomesteadで共有してると仮定すると

Full Regionと同じ27KB/primっていう値が出るっす。

(800MB / 4 = 200MB

200MB / 2 = 100MB

100MB / 3,500prims ≒ 27KB/prim)

これはギリギリの値なので、もっと下げないといけないっす。

どのくらいからパフォーマンスに影響するのか分かんないんっすけど、

とりあえず半分くらいにして、キリの良い値を指標には使いたいっす。

というわけで、自分の指標は

上限は16KB/primで、可能な限り8KB/primに抑える

にしたっす。

プリム数を増やして、割合としてのメモリ使用量を下げるっす。

リバーシが全体で130KBとすると65primsで2KB/primっすね。

これくらいなら大丈夫…なんっすかねぇ？

リムーブの活用法っす

2010-07-20T23:49:00.002+09:00

やる気が出ないのは暑いからっすね。

でも別な理由があるような気もするっす。

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

ここら辺においてある、テクスチャ・チェンジャーで販売もしたいっす。

Pay/moneyイベントを使えば出来るんっすけど、

ちょっと違った方法も考えてみたっす。

現状、SLPPFとかのリンク周りの関数で作ってあるっす。

そこのところを変えて、リンクじゃなくてSay/listenでやり取りするっす。

こうすると商品部分と切り替え部分が分割されて、

Payじゃなく、Buyで購入できるようになるっす。

テクスチャ・チェンジャーをまるごと販売するわけじゃないっすから、

Buyでやるときはこうなるっす。

注意が必要なのは「コピー」を販売するようにすることっす。

「コンテンツ」じゃ中に入ってるスクリプトを販売することになっちゃうっす。

でもこうすると、商品の中にスクリプト(listenして形状を変える)が

残っちゃうっす。

そこで登場するのがリムーブっす。

リムーブが便利なのは自身を対象にできて、自爆できるっす。

llRemoveInventory(llGetScriptName());

と出来るわけっす。

llDieと並んで地味に使えるっすよ。

リムーブするタイミングなんっすけど、購入後初めてRezした時に

やることになるっす。

on_rezイベント中で記述するわけっすね。

「オーナーとクリエーターが異なるならリムーブ」

としておけば良いっす。

この方法の長所と短所をまとめると

長所:

　・Buyの安心感・安定感

　・切り替え部分は使い回しが可能

短所:

　・スクリプトの本数が増える

　・Say/listenを利用するので混線対策も必要

　・購入時には商品中にスクリプトが残っている状態

　　→一度もRezしないまま、別のオブジェクトのコンテンツに入れると

　　　　on_rezイベントは起きず、スクリプトも残ったままになるっす。

　　　　でも、どうせ使うときにはRezするっすから問題ないっすよね?

　　　　ただ単に気持ち悪いだけっす。

結論:なんだか面倒なので、普通にPay/moneyでやるべし

CAっす

2010-07-19T23:45:00.002+09:00

デジアカの受け付けが間もなく始まるみたいっす。

でも実際に講座が始まるのは9月からなんっすよね…

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

CAはセルオートマトンの略っす。

何なのかは調べてくださいっす。

モデル化したのを実際に動かして、さらに可視化するのには

SLのオブジェクトはなかなか使えそうっす。

あんまり複雑なのが出来ないのが難点っすけどね。

まず手始めにECAのルール224を作ってみようと思うっす。

モチベーションが上がらないので、いつ完成するかは分かんないっす…

if文に直接ぶち込むっす

2010-07-16T23:44:00.003+09:00

サーバー1.40.4のアナウンスがあったっすね。

20日にいつも通り20%適用、28日に全域適用らしいっす。

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

面白そうなネタを見つけたっす。

http://wiki.secondlife.com/wiki/If

単なるif文の説明なんっすけどね。

日本語での説明もあるっすよ。

if文の条件式のところにはstring型とかも直接ぶち込めるっす。

とっても気持ち悪いんっすけど、使い道もありそうっす。

例えば以下は同じ結果を返すっす。

[A: string型のパターン]

　if(llStringLength(str_test) != 0)

　if(str_test)

[B: list型のパターン]

　if(llGetListLength(lst_test) != 0)

　if(lst_test)

http://wiki.secondlife.com/wiki/LlAvatarOnSitTarget/ja

にも書いてあるんっすけど、key型の使い道もあるっす。

直接ぶち込むif文も慣れた方が良いんっすかねぇ。

また作り始めたっす

2010-07-14T23:42:00.002+09:00

ここ2週間ほど更新のペースが遅かったっすね。

それでも週3ペースなんっすけどね。

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

作りかけのを完成させるべく、コツコツ作ってるっす。

モノはリバーシのAI部分っす。

ヒトvsヒトのは既にたくさんあるっすけど、vsオブジェクトは無いっす。

強いのは64kb制限とか速度の問題で作れないっす。

でも弱いのなら作れなくもないっす。

ただ超面倒なだけっす。

進展があったのは「評価関数」の部分っす。

無理をして2種類の評価関数を組み込んだっす。

LSLで作るものとしては豪華仕様っす。

速度は低下するんっすけど、ちょっとでも強くしたいっす。

予定としては中盤までは4手読み、最終盤6手完全読みっす。

置ける場所を考えるとどちらも1,000パターンまではないっす。

これがギリギリの線じゃないかと思ってるっす。

10月のアレまでには完成させたいっすねぇ。

連絡が来たっす

2010-07-12T21:16:00.002+09:00

まだ詳細について煮詰まってないみたいっすけど、

判明してるところまで書いておくっす。

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

デジアカの件っす。

スケジュールについて、ちょっと進展があったっす。

8月中旬に入校式

9月から講座開始

ということらしいっす。

7月中に講師の方で一度集まることも予定されてるっす。

もうすぐ募集も開始されるみたいっすよ。

まだ時間に余裕があるので、作りかけのを作っちゃうっす。

SLマーケットプレイスっす

2010-07-10T23:23:00.002+09:00

メールが来てたっすね。

でもマーチャント(出品してるヒト)にしか届いてないかもっす。

知らないヒトも多いんじゃないっすかねぇ。

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

マーチャント、つまり売り手の方から見てみるっす。

買いやすいかどうかは、いろんなところで書かれてるっすからね。

https://marketplace.secondlife.com/

これが新しいSL Marketplaceのページっす。

商品などの設定を変更したい場合は、ログインしたあと、

マーケットプレイス→マーチャントのホームページ

と進めば変えられるっす。

ここはXStreetSLとほぼ同じ感じっすね。

自分が一番の違いを感じたのは「マイストア」の存在っす。

XStreetは自分の[名前]で販売することになってたんっすけど、

それとは別に、[ストアの名前]を付けることができるっす。

[ストアの名前]の他にも[プロフィール][ポリシー][ブログへのリンク]

なんかも、ストア情報として書けるっす。

[プロフィール]は2,100文字、[ポリシー]は450文字っていう

制限はあるんっすけどね。

少なくとも8週間はXStreetは無くならないとメールに書いてあったっす。

でも早いうちにSLMarketplaceに慣れた方が良いっすね。

(というのもメールに書いてあったっす)

なんと、今月14日まではコミッション・フィー(販売されたときに

支払う手数料)が無料になるということなので、

商品を買われる方もSLMarketplaceで買うと、

制作・販売者が喜ぶかもっす。

サーバー安定化についてのごにょごにょっす

2010-07-07T23:10:00.002+09:00

そろそろ今年のLSLCONについて動き出さないとっすね。

去年は一応「成功」なので、去年と同じ感じになると思うっす。

いや、まだ分かんないっすよ?

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

近頃、予定が狂いまくってるっす。

ぽっかりと予定に穴が空いて、暇っす。

モノはいろいろ作ってるんっすけどまだ余裕があるので、

オフィスアワーのログを漁ってみたっす。

あんまりチェックしてないBeta Server Office Hoursのログを

久しぶりに見てみたっす。

ナナメ読みしたので「いつ」に関する記述は見つけられなかったんっすけど、

サーバー1.42と1.44について書いてあったっす。

http://wiki.secondlife.com/wiki/Beta_Server_Office_Hours/Minutes/2010-04-15

サーバー1.42: TCMalloc

サーバー1.44: Mono 2.6

これがキーワードっす。

新機能というよりは安定化・高速化に関するアップデートっぽいっす。

しばらくは見た目が地味なアップデートが続きそうっすね。

今日は書くこともないっすね

2010-07-05T23:25:00.006+09:00

wikiを漁ってたら、llGetAgentInfoにAGENT_AUTOPILOT

なんてのが増えてたみたいっす。

オートパイロット状態を検出して、何するんっすかね?

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

今日は「書くことがない」ことをネタにして、無理やり書いてるっす。

無いもんは無いっす。

ロールバックされなければ動摩擦係数のこともあったんっすけどね。

次、いつ1.40が戻ってくるのかのアナウンスも出てないっす。

実験は中断っすね。

Havok 7といえば、FJ Lindenさんがblog書いてたっすね。

http://blogs.secondlife.com/community/features/blog/2010/07/01/upgrade-of-second-life-to-havok-7

Havok7になってフレームレートが増加した、って書いてあるっすね。

ぬるぬる動くようになったわけっす。

デフォルトの箱を物理にして、ドラッグで移動させても体感できたっす。

今はロールバックされて…

なんか皆さんビューワの変化に一喜一憂してるみたいっすけど、

サーバー側の変化には鈍いみたいっすね。