2015年12月19日土曜日

Project 弁当?

https://community.secondlife.com/t5/Featured-News/Introducing-Project-Bento-New-Bones-Added-to-Second-Life-Avatar/ba-p/2987206


ざーっと見た感じだと

アバター装着物系でエクストラボーンを複数開放するらしい

アバターだけで置物にはなさそうだな

てーとまぁメインの対策先は

全部のポーズを形状で作ってリンクして
超高速でアルファ切り替えしてアニメさせてる
クソ重いアバター作ってるメーカー

だなもう

あのへんをビューワーサイドレンダリングにしてやればものすげー軽くなるんはわかってるし

問題はエクストラボーンの記述方法だけど
bvh拡張するのかスクリプトでテーブル直接ぶっ叩く方式とどっちだろな

数と位置を固定しているということは前者かねぇ

以上

2015年10月22日木曜日

LSL外部エディタとして秀丸を使うお話 (Gitは現状では無理ぽ)

ドーモ秀丸原理主義者です

世の中にはvim原理主義過激派みたいなめんどくさいのが居るらしいですが

こちとらもう10年以上秀丸使ってるっちゅうねん



LSL外部エディタの設定って
まぁ初期はほんとまともに使い物にならんかったわけよ

今もデバッグセッティングから設定必須だったりして微妙だけどw



んでまぁ
今回の最終目標は
秀丸でのスクリプトエディットの実用化と
Gitでのバージョン管理だったわけなんだけど

gitはかなり大掛かりなビューワー改造しないと
そもそもスタートラインにすら立てない感じ


スクリプトファイルの名称がSL_script_(UUID).lslなので
複数ウィンドウ開くとタスクバーで判別がつかんし

生成先がOSの一時フォルダに階層無しでぶちこまれてるので
既存のツールで最低限で済ます 的な運用では割とどうにもならん



・外部エディタの設定方法

デバッグセッティングの該当箇所にエディタのフルパスを指定
多分マルチバイトOSだとダブルコーテーションが要る

http://wiki.secondlife.com/wiki/Debug_Settings

ちなみに項目名は"ExternalEditor"これな


ちなみにこれで外部エディタ開くと

user\xxxx\appdata\local\temp

辺りにUUIDのファイル名で生成されたのが開かれる

firesotrm系なら別フォルダに書き出して修正とかも出来るんだけど
書き出したファイルを修正してビューワーでロードしてコンパイルしてなんて悠長なことは

リアルタイムでテストしながらデバッグしてる環境だとぶっちゃけ使い物にならんので

(あーでもgit利用するだけならファイル書き出しでもいけるか 考えとこう)

基本的に外部エディタに同時に投げられるのは3つくらいまでと思っといていい



・外部エディタを使う際の注意点

Loadingで外部エディタ開いたらファイルがぶっ壊れて死ぬ 解決策一切なし アキラメロン

ノーマル系のビューワーならeditボタンがそもそもloadingでアクティブにならないんだけど

firestormだとメニューバーについちゃってるので誤操作が危険過ぎる




・秀丸でLSLをエディットするお話

まー世の中にはものすごい便利なものがあってだなぁ

秀丸 LSL でググるとこいつが出てくる

LSL用強調表示定義 Ver.2

ぶっちゃけこれ導入するだけでものすげー便利になる
こいつの機能

1.関数や定数の強調表示
2.ユーザー関数やスクリプトステートへの一発ジャンプが可能なツリー表示

このふたつが使えるようになる

あと適当にジャンプ用のインデックスもツリーに登録しとけば
機能ごとのコードにダイレクトジャンプできるのでチョー便利
新関数とか対応大丈夫なのかよとか色々と危惧してたんだけど

その辺は秀丸の強調表示判定がものすごい優秀なので問題なかった

実際のエディット画面はこんな感じ


実際に使うとフォントサイズとかも可変だし標準エディタみたいなカーソル崩壊も無いので
作業快適性がものすげー高くなる

あと適当につまづいたところを抜粋

1.カーソル行の強調表示がウザイのでデザインのとっからカーソル行のチェックをOFF

2.標準だとダブルスラッシュのコメントアウト対応してないので
   複数行コメントんところの言語設定を自動判定から言語指定で"C言語/Java"を指定

3.タブの文字数が8になってるので4に

4.アウトラインの解析んところに適当に行ジャンプ用のタグを指定すると便利

5.SSに使われてるのはメイリオの等倍化フォント(やり方はぐぐってくれい)




だいたいこの辺かな

以上

2015年8月25日火曜日

SL課金難民の方向けのお話(Skrill決済)

ATMで買えなくなった方向けのお話

前提条件

・クレカが無い

・銀行口座はある

・多少英語は出来る

んでまぁ詳しいことは全部ここに書いてあった
解説が面倒なのでリンクのみね


ここ見りゃ多分なんとかなる

以上

2015年8月15日土曜日

