SANSARの決裁がSteam対応することについてのお話

結構思ってた"最悪"よりはマシという印象
　
ソース
https://modemworld.me/2018/10/31/sansar-extends-to-steam-lab-to-end-sandex/
https://modemworld.me/2018/11/02/2018-sansar-product-meetings-44-steam-with-audio/
https://modemworld.me/2015/11/04/linden-lab-and-tilia-inc-speculations-on-the-labs-new-subsidiary/

とりま今回の要点
　
・SANDEXが廃止というだけでS$は残る
・steamウォレットでS$が購入できるようになる
・S$購入レートは維持(1US$/100S$)
・SANSARのマケプレでの取引手数料(15%)が廃止(そんなにとってたのかYO!)
・引き出しレートの大幅な引き下げ(143S$/1US$から　250S$/1US$)
・S$の引き出しが"売上金"に限定される(自分で買ったS$の払い戻しは無理)
・S$はUSDに換金後の引き出しに30日の待ちが必要になる(長すぎぃ)
　
　
要はまぁ額面での売上が激減するし支払いまでに一ヶ月かかるようになるという話だな
ゼロになるわけじゃない
かというてS$の売上で"ギリギリ食ってた"連中は餓死するかもしれん
　
　
ただもう想定される最悪のシナリオ
S$廃止でマケプレ売上が
steamウォレットに
チャージされるようになって
一切換金できなくなりあぼーん
"ではない"
　
のでとりま安心かもねぇ
取り分減ること自体は全く変わらないのだけど

仕組み的には日本人に馴染みがあるプラットフォームてことなら
LINEのクリエイターズマーケットとかに近いかなぁという印象
　

最悪のパターンだった場合
それこそかなりグレーなルートで"現金化"する手法を使わないといけなくなったので
まぁそこまでする必要はないからとりまえず安心でいいんじゃないのという
　

とりまこの辺かなぁ

以上

新人3DクリエイターやVRC住民向け想定リスクリスト

とりあえずはVRC
今後新しいアマチュアクリエイティブの場が出来るたびにおきる想定

・コミュニティ内で可能な限り"先輩"や"師匠"と呼べるような人を見つけておけ
　作品を出す前の予防策や　何か気になるようなことを見つけた場合に
　判断基準に出来るような意見を得られる人を得ておくこと
　
　これをやらずにソロで暴走して追い出されたり燃え尽きていった新人は山程おる
　逆にこれの選定に失敗して潰れちゃった人も結構おるけどねぇ

・素材やキャラクタモデルのライセンスはちゃんと読んどけ
　"商用利用禁止"や”改変・再配布禁止”等のワードがある場合
　通称"お気持ち合戦"に巻き込まれて余計なリスクやトラブルを抱えることがあるので
　そのアセットは基本使えないものだと思ったほうがええ

・とりあえず異様に出来が良い版権コンテンツはrippedや違法コピーを疑え
　というか公式からのコラボしますのプレリリースや
　アバター自体に公式コンテンツ表記ナシで出てる時点で何かがおかしい

・自由に利用可能な3Dモデル素材配布サイトなんて便利なものは
　最初から存在しないと思え

　てのがもう　どこにrippedコンテンツが混ざったキメラがあるかわからないからだ
　カード登録必須で運営の身元がはっきりしてるところは別と考えてもいいが油断禁物

・自作品が人気コンテンツになった時点で不正コピーの標的になることは想定しろ
　DMCA申請がしやすいように時系列で制作過程とマスターデータの記録を取れ



・部品の一部がripped　みたいなキメラを自作と称して公開して
　あまつさえコミッションと称してカネを取ろうとする不届き者は
　絶対に現れるので　警戒しろ
　
・あらゆる手を尽くしてタダでなんかやらそうとする
　"企業"や"自称プロ"や"団体"が現れるから気をつけろ

・新しいプラットフォームではコンテンツ絶対数が不足している間に
　短期で需要が高い高品質なものを作って成り上がるという手が使えるが
　有名になれば過去の行動は全部調べられて後ろめたいこと等は晒されるので
　敵を作らないように品行方正に生きるか　新しく人格を形成しろ



