球も出来たっす

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

これで折り返しっすね。

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

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

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

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

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

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

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

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

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

詳細度: 低

詳細度: 中

詳細度: 高

Hira 3D Viewer

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

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

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

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

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

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

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

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

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

・形状データ送信

[本体]

・制御

　　・プリムの存在確認

　　・形状データ受け取り

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

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

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

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

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

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

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

Hira 3D Viewer

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

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

やっぱり容量の壁っす

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

調べてみたっす。

どうもぺんぎんっす( ◎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度で増えるっす。

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

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

経済的な箱っす

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここまでやるっすかね？

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

順調ではないっすね。

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

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

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

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

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

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

書き出しが

0

SECTION

2

ENTITIES

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作戦は

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

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

3.ブラウザで開く

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

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

6.加工

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

8.SLへ

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

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

算数勝負っすね。

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

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

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

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

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

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

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

これを調べてみるっす。

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

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

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

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

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

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

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

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

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

結果が気になるっす。