またVプリカダメになったっぽい

一時期認証プロセスが一部省略されてたんだけど

また例の1ドル請求して生存チェックするやつが稼働してるっぽい

ちゅわけでやっぱ確実性取るなら楽天のVISAデビッドかねぇ

以上

2015年8月10日月曜日

blender 2.7 とPrimstar2 の組み合わせで出力データがぶっ壊れる場合の対処法について

どうもなんかファイル形式によるものっぽいんだよなぁってのが確定して解決したので記録

ファイルがぶっ壊れる現象について

・2.7で普通にrender sculpt maps すると2.6同様の形状でアルファマスクされた画像が生成される

・このファイルをtga raw もしくはtgaでそのまま保存するとぶっ壊れる

・pngで保存してもぶっ壊れる

・ぶっ壊れる現象としては
 tgaの場合アルファ部分が黒つぶれを起こす
 pngの場合アルファ部が白飛びを起こす



んで解決策

保存方式にRGBAを指定して
tgaもしくはpngで保存

こんだけ

ってかこの現象のせいで一年近く2.65a使うはめになってたのが解決した

これで複数のバージョンのblenderを管理する必要がなくなったので
多少作業効率とかが改善するかねぇ


以上

KFMでスプライン曲線のお話

チャットログを適当に編集


http://opentype.jp/fontguide_doc2.htm
まぁ演算的にはこういう話っぽい

で。まぁ数学的表現 のところ見る感じだと 点1と点3に接線が定義されてればそっから交点座標出して数式通せば出来ないことはなさそうだなぁ


うちの鉄道車両がガイドオブジェクトのvectorから二等辺三角形近似して円軌道算出してるんだけど

多分この演算実装出来りゃかなりスムーズに出来そうだなぁ vector2つから交点算出する部分だけは新造が必要だけど
基本全部四則演算なので不可能ではないな
ただこれ交点座標の計算が骨だなぁ

ミサイルの場合二点のスプラインだとオフカーブ点の決定どうすんだよこれ
鉄道ならガイドオブジェクトの交点をオフカーブ点にすることで簡略化出来るけど ミサイル誘導の場合オフカーブ点を任意生成出来ないから

あー

今の進行方向ベクトルとターゲットとのベクトル拾って二等辺三角形作って近似か?

出来ないことはないなぁ

んー 生成レートはせいぜい1秒ごとかねぇ
スプライン生成して接線vectorからrot算出して ってなると

ちなみにKFMって
知っての通りmovetotargetと rot2targetをリストで記述する方式の命令ね
しかも指定するvectorとrotが"その時点の位置からの”相対記述になるので
スプライン曲線の分割レートによっては
んー10m移動でループ5回くらい使えば実用で十分かなぁ

乗り物だとせいぜい10m/secくらい? もっと遅いか
まぁ2.5m/secだとして4秒 計算量的には余裕で間に合うなぁ

ちょっと現物見てみないとなんともいえんなぁ

参考になるかどうかわからんけど
SLRRって知ってるでしょ
あれの走行制御で一番高度なことやってるのが確かにKFMでスプライン曲線だけど
売ってない
んで一番普及してるのが多角形移動のやつ
てな辺り



大体この辺

以上

2015年7月3日金曜日

台形の当たり判定の演算方法についてメモついでに検討

ちょっとメモついでに検討します

Y値をノーマライズかけた0から1のfloatとする

(上底/下底) まずこれが必要 Y値がmaxんときはこの比率そのまま掛けちゃっていい

あーそうか

((上底-下底)/相対Y値+下底)/下底  か なるほど

以上

2015年5月31日日曜日

プレ垢のグループ枠が拡張されたっぽい話

なんか枠が40から60になってるね

以上

llCastRayの対象判定の高速化とかエラーレート改善の話

llCastRay自体の基本的なところはこっち参照

http://ueponya.blogspot.com/2014/03/blog-post.html

実際のソース無しで概念的な部分だけ適当に

・検出開始の最低距離は24m辺りから

何故か知らんのだけど初期検出チェックを64mとかでやると
特定角度で実際にはオブジェクトがあるはずなのに
未検出になる微妙な角度と位置ってのが存在する

これを回避する方法はvectorを短くするくらいしか無い



・対象物検出はSensorではなくllGetObjectDetailsを使う

http://wiki.secondlife.com/wiki/LlGetObjectDetails/ja

Sensor使う方がサンプル多くてちょっと簡単なんだけど
イベント発生レートとか考慮だとちょっと面倒なので

llGetObjectDetailsの OBJECT_OWNERとOBJECT_RUNNING_SCRIPT_COUNT

この2つを使う方式が多少応答速度アップになります

対象物がAGENTだとオーナーUUIDがidと同一になる

対象物がオブジェクトの場合OBJECT_RUNNING_SCRIPT_COUNTが

0ならスクリプトなしの静的オブジェクト
コリジョン用のタマをrezしないことで軽量化が見込める