・情報が出揃っていない状態での憶測での行動は危険
　この辺はまぁ　MMD　vs　VRC
　みたいな状態にしようとしてた人らを見てわかってるとは思う
　
　現状の確認　と　間違った情報の訂正　は正しい行動をするための基本

　
・とりま積極的にコンテンツ供給をしたり
　コミュニティに参加したり貢献する気がないなら　MMDには関わるな

　コミュニティに参加したり貢献する気がない部外者が関わると基本碌なことがない
　MMDはファンコミュニティでありMMDのアセットは全てMMD専用のものだ
　MMDは貴様の便利な無料アセット置き場ではない
　

とりあえずとしてはこの辺かなぁ
あとなんかあったら随時追記ってことで

以上

公道最強理論 2018年

クルマとして最低限クリアすべきファクターは　4つなんだよ

　
・旋回レートの安定化

・加速レートの安定化

・ブレーキングの実装
　
・まともに車庫入れが出来ること

全部もう両立可能ではある
　

でまぁ　今回は加速レートの安定化と旋回レートの安定化の話


旋回レートと加速レートの安定は相互で関わるわけよ
　
ギアアップするとパワーアップするのは
クルマとしてはおかしいわけよ常識的に考えて
　
加速力ってのは最高速度アップで下がっていくのが
自然の摂理なわけよ　パワーバンドとは別の話な
　
じゃぁなんで既存カースクリプトは　ギア＝パワーなのか

理由はスクリプト内部の数式観察すると簡単なんだよな



その前に高校物理の初歩でやる簡単な数式
a(加速度) ＝ v(最高速度)/t(加速時間)

単純にこうな


でもって　SLのヴィークルで直接指定可能なのは
最高速度
VEHICLE_LINEAR_MOTOR_DIRECTION
http://wiki.secondlife.com/wiki/VEHICLE_LINEAR_MOTOR_DIRECTION
と
加速時間
VEHICLE_LINEAR_MOTOR_TIMESCALE
http://wiki.secondlife.com/wiki/VEHICLE_LINEAR_MOTOR_TIMESCALE/
のみなので

大体ギア(最高速度)をList使って可変にするんよ
そうすると　加速時間が一緒で最高速度が増えるから
そりゃ加速力が向上するわな？　簡単なお話だ



ワイとかよく比喩表現として
"SLのヴィークルは思いで駆動する"とか言うわけよー
物理法則的にはパワーから加速時間が決定するからな

なので加速レートを安定させたければ
　
単純に
t(加速時間)=v(最高速度)/a(加速度)
の数式で加速時間を決定してやればいい


で、
この数式を単純に入れるだけではちょっとした問題が出てくる

VEHICLE_LINEAR_MOTOR_TIMESCALE

これの下限が0.1なんだよな

なので　0-100km/h加速を例えば3秒とかにしたとして

大雑把に27m/sec　加速度は9m/sec^2　大体0.9Gくらいかな

SLでまぁまともな登坂能力欲しかったら最低でも2Gくらい要るのよ大雑把に

でも速度は出したくない　歩く速度程度　5km/hくらいがいい

そうなると

1.38/20=0.069

0.1切りますな

でまぁこうなる場合は

VEHICLE_LINEAR_MOTOR_DIRECTIONを

加速時間が0.5秒くらいになる適当な数値にして

本来設定したい最高速度に達したらモーターをカットすればいい

あともうこれでパワーバンドみたいな概念も直感的な

加速度という数値で入れられるようになる　やったね！

参考程度に　ということで

ちょっと既存のヴィークルについて計算してみるか

一般にレース用ヴィークル言われてるやつは

1秒程度で時速300キロに達する

加速度的には　8.5Gくらいか　参考に調べたらドドンパが3.75G

83.3/83.3=1.00　まぁこのレートでも最高速度ならあんまり関係ないな

次　旋回レートの安定のお話

実は加速レートが全ギアで安定してしまえば