1以上ならスクリプト入の動的オブジェクト

大体この辺


以上

2015年4月1日水曜日

ヴィークル関係の愚痴

偉い人が言いました

"正義であるためには勝利し続けなければならない"



まぁあれよ 読む気があるなら所詮負け犬の遠吠えだと思って読むのが吉



何度か書いてるけどねー

今ちょっと調べたら最後にフルスクラッチで全部作った車両から4年近くたってんのなぁ
そりゃ旧世代になるわなぁと思ったんだけど
操縦性の体感的には実際んとこそこまで世代落ちてないんだよな

(例のバイクは気が向いた時にコリジョン調整してるけど結局一台しか売れてないし)

meshで作れる連中がランドインパクトの限界を結局どうにも出来なかったのと
あとは結局ヴィークルのスクリプトで2010年移行劇的な変化や発明は全く無いのよ

というか元から出来る奴となんとかごまかせてた連中との開きが顕著になった
んで出来てる奴もMMDとかUnityとかUE4とかの
ラグナロク(神々の黄昏)がおきてみんないなくなっちゃった

んでまぁスクリプトのアイディアレベルでどうにかなるような革新が出来たのが
せいぜい2010年くらいまでで

それ以降はほんともうなんというか

どれだけ外装のディテールやエフェクトや演出の質を上げて
スクリプトを軽くしたり機能を満載するか
とか

どれだけ優秀なベーススクリプトとガワを調達してくるか
みたいなところばっかりで

スクリプトのロジックやら物理現象の数式的なハックやらは行われていない
というか物理制御部分は一部の門外不出連中以外は
2007年くらいに組まれたスクリプトをずーっと使ってるのよな
(実際にどんなスクリプトかってのは前に書いてるから省略)

組める奴に依頼すりゃいいじゃんってのも順当な発想なんだけど

ほんとにまともに出来るやつに依頼するなら100万L$単位の額か
もしくはものすごい強力なコネが必要だったのよ

2500L$で400台とか売ってやっとトントンくらいよ

まぁなのでKCP-ACSがバカ売れするんだけどな
(少なくとも使えて出せてる連中は口だけ番長で出せてない奴よりはマシ)

あとまぁ最近登坂性能とかその辺で注目されている
トルクコントロールの技術も
原理自体はものすごい単純で結構楽にに実現出来るんだけど
(そこも2010年くらいには基礎理論があって実装までいってる)

実装するためには基本的な運動特性制御がif-elseゴリ押しじゃなくて
f(x)関数の数式コントロールになってないとあかんので

一般的な実装だと最高速と加速時間を
全部のギアでトライアンドエラーで手動設定してるか
加速力特性の制御を諦めてる

まぁその辺を簡易なパラメータ一覧で制御出来る
ブラックボックスでも作れればいいんだろうけど
作ったところで売れる見込みもないし
知り合い連中は全員自前スクリプト持ってるか
買い入れ品ぶちこんでるからな的な

長いなこれ

とりあえずトルクの理論

vhicle_liner_motor_directionだったっけ
のxを必要な加速度(m/sec)で割ったのをtimescale(t)に入れればいい
ただしtimescaleが0.1を下回ると0.1にクランプされるので
(t)が0.1を下回る場合はvelでリミットをかけつつ(m/sec)*0.1を
motor_directionに指定してやることで低速トルクが実現できる

あと最高速度が結局200m/secくらいまでなので
所謂非常識なタイムを出すクルマのような何か みたいなのはまた別の理論体系になるかの


ってな辺りかな

以上

2016.02.08

ある程度 簡単にわかる完全にダメなショップの見分け方

まぁテンプレみたいなものがあるのよ

・パイプフレームで運転席の上に機関銃乗ってるバギー(BattleFieldもしくはHalfLife)

・側面に赤と青のラインが入ってる白い発電機 もしくは投光機(L4D2)

すく無くともこの2つは有名なripped品なので ラインナップにあったら全力で避けろ



・フェ○ーリの市販モデル(レースカーは微妙w)

・背景が単色かsandboxのSSで 文字が一切無いやつ

・meshなのにいかにも旧型ビューワーで撮った感じのSSのやつ

・なんかやけにモデルの出来はいいんだけど安いやつor Mesh!ってでかでかと書いてる奴

・自動車とか銃ならメーカー名と商品名そのまんまのやつ

・規格もののパーツの寸法が明らかにおかしいやつ

・いかにも素材かき集めました系の見た目なやつ

この辺は多分SLで所謂"ビジネス"をやろうとしてる連中

そいつら自体がアウトなモデルをアップロードしたかどうかは不明だが
使われてるモデルデータはほぼ全部アウトなので避けろ

簡易の見分け方としてはこの辺

以上

今更RLva関係の話

メモ程度に

尺 一 八 に抵触しないために色々と伏せます

Rlvaの制御がどこまで出来るかってのを見るためにプロジェクト セッ(略)を使用

通常のセッ(略)ベッドみたいに家具据え付けではない
位置調整とかがカメラ回転でかなり直感的に設定が行えるタイプ

とりあえず単品での動作は確認した

RLva設定はCoolVLで RPをとりあえず設定 noBD○Mでは制限が多すぎる模様

Rlvaは制御用のリレーオブジェクトはどうも必須らしい
(パーミッション関係の取得をスムーズに行うためっぽい)

こいつの場合

・スタンドアロンモード(単独動作 通常はこれを使用)

・同じ店で売ってるセルフプレイシステムとの連動?

・行為を致す場所をカメラ回転で設定可能 制御持ちは片方

・オートボタンとかゲージとかキーコントロール対応とかなかなか現代的な機能がある



んでまぁスタンドアロンモードが動作するまでの部分
正直Rlvaの初期セットアップがいまいちわかってなくてすげー手間と時間食ったけど
一回使い方のルーチンがわかってしまえば次からは装着のみでおk

1.タッチセンサープリムを装着

2.メインHUD(透明)を装着する

3.制御HUDがくるので装着する

4.相手にリレーを渡して準備完了


適当にターゲット指定して最初の技を選択すれば開始

技のバリエーションは

・スタンド前から

・スタンド後ろから

・寝技前から

・寝技後ろから

・壁

・椅子

・適当に高さのある台(机とかその辺)

だいたいこの辺

位置調整が技ごとじゃなくてカテゴリーごとなので調整が楽かも?
基本もう自動で動くのでセットアップ終わったらキーボードから手放しでおk(意味深)

あと適当に気づいたこと

・たまーに操作レスポンスが非常に悪いことがある
  数秒フリーズとかそんくらいのレベル

・RLva使ったことないと初期動作までがかなり難しい
 ってか日本語チュートリアルどっかないのかね
 そのうちmokyuさんところででもやらんかねぇと(ぶん投げ)

・カメラ制御は無い ビルドイン系でもやってるのを見たことないから
 多分業界?系でそこを実装しないほうが便利がいいとかそういう方向なのでしょう

・多分アニメヘッドのエモート制御対応したら多分神ツールになるっぽい?


だいたいこの辺

以上


とりまL$引き出しに関して適当に

買う方はぶっちゃけクレカ登録すりゃいいだけなんだけど

L$売って引き出すには結構周到に前準備しないとダメっす



準備するもの

・クレカとして支払情報が行えるカード(一部VISAデビッド可)

・Lindex公式でのL$購入実績(とりあえず10ドル分くらい)

・郵便認証を済ませたpaypalアカウント(本名登録 プレミアム推奨)

・必要に応じて免許証等のスキャン

・ちゃんとしたアカウント情報(でたらめな情報が入っている捨て垢は不可)

 ただしL$引き出し用に新しいアカウント作ってそこに大量送金すると
 アカウントホールドされる場合があるので事前にチケット切るとか推奨


大体この辺

通常の引き出しで大体通しで10日かかります

事前準備を怠ると三ヶ月前後かかる場合があります

手数料諸々考慮すると引き出しは550ドル(14万L$程度)以上がオススメ

最小は100ドル前後くらいでもいける


手順

前提条件としてpaypalアカウントの郵便認証は済んでいるものとする


①まず支払情報にpaypalとクレカを登録します

②どっちでもいいので10ドル分程度のL$を買います

③支払いが通ってL$がチャージされてから即時もしくは数日でL$売りリミットが開放されます

④リミット開放されたら適当にL$を売ります
   急ぐなら32000L$単位くらいを 248L$/1US$ くらいがええかと 数時間から数日で終わります
   L$売れた段階で手数料引かれます この手数料が リンデンの主要収入源の一つです

⑤アカウントにUS$がチャージされるので確認する
  上記のレートで売ると120ドル前後になるはず

  ちなみにチャージされているUS$はプレ垢や土地代の支払いに使えます
  売上だけでSIM維持してる云々の話は大体この辺

⑥資金の処理を行います
 paypalアカウントへの送金は大体一週間前後かかります
 ここで手数料が1ドル前後取られるのである程度まとまった額推奨

⑦paypalアカウントに送金されます
 paypalは日本円でのアカウントチャージが出来ない仕様なので
 アカウントにはUS$でチャージされます

⑧銀行口座への引き出し
  500ドル以下だと250円の手数料がかかります 大体一晩かかります

⑨銀行口座に入金されて(゚д゚)ウマー

大体こんな流れ

ストレートで大体10日かかります


完全にゼロベースで開始する場合一番手数が少なくて済むのは
ジャパンネットバンクか楽天銀行のVISAデビッドカードっす

楽天銀行のVISAデビッドは手数料かかる糞仕様になっちゃったので
今から取得するならジャパンネットバンクかねぇ



イレギュラーな事態について