旋回レートって既存のロジックでも安定しちゃうのよ

ただし超高速領域でクリップしてしまうのでそこはどうにかせんとアカン

VEHICLE_ANGULAR_MOTOR_DIRECTION

http://wiki.secondlife.com/wiki/VEHICLE_ANGULAR_MOTOR_DIRECTION

日本語だと書いてないけど　英語なら　4PIと書いてある

この数値案外すぐ突破しちゃうんだよな　せいぜい12.56くらいなので

　

アーロン系のスクリプトだと大体適切な係数がせいぜい2.5から3.0前後

　

12.56*3.0*3.6=135.048

12.56*2.5*3.6＝113.04

時速だと135キロ程度がステアリングが

リニアに効くMAXだということになる

　

DTCARだとその辺はそもそも関係ない

速度でターンレートが下がる数式なので

でまぁ４PIでクリップするなら

それ以上をインパルスとかを使ってアシストすりゃええんだけど

ちゃんと計算してアシストしてやらんとすっ飛ぶし

ヴィークルパラメータの限界はそのままだから

アンダーステア等の問題が出てくるのだ

そっちもインパルスで押し込めばいいんだけどな

その辺の計算は理屈がわかってりゃ単純っちゃ単純だよ

大体この辺かねぇ

以上

BENTOハンド制御HUDの雛形 的なお話 仕様想定編

ちょー雑にやるよ

あくまで仕様想定のみなので実際の実装はそのうち書くかもしれんが
基本的には各自なんとかしてください

・必要そうな変数の想定

とりあえず左右別制御だからLRの二種類は必要

インジケータの点灯認識に必要そうなのでラストリンクナンバー

integer lst_anim_num_L;
integer lst_anim_num_R;

アニメ止めるのに必要そうなのでラストアニメネーム

string lst_anim_name_L;
string lst_anim_name_R;



・アニメーション名称のフォーマット

Lhand_XXX
Rhand_XXX

こんなもんかな　XXXは連番の数字　3桁　001~999まで
ボタンプリムの名称も同じにすることで
収納と展開の処理もオートに出来るんじゃないのという想定

このフォーマットになっていないボタンは
別の機能ボタン　あるいは背景として最初の方でif文で弾けばいい

アニメボタンのif文後にreturn入れれば
アニメボタンのレスポンスがスポイルされることはないんじゃねぇかなぁ



・ボタンのLRとか番号とかやるためのIF文

基本的に　llDetectedLinkNumber　からの　llGetLinkName　で

名称の先頭１文字でLR判定　後ろから３文字で番号判定
抽出はllGetSubString でいいだろ




・タッチ時の挙動
　
まず押されたボタンのLRと番号をチェック

ラストアニメと押されたアニメが一緒の場合
　停止してインジケータ消灯　でreturn

ラストアニメと押されたアニメが別の場合
　ラストアニメが空白でなければ停止してインジケータを消灯後に
　押されたアニメを再生してインジケータを点灯
　
　ラストアニメに再生したアニメ名を入れて
　ラストリンクナンバーにリンクナンバーを入れる


アニメのボタンでない場合
　展開格納の制御等の処理？



・その他気をつけること
　通常のAOのようなアニメの全停止処理を入れると割とまずい
　外した時にアニメ停止するかどうかは判断が別れると思われ
　停止したほうがいいと思うけどねぇ



・展開と収納の処理

全プリムスキャンしてボタン番号を調べて

除算と余りを使って位置を確定して
等間隔にグリッド配置すりゃええでしょう

大体この辺かな

以上

RayCastとか呼ばれてるllCastRayのお話 乗り物向け

前に書いたのが出てすぐくらいだったので改めて書くかなぁという感じで

　

とりあえずリファレンスになるようなヴィークルがあるといいいんだけど

知ってる限りではこいつくらいしかないんだよなぁ

https://marketplace.secondlife.com/p/mechanical-ant-119-full-perm/5106264

処理の考え方　とりあえず路面追従のみする場合

・とりあえず速度ベクトルから”未来のタイヤ位置”を調べる

　

　この辺はタイヤの位置と角度の制御がセントラルコントロールだと楽です

　計算に必要なパラメータが全部揃ってるのでちょー簡単

　で、ルートプリムの位置と　回転と　速度ベクトルを調べて

　1フレーム(約0.035秒)後のタイヤの位置座標を計算します

　単純に速度ベクトルを0.035倍するだけでOK

・RCを実行する

　

　でそのタイヤ位置から

　ローカル座標系(ルートプリムをゼロ位置ゼロ回転とする座標系)で

　それぞれのタイヤの未来位置から

　Z軸のプラス50センチからZ軸のマイナス1mに向かってllCastRayを実行する

　検出の最大数は　子プリム検出とかしないなら最大でも２でいい

　UUIDはルートプリムのものを拾うようにしとくと

　自社検出を効果的にフィルタリング出来るはずだ

　ノーマルのベクトルはいらん　どうせ使わん

　これを変換すればタイヤの未来位置における”接地面までの高さ”が出る

・タイヤをストロークさせる

　理想的なサスペンションシステムは

　車体をロールさせずに完全に垂直にストロークするので

　とりあえずタイヤのストローク位置はRCの数値そのままオフセットすればOK

　ストローク量が一定以上の場合は

　フルバンプとフルリバウンドの位置で止める処理入れとくとええ

ソースを使わず大体の流れをまとめると大体こんな感じ

サンプルコード書くとタイヤ位置ごとにRCを実行して高さをfloatで返すだけの関数を

4回実行するだけでいけるからちょー簡単なんだけど

ルートプリムからのタイヤの初期位置　の定義が無いとそこが厄介なのよねぇ

でもって荷重移動を足す

でまぁ　これに荷重移動によるサスペンションストロークを足したいってなるわな？
ストローク最終決定する前にRCの生データを足せばOK　簡単だな

タイヤ”だけ”を考慮した場合はこれでいい

でまぁこれが一番厄介な箇所になるんだけど

実際のところほとんどのSLの地上ヴィークルには

当たり判定のための通称"ソリ"がついているのだ

こいつを4輪がまともに接地するように調整するのがまぁかなり厄介なんだけど

ピッチングのみを制御するならまだなんとかなる

ローリングのみでもまぁなんとかなるな

複合した場合

タイヤ4つが同時に接する”ソリ”の回転と位置を合わせることになるんだけど

むしろソリを回転させてから

それに合わせてホイールをストロークさせたほうが楽だな

となると　さっきのRCの計算ともちょっと違うねぇ

でそのホイールのストロークでもサスペンションのフルバンプは出るわな？

でそうなった場合挙動にリミットがかかるわけかんだけど

その辺はピッチとロールの数値で直接リミッターかけたほうが多分楽だよなぁ

底辺と角度が決まってるからArcCosでRだしてからのRsinθか？

この辺の式は整理すればもうちょいわかりやすい構造になるはずだけどなぁ

ああ普通に　tanθx(底辺Y)　でストローク出るかいけるじゃん

変に合成ベクトルでやろうとしなけりゃいけるな

大体の考え方はこれでいけるはずだから

後は誰かが頑張って実装してください　だなぁ

計算の順序は　ソリをピッチとロールさせて

それに合わせて4輪のストローク量を決定して

そこから更に接地分を足す　と

んでこれ前荷重状態で地面がなくなった時の挙動が厄介か？　いやそうでもねぇか

ある程度真面目に方程式を解けば

イニシャルDでやってた　インの前輪だけ浮かすコーナリングとか

あのへんも実現出来そうではあるな

これで合ってるかどうかは実装してみんとわからんなぁ

ちなみにもっと雑な実装方法もなきにしもあらず

"ソリ"を先に回転させてコリジョンで挙動安定してから

RCで接地計測するの

時速20キロくらいまでならこういうガバガバ実装でもそこまで違和感出ないはずだ？

とりあえずこの辺かねぇ

以上

スクリプトから見た イベント時のSIMパフォーマンス改善方法について