現状知られている限りでイレギュラーな事態



・リンデンへの書類の提出が必要になる場合
 所謂身分証明とかその辺のお話
 これは運転免許証かパスポートのスキャンが必要です
 スキャンがあれば手続き自体はペーパーレスなので割とすぐ終わります


・paypal認証にネットバンク以外の口座が必要になる場合

 実店舗持ちの銀行口座の情報が必要になる場合があります
 大体地方銀行の口座でおk ゆうちょは不明


・paypalの認証をせずに送金してしまった場合

 これはなーんのアクションも無しで静かなエラーになります
 一回これになっちゃうと事務手続き等で三ヶ月覚悟すること


 まぁなので最初は100ドル前後を送金して流れとかを把握するのも手




ってな辺りかな
以上

某アレの名称は NextGenerationPlatform らしい

パトレイバーじゃないよw


いまんところのお話

・NGPにSLのリージョンが内包される形となるらしい?
  (しかしPlatform同士の互換性はないとのこと)

・とりあえず今のSLが"いきなり"死ぬはない

・とりあえずC#(まぁ.netが使えるという意味では無い?)

・とりあえずプリム互換性は100%ではない(LSL使えないので)

・とりあえずMayaのみ対応(次はスケッチアップ Blenderの順番らしい?)

・とりあえず今年の夏アルファ(ベータは半年から一年後?)

・とりあえずアセットは完全新規(買い替えは死ぬだろうなぁ)

・とりあえずL$は未定(未定)

・SIMの面積拡大と収容人数アップ?(リミッタでもつくのかね?)

・inworld用のボクセルモデラー?(minecraft系かZbrush系かどっちだろね)

・アバターモデルが更新?

ってな辺り

以上

2015年3月17日火曜日

スクリプトのお話 2015春版

ぼちぼちSNSとか各種ネトゲが荒れる時期となってまいりました(笑)



記録ついでに現状のスクリプトについてテキトーに書いておくこととする


・スクリプト数を減らせ 運動の一応の収束

 まぁ一時期みたいなヒステリックなキャンペーンは一応収束かなぁ
 対応できるところはとっくに対応してたし
 してないところは慌てて対応したり開き直ったり

 もう死んでるメーカーのものは諦めるはめになったり

 所謂負荷ランキングボードが現れたんだけど
 あれのうちいくつかはアレ自体が重いからまぁなんともだねぇ

 イベント会場とかはゼロスクリプト必須になりました 仕方ないね


・2008年頃からmesh普及くらいまでのミッシングリンク

 例としては
 meshオブジェクトをスクリプトで動かすのに
 スカルプみたいにアップロード段階での
 センターオフセットをやるための仕組みが存在しないので
 余計な三角ポリゴンを追加しているところがちらほらと

 その辺の対応も出来るところはきちんとやってるわけで

 自己調達技術がないところの場合
 一部のクソ重いポン入れ系以外は
 大体2008前期以前のスクリプトしか調達できないので

 スクリプトを入れることを諦めるかデファクトになっているものに移行するか
 開き直ることを強いられているのかねぇ

 
・ポン入れ系がぼちぼちやばい というかこのままだと大規模な死を招くかも?
 大量のリンクナンバー管理を強いられるような一部のオブジェクトの場合
 未だにポン入れ系1プリム1スクリプトのものが横行しております

 もし今後なんらかのSIM上でのスクリプト数制限がかかった場合
 某業界でデファクトになってる某スクリプト採用してるメーカーや
 AO入り多機能系HUDとかが大量死するかもしれん

 正規品買ってたらアップデートはされるだろうけど
 セットアップの手間がものすげー増えるだろうなぁ


・キャストレイは使えるようになっときー

 どういうものかというのを理解して
 簡単なサンプルスクリプトくらいは組めるようになっときー


・自前でなんか組むなら座標変換と三角関数と物理演算の知識は必須

 まぁ全部手打ちでやるなら別だけどねぇ
 そうでないならオフセット回転とか ピッチロールヨ~検出とか

 テクスチャアニメとかパーティクルの手入力とか
 その辺をぼちぼち覚えていく必要があるよと


大体この辺かねぇ

以上


メモ [TNKworks]VardarV1.3

かなり昔にレビューしたねこれ

当時はバージョン1.0だったかな

http://ueponya.blogspot.com/2013/12/tnkworksvardarv10.html

まー大雑把に書くと スクリプト的な部分での
わかりやすい悪癖みたいなもんは確実に減ってるかな



変なとこでコケるとかオフロード性能が微妙とかそういうのも減ってる



普通に道になってる箇所なら大体破綻せずに動く
スクリプト数も6まで減らしてきてる かなり優秀だね



ただまぁmeshを当たり判定にしてる関係の不具合みたいなもんはある
いきなり透明な壁にぶつかったみたいなジャックナイフして
そのまま床面方向にものすごい勢いですっ飛んでいって
横倒しのままどうにもならなくなったりとか

ブレーキランプが極稀に点きっぱなしになることがあるとか

(致命的なコケ方したらflightモードで脱出しろってことだろうねもう)
(今の設計なら足の当たり判定を最近流行りのテーパーかけた箱にして
 その分のチューンをスクリプトでやる方向が多分安全)

その場旋回を徹底的に排除しないのは そこまでやる必要はないって判断か
多分KCPベースで 下手に排除しようとするとロジック破綻起こすからだろうな


”この手のオフロード車両で外装と中身の素性がちゃんとしてるやつ"
ってんなら確実に選択肢の一つだなぁ

ただこれを手放しで万人におすすめできるかってーと
まぁそうでもない 車体のジャンルがちょっと特殊だし


ってな辺りかな
以上

A-Tのタグボート

ちょいと気になったので

https://marketplace.secondlife.com/p/A-T-HarborTug/6153928

mesh製でLIが35
まー昔の基準だとメインランド実用でギリギリだけど
最近のものとしてはむしろかなり余裕がある方だね


置物用のディスプレイモデルが同梱されているのでシーナリーとしても使える



コックピット以外の内装は無しだが元々中を歩くような船種では無いので問題なし



スクリプトは所謂ノッチ式で手放し航行が可能

フルパワーでも速度はそこまで出ないが十分実用域

ホーンとベルが使い分けられたり
照明類がオンオフ出来たりと実用十分なギミック有り

HUDはノッチ表示と操作盤とコンパス
所謂燃料のシステムがあるが航行可能距離的に
そこまでシビアに考えなくてもよさげ



ハンドリングはタグボートなので旋回力自体はそれなりに高いけど
ちょっと早めに行わないと衝突とか怖いかな

あとは浅瀬で座礁した時の挙動がちょっと気になるかなって程度だけど
この辺はそもそもぶつけなければいいって話になりそうな感
(ちなみに座礁したらプリム移動で脱出することになる)


複数人乗れてちゃんとした見た目で非武装で
まともに航行可能なボードが欲しいならおすすめ

ってなところかな
以上


最近のカースクリプトの調達法についてのお話

大きく分けて3つ


・フリービー系の利用
 Arlonとか開発終了してるDTCARとかあのへん
 ポン入れで動く奴がそれなりにあったりする

 (DTCARは売り物じゃねーかってツッコミが入りそうだけどまぁ
 今正規品買ってちゃんと届くかどうか怪しいからなぁ)

 ぶっちゃけ今となっては低機能すぎたりして話にならんけど
 今のところ一番ローコストな調達方法

・KCP ACS
 4000L$

 ぶちこめば動く系だとこいつがいまんとこFA
 昔はバイク専用みたいな構造だったけど 今は自動車に対応してるらしい

 難点はどうしようもないレベルでクソ重いことと
 その場旋回なので操縦性が全く自動車ではないこと
 あとバックのステアリングがおかしいことくらいだね

 利点は 大手メーカー並の多機能車両が少ない手間で作れること

 まぁこの利点は諸刃の剣なので
 出所不明の違法モデルデータ使ってる自称カーディーラーと
 一緒にされたくないならなんとかして自己調達するのがええかと


・自己調達
 まぁ欲しいものが手に入る可能性が一番高いのはコレ
 ただフルスクラッチで組もうとは思わないほうがいい

 最初はフリービーのスクリプト流用して
 バグやら嫌な動きやら潰しする方向でやること

 ただしまぁ操作に対応した外装制御とかは結局自前制作することになる

 ヒントとしては 一旦全部の操作をフラグで取得してそこから外装制御を行うこと かな


大体この辺かなぁ

全部に共通するのは日本語でのまともなマニュアルが存在しないことと
そのまま使う限りにおいては致命的なバグが存在すること

以上

2015年3月12日木曜日

llSetForceのお話

簡単に解説すると

llSetForce(<1,0,0>*llGetMass(),TRUE);

これでローカルX軸方向にオブジェクトを1m/sec^2で加速します

簡単でしょ?

んでまぁSLには空気抵抗が無いので
llSetBuoyancy(1.0);とかで
空中浮遊させたオブジェクトだと無限に加速しちゃいます

方向転換とかしたいときは減速する必要があり

force切っただけだとダメです

llApplyImpulse(-llGetVel()*llGetMass(),FALSE);

これ実行すりゃ空中でならほぼ100%止まる


ヴィークルのハック系で
一定重量以上のオブジェクトでは浮力が効かなくなるバグってのが
一部の業界では有名です

そういうときは

llSetForce(<0,0,9.8>*llGetMass(),FALSE);

これで浮力の代用とすることが可能と知られています


大体この辺かな

以上

2015年2月2日月曜日

LSLのちょっとしたif文圧縮テクニック

まぁほぼ使うことはないと思う

たとえばこういう状況

integer A=TRUE;
integer B=3;
integer C;