まぁ2017年が終わるのに今更そんなカビの生えたネタかよみたいなところはありますが
　
未だに"ヌルい"運営してるところが結構あるという話を伝え聞きますので
今一度最新のトレンドも込で年末イベント向けのパフォーマンス改善の話とします
　
　
ちょー雑にチェックポイント

・SIMFPSが44.0を下回るとヤバイ
・SIMのスクリプトタイムが10を超えるとヤバイ
・軽くしたいならビジターは全員座らせろ

・装着スクリプト負荷のチェックは必須
　スクリプト総数15枚　スクリプトタイム0.05ミリ秒以内が目安

・アパレルで一着に3枚以上のスクリプトが入ってるのは異常と知れ
　特に今時パーツ単位でのリサイズやカラーチェンジのため"だけ"に
　パーツ単位でスクリプトが入ってるのはおかしい
　5年以上前には既に入れなくてよくなってる

・スタッフやオーナーやメイン演者だから
　重くていいという道理は　無い
　特にオーナーとスタッフは
　ビジターに対する模範として徹底的に軽くしろ

・いくらそのSIMに取って重要な住民だろうと重いのはやめさせろ
　そいつのためだけにSIMを沈めるだけの覚悟があるなら別だが




んじゃ詳細

ctrl+shift+1を押して出る統計情報から

まず平時のチェック項目

・SIMFPSの確認
　44.0を切るようならアカンです
　逆に1.0くらいは割と色々な条件で落ちます

・アクティブなスクリプト
　大雑把に3000切ることを目指しませう

　普段土地レンタルしている土地ならスクリプト数は
　土地プリムの20%程度を目安に減らすことを目標としませう

　200プリムなら40程度　

・スクリプト実行
　ここが常に100%になることを最低条件とします

・時間
　常にフレーム合計時間が22.200ミリ秒を超える場合何かがおかしいです
　
　スクリプト時間　は10ミリ秒切ってることが最低条件
　ほんとは3くらいにしときたいんだけどねぇ

　逆に　スクリプト時間と余暇　とフレーム時間合計　以外が
　1.0を超えるのも割とまずいです


・スタッフ・住民・常連客の装着スクリプト数とスクリプトタイム
　装着スクリプト数は平時で50枚未満　イベント中は20枚未満
　スクリプトタイムは0.1ミリ秒を切りませう
　0.1超えてる時点でスタッフとしては重すぎます
　ほんとは0.05切りたいところだけど最近だとちょっとむずかしい

　消費メモリは多少参考になるけど
　スクリプト数が多けりゃ普通にアカン数値になるので
　基本的にはスクリプト数とスクリプトタイムを観測すること

でまぁこの辺のチェック項目で一つでもボーダー越えたらアウトです




イベント時のチェック項目

・ビジターのスクリプト数とスクリプトタイム
　実際のところスクリプト数が150枚越えてたら問答無用でTPHOME対象
　警告してダメならBANでもOK
　それを理由にテロリストになる可能性はあるけど
　そったらそれはそれでARする理由になるのでOK

　50枚超えてる程度なら
　軽量化にご協力ください
　不要なHUD等を外してください
　という感じの"お願い"すりゃええ

　ほんとの理想は来客全員完全ゼロスクリプトではあるんだけど
　そんなことしたら服装の選択肢が極端に狭まる上に
　イベントの性質によってはそれが不可能な場合が多いので

　最低限のAOとかその辺の装着を許可した場合
　15枚くらいが最大値かなという感じ
　スクリプトタイムは0.06ミリ秒くらいまでは大目に見ませう

　超えるやつは両方共大幅に超えちゃうので個別対応でいい


・監視スタッフとしてのエスマネの有効性
　正直エスマネの上位スクリプト　が使えないと
　イベント中のリアルタイム監視は無理HUDタイプの監視スクリプトは止まる
　ライブパフォーマンス系のイベントなら最低一人はエスマネが常駐しませう
　
　ある程度期間のあるイベントの場合は各種自動監視スクリプトを活用しませう




有用なスクリプト命令群