if(A && B==3)C=TRUE;else C=FALSE;


こういう場合 if文の結果は Boolean値 (TRUE or FALSE)なので

C=(A && B == 3 );

こう出来る

たったこれだけなんだけど

まぁたとえばこれが4箇所くらいに分散してて
メモリがどうしてもカッツカツだった場合

これに置き換えることで
スタックメモリの消費を512バイトほど減らすことが可能な場合があります

まぁ負荷ではなくあくまでVM内メモリの話なので
パフォーマンス重視なら全く必要ない上に
メモリが足りてるなら ソースの可読性が下がってしまうデメリットのほうが
デカイテクニックではあるんだけど

知ってると最後の一手みたいな状況でちょっと役に立つかもね的な

以上

2015年1月11日日曜日

SLで"いつもより重い"ってなったときにチェックすること

本格的な調査に入る前のクイックチェックリスト的な話

まずビューワーサイド

・描画距離が上げっぱなしになっていないか

・普段ONにしてない設定がされてないかどうか

・pingSIMの数値が異常値を出していないか

・周囲にパーティクルや光源が大量に無いか

大体この辺をチェックすればおk
マシンスペック的に重いとかはまぁ どうにかしてください

次にSIMサイド

・テロもしくはスパムが行われていないか

・SIM内に異常な多スクリプトを装着したアバターが居ないかどうか

・SIM内に異常なランドインパクトのmeshを装着したアバターが居ないかどうか

・SIM内に異常なコリジョンを発生させているオブジェクトが無いかどうか

・GridStatusを見てメンテやローリングがされていないかどうか

大体この辺
SIM自体がいきなり重くなる原因は大抵バカがクソ重いものを持ち込んだ場合です

んでそういうバカは大抵話が通じない上に他でもBANされていることが多いので
容赦なくBANなりTPHOMEしておk

ってな辺りかな

以上

2015年1月3日土曜日

ホビーって点からSLを観測した場合の話

まぁ大雑把にまとめると

・コスプレ

・ドール

・ジオラマ

・ガーデニング

・鉄道

・ゲーム系

・乗り物

大体この辺が可能かなぁ



コスプレとドールはまぁ実質的な差はないというか
所謂2.5次元系も割と問題なく存在できる系の意味ね



ジオラマ とガーデニング はまぁ景観の作成とかそっち系の話



鉄道 はフルスクラッチ自作とか市販品購入して走らせる系を
人間が乗れるフルサイズからミニSLみたいなのまでひと通り規格があるって話
撮り鉄系もまぁ可能だけど車両は大体自前で準備することになる

乗り鉄 はまぁ無理だな 路線が実質一本しか無いし 運転は自力だ



ゲーム系は スポーツ系やシム系のFPSがある程度出来る環境があるって話
刀専用のとかRPG系もあるっちゃある

 ミリタリー系での主流はは歩兵同士の銃撃戦

 乗り物も使える規格もあるが基本WW2 一応モダンウォー系もある
 空物の操縦性はプレステのエスコン2程度
 アナログ入力とかフライトモデルとか気にしたら負け

 NPC(主にゾンビ)相手の射的ゲーム的なもの もある

 そういったゲームに使用する銃や武器類は基本
 許可エリア以外では装備すら禁止されてる場合が多いです


 ガチのミリタリーな服装も心象が悪いエリアが割とあったりします
 (警察装備で横暴なことしまくるバカとかキチガイが一時期すげー問題になった)

 乗り物系でも武装されてるものは禁止ってエリアが割とある
 (設定加害傷能力はありませんとかそういうのは一切通じない)

 第三者が実在する軍隊や公的組織や企業のロゴや名称を使うのは原則禁止 一部罰則有り
 ("公的には存在しないことになっている"系の組織のロゴとかは知らんw)





乗り物は純粋な移動手段ではなくほぼレジャー扱い(移動だけならTPがあるので)

 モタスポも可能っちゃ可能だけどミニサーキットくらいのサイズまでしか作れない
 直線も最大で160mくらいまでしか作れないので大型車は結構キツイ
 (ゼロヨンで400m確保するのは物理的に無理なのでアキラメロン)

 一番プレイエリアが広いのはブレイクシーとかのヨットレース系
 ただし割とガチのヨットなので訓練必須

 乗り物系の入手手段は 買い入れと完全自作がある
 基本的に外装や走行を自分好みにどうにかるすなら完全自作になる
 (部品単位で売ってるやつもあるけどポン付け以外は物理的に出来ないので
  全部組み合わせが出来るフルキット系を買ってくるか自作になる)



んで全てに言えることなんだけど

ある程度効率化を求めたり 決め打ちで欲しいものが存在しない場合
ゼロから設備揃えてフルスクラッチで自作するか 製作を依頼することになる
依頼した場合の値段とクオリティーはまぁピンキリ