まず装着物一覧がUUIDで取得できる関数　HUDを除く
http://wiki.secondlife.com/wiki/LlGetAttachedList

からの　個別オブジェクトのスクリプト数　スクリプトタイム　等の取得
http://wiki.secondlife.com/wiki/LlGetObjectDetails

OBJECT_NAME,OBJECT_RUNNING_SCRIPT_COUNT,

OBJECT_TOTAL_SCRIPT_COUNT,OBJECT_SCRIPT_TIME

この辺取得すりゃ十分だな

これ使ったセキュリティーゲートを通ること自体を

プライバシーの侵害云々でゴネるようならお帰り願うしかないなぁ

ちなみに装着HUDの一覧は取得できないので

アバター全体から　HUD以外の装着物の数値を引いたものが

HUDのスクリプト量になる

チェックタイミングは

http://wiki.secondlife.com/wiki/LlVolumeDetect

これを使って通過時にすればOK　セキュリティーゲート風にしときゃええな

SL用にハイエンドPC組んでもあんまりパフォーマンス上がらない理由

VR用にグラボをGTX1060入れました　VRAMはもちろん最大の6G

コスパ厨なら3万切る3Gモデルでも問題はないんだけど
まぁ大体経験上VRAM少ないグラボで碌な目に会ってないので

んでまぁSLクライアントでむやみにハイエンドなグラボやSSDを入れても
全体のパフォーマンスアップが頭打ちになるどころか
ボーダー超えるとCPUとGPUが寝るようになる現象について

大体の結論みたいなもんが出た
　
ボトルネックになってるのはGPUでもCPUでもなく
恐らくGPUでレンダリング可能なデータに変換する周りの
レンダーパイプライン周りの処理がボトルネックだ
　
なのでレンダリングエンジン自体の
根本的なアップデートがないとパフォーマンスアップは不可能というとりあえずの結論　

でまぁFPS上げたかったら描画距離を256までにしろってことのようだ




じゃぁなんでそんなことになるのかというと

とりあえずLLが想定してる標準的なレンダリング距離は256mのようだ

描画距離が2倍になるとレンダリング対象オブジェクトの処理量が
単純計算でもにXYZ軸で8倍になり
(実際の具体的な数値はもうちょい小さいはずだ)
　
どうもなんかそのへんの処理で”細かい大量のオブジェクト”の処理が
どんどん肥大化してクソオモになるらしい？

　
でまぁSLのオブジェクトは
そんな処理をするための最適化されたモデルになってるわけでもないので
描画距離を伸ばすと指数関数的に処理が増大することでひっかかる原因になるようだ

実際描画距離を絞るだけでCPU使用率とGPU使用率が上昇して
FPSも16切るくらいから30以上まで上昇する



でまぁ多分これ”画角”に対するレンダリング省略処理を入れることで
解決しようとするのがセオリーなんだろうけど
というか今も隠れたオブジェクトのレンダリング省略は入ってるんだが

描画距離を一定ボーダー以上にすると
どうもそれ以前の領域での処理量がえらいこっちゃになるっぽい


でまぁそこを解決する手段なんだけど
多分SLクライアントが本格的にマルチスレッドとか
リクエスト数リミット周りの上限対応すりゃいけんじゃねぇの？知らんけど


ちなみに根本的な解決にならなかったのは以下の通り

・最新のハイエンドCPUへの換装(CPU使用率が寝る)
・最新のハイエンドGPUへの換装(GPU使用率が寝る)
・M.2SSDへの換装(全体的なパフォーマンスアップにはなったがFPS改善せず)


もちろんこの辺が完全に無意味ってわけでもなく
フリッカーさんとかだとレタッチやらで十分なパフォーマンスアップがあるし
動画撮影や編集でのかなりの速度アップが望めるので

ある程度最新のCPUにしてSSDと大容量メモリを搭載して
3万円前後のまともなグラフィックボードにすることは
現在移動すら辛くてビューワーがクラッシュしまくるような状況では
十二分に効果的なのでそこは誤解なきよう



以上