乗り物系やゲーム系は 走行させるためにスクリプトが必要で
フルキットみたいなポン入れで動く市販品(組立や組み込み自体は必要)から
ゼロベースでフルスクラッチで自作も可能

(ギミックや操作性に関しては一万円以下のチープ系ラジコンや
 プラモの操舵機能無しのモーターライズくらいが限界
 ドア開閉や砲塔旋回みたいな単純な機構は可能だけど
 サスとか車体のロールは演算負荷と通信速度の関係で現状は無理)

んでスクリプトを動かすVMのCPUの性能が
 PICとかの組み込み系ワンチップマイコン程度なので
 その辺をうまいこと折り合いつけて実装する必要がある感じ

メイン用途は文字の入出力と物理パラメーター書き換え あと外装やエフェクトの簡易制御
面アニメーションとか基本的なパーティクルくらいは使える

数学的な演算は単精度浮動小数点の誤差を
あんまり気にしないレベルの演算なら普通に出来る



ってな辺りかな

以上

ちょいと気になったのでビューワーの"超高"設定を試してみた

さてまー数日前に冬ボ向けPC更新の最低ラインの話をしました


で、某所で価格辺りのマシンスペックと快適性の話を見かけたので

(相変わらずハイエンドのPCじゃないと超高で快適じゃないって説と
  10万円クラスのゲーミングPCでも超高で快適って説)

ここ5年くらいカスタム設定一辺倒だったけど
超高ってそんなに重いのかーって部分に興味が出ましたので

素人なりにちょっとした検証みたいなことをしてみるてすつ



とりあえずまぁ超高設定って
どんだけクソ重いんだよってのを知らないことには
議論が全く進まないので実際にやってみた

ビューワーはfirestorm

プリセットの超高ってのは設定的にはこの辺にになる
(思いの外描画距離が低いなぁと 最低360m無いとSIMの対角線が見渡せない)


んで今回の検証に使うPCはこれ

CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (3292.58 MHz)
Memory: 24519 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 650 Ti/PCIe/SSE2

Windows Graphics Driver Version: 9.18.0013.4709
OpenGL Version: 4.5.0 NVIDIA 347.09


モノとしてはどこにでもあるような格安系の自作PCです

CPUの世代はIvyBridgeで 丁度オンボグラフィックやバスが小慣れてきた時期のやつ
(ハスウェルだともうちょいグラフィック性能上がってて
 i3でもミッド以上のグラボがまともに使えるようになってるとかなんとか)


現行のBTOマシンだと スペック的には リフレッシュドじゃないハスウェル搭載で
69800円前後のマシンに ミッドのちょい下のグラボとSSDとメモリ16Gと
インテルのギガビットイーサのNICを足した感じ

(マザーボードの組み合わせががBTOだと絶対に存在しない構成なのであくまで参考値)

650Tiを使ってるのはまぁ660と同じ石の廉価版で省電力だからってくらいの理由


で、まーその辺の話を見た感じだと
これでもクソ重いってんだからFPSが10切るとかなんだろうなーと思ったら


それなりに軽い場所で30fps辺りにクリップ(fpsリミットかけてるのを忘れてたw)

グラフィック的に”重い”場所で15fps前後まで下がる

なんかそんなに糞重いってほどでもないぞ?
ただ手放しで快適ってほど軽くもないな

(このCPUの場合オンボでも影表示しなきゃ30fpsくらいは余裕で出る
 大気シェーダーONにした瞬間に5fpsとかになっちゃうけどね)

10万円クラスのPCで超高で快適ってのは
まんざら嘘でもないがちょっと誇張表現気味かなぁと

(所謂SIMfpsってもんが45なので 60fpsではちょいとオーバー する感じ)

(PS3くらいまでの家庭用ゲーム機は平均30fpsで開発されてます PS4とかアーケードだと60かも?)





んでまぁ2007年基準での”普通のPC”で 当時確か一番軽い設定でも
(普通のPC:セレロン系でオンボグラフィックのみ みたいなPCのことね)

"軽い"と言われてるところで10fps

"重い"と言われてるところだと0.1fpsとかだったかなぁ

んでもってなんかの拍子にビューワーがクラッシュしまくってたねぇw



その当時からまぁ
"ゲーム用のハイエンド機"でないとこんなもんは出来ないッて言われてたね
そこから比べれば一応劇的に軽くなっている感じだけど
PCのコスパ周りも随分変化してるので断言するのはなんともって感じだなぁ


超高 の設定に関する話しはここまで


-----------------------------------------------------------------



ちなみに現在うちのPCで常用してる設定は


大体こんなもん
これで平均30fps前後はコンスタントに出てるし
ビューワーで30fpsにリミットしてるので普段のカクつきは無い

作業場レベルで軽くしたところならグラフィック負荷的には全く問題ない

初期のデータロードで重いかなーと思ったら描画距離絞るだけでマシになるので
値段の割にははちょー快適って感じではある


ってなところかね

以上