身内向け SSOC R2 フォトスポット

座標ダイレクトなのでクルマとか併用しつつ適当に回ってくれい

1.R2よくばりセット

http://maps.secondlife.com/secondlife/R2%20Fashion/95/202/1104

R2のSIM要素ほぼ網羅出来る場所

2.雑居ビル街の外

http://maps.secondlife.com/secondlife/R2%20Fashion/71/189/1108

ちょっとここ到達するの難しいかもねぇと

3.月壁銃砲店

http://maps.secondlife.com/secondlife/R2%20Fashion/63/193/1108

狭い室内で全天映像とるのによさそな密度

4.雑居ビル街　喫茶店前　どこかでみたような店名

http://maps.secondlife.com/secondlife/R2%20Fashion/46/168/1105

5.コンビニ店内

http://maps.secondlife.com/secondlife/R2%20Fashion/102/172/1104

6.TOC格納庫

http://maps.secondlife.com/secondlife/R2%20Fashion/68/20/1109

ミリ系


7.SSOC東中央交差点

http://maps.secondlife.com/secondlife/SSOC/192/96/1102

8.SAC本店周り

http://maps.secondlife.com/secondlife/SSOC/195/212/1111

9.地上側雑居ビル街中央

http://maps.secondlife.com/secondlife/Mopire/225/49/32

10.ロックゲート

http://maps.secondlife.com/secondlife/SSOC/142/124/24
http://maps.secondlife.com/secondlife/SSOC/229/119/23

11.商店街

http://maps.secondlife.com/secondlife/SSOC/105/184/28

12.ゲーセン内部

http://maps.secondlife.com/secondlife/SSOC/105/191/28


13.神社

http://maps.secondlife.com/secondlife/SSOC/138/222/34
http://maps.secondlife.com/secondlife/SSOC/122/215/33
http://maps.secondlife.com/secondlife/SSOC/130/244/35

14.学習塾前駐輪場

http://maps.secondlife.com/secondlife/SSOC/37/72/31

15.倉庫に併設の有料駐車場

http://maps.secondlife.com/secondlife/SSOC/134/35/26

16.ファミレス

http://maps.secondlife.com/secondlife/SSOC/106/173/32

17.高架下T字路

http://maps.secondlife.com/secondlife/SSOC/58/156/27


だいたいこの辺かねぇ

以上

身内向け Mopire フォトスポット

座標一式ね

直接飛べないからなんとか歩いて到達してくだちい

1.ランディングからモールのエントランス

http://maps.secondlife.com/secondlife/Mopire/216/173/1107
Mopireのランディングで後ろに見えるモールのど真ん中
全体が見渡せるのでわりといける

2.モールのモノレール駅

http://maps.secondlife.com/secondlife/Mopire/242/163/1132

１番から東のエスカレーター上がって４階
エスカレーター上がる風景でもいいかもねぇ

3.中華屋前の渡り廊下
http://maps.secondlife.com/secondlife/Mopire/185/175/1124

駅からエスカレーターを1フロア分降りて廊下を西にいくとある
中華屋の中もフォトスポットではある


4.　一階のピザ屋んとこの椅子

http://maps.secondlife.com/secondlife/Mopire/159/163/1107

渡り廊下から西にあるエスカレーターで一階まで降りるとある
ガラス越しでモール西側と店内がみられる

5.西交差点　高架下

http://maps.secondlife.com/secondlife/Mopire/87/98/1102

モールから出て歩道橋の方にまっすぐ歩いて交差点のど真ん中辺り

この辺は各停止線からの風景もいいし
歩道橋の上から撮ってみるのもいいだろう

クルマ撮る時は大体このへんでやる

6.駅入り口

http://maps.secondlife.com/secondlife/Mopire/107/137/1103
ここ自体は特にフォトスポットってわけでもないが通り道ってことで

7.屋台通り
http://maps.secondlife.com/secondlife/Mopire/107/162/1093

ちょっとした高密度スポット
ここの改札はスルーして向かって右の大通りを南にいきエスカレータを降りる

8.中央改札

http://maps.secondlife.com/secondlife/Mopire/106/118/1085
http://maps.secondlife.com/secondlife/Mopire/123/119/1085

券売機や改札の密度高し

下り階段側の改札に入って更に下へ

9.地下鉄ホーム中央

http://maps.secondlife.com/secondlife/Mopire/177/137/1077

ホームと車両

まっすぐ階段上がって左にいくとモールに出る

ここでは降りてきた階段の裏に向かう

10.中華鉄ホーム中央２

http://maps.secondlife.com/secondlife/Mopire/101/135/1077

自販機とキオスク

11.西改札出口

http://maps.secondlife.com/secondlife/Mopire/48/135/1077

この階段を上がって左　改札を出る


12.　中央改札２

http://maps.secondlife.com/secondlife/Mopire/59/118/1085

中央改札の反対側

ホームに入場して右に向かい　突き当り右の階段を上がる

13.中央口とかいてあるが実質南口

http://maps.secondlife.com/secondlife/Mopire/86/42/1093

ここも改札とキオスク
まっすぐ出て大通り右のエスカレータを上がる

14.自転車置き場

http://maps.secondlife.com/secondlife/Mopire/64/8/1102

自動精算機付きの自転車置き場　自販機アリ
ここから北に行くと５番の交差点に出る

15.郵便局とアメリカンパトカー

http://maps.secondlife.com/secondlife/Mopire/176/66/1102

16.ビルの谷間　電柱多め

http://maps.secondlife.com/secondlife/Mopire/199/27/1102



とりま上空側の地上と地下　で一通り回るならこんなもんかねぇ
歩いて回って一時間程度のルート


迷ったらとりあえず階段探して上を目指せ
案内看板類が全部実際の導線なのでそれ参考にして目指すもよし

階段の場所も代体セオリー通りなのでそれで脱出できる
あと改札機は歩いて通らないとだめよ

17.おまけ　全景用

http://maps.secondlife.com/secondlife/Mopire/120/145/1133
http://maps.secondlife.com/secondlife/Mopire/60/157/1208

18.おまけ　モール駐車場

http://maps.secondlife.com/secondlife/Mopire/187/198/1132

以上

SecondLifeでBlender使ってなんかやる場合のお話 その２ 初動編

第一回はここ

https://ueponya.blogspot.com/2019/12/secondlifeblender.html

本が二冊ある前提での話とします

本の内容的に

blenderを2バージョン使う必要があり
なのでzipでダウンロードしてくる必要がある


で2.79bはここ

特に問題なければ　windows 64bit を選択
https://download.blender.org/release/Blender2.79/

2.81はここ

https://www.blender.org/download/

zipを解凍するのにアプリが必要な場合はこれ

https://sevenzip.osdn.jp/

でフォルダつきで解凍して

適当なところに配置する

デスクトップとかでいい

でとりあえずどっちかを起動する

設定は右クリック選択にしろ　一番不具合がない

それぞれのバージョンの設定は

本を参照でいい　とりま日本語化する程度でOK

次にプラグイン(textools)のインストール

インストール自体は別にUV作業開始する前でもいい

正式版はこれ　今の所2.78までの対応
http://renderhjs.net/textools/blender/
有志による2.8対応版
https://github.com/SavMartin/TexTools-Blender/releases

インストールは　設定のプラグインから行う

解説はこのへんを参照のこと

基本的なやり方や文言はバージョンごとで変わらん

http://bluebirdofoz.hatenablog.com/entry/2019/02/19/093817

注意点としては

プラグインのパネルの場所が

2.79では左側

2.81では右側になるので

そこだけ注意

あとMagicUVというネ申プラグインもあるからそれも有効にしとけ

とりま初動はこの辺

以上

SecondLifeでblender使ってなんかやる場合の現状での一式セット

話はシンプル

まず3000円の本を二冊買うのだ
こういう本は新品買っとけてのが基本だけど

ディスクが付属してるとかそういうのないから
ガチでお金ないなら別に中古でもいいけどまぁそこはお好みで

推奨は新品　忘れないことだ


イルカ本　blender2.7だが内容はまとまっている


箱うし本　現状手に入る最新で一番簡単なblender2.8本


とりまこれ買っとけばあとは読んどけ　でいいんだけど
それだとまぁあまりにも突き放しすぎてるので

blender2.79aのダウンロードはここから

https://download.blender.org/release/Blender2.79/

blender2.8はここ　2.81aとかになってるけど　気にするな

https://www.blender.org/download/

あと神ツールである　textools

正式版はこれ　今の所2.78までの対応
http://renderhjs.net/textools/blender/
有志による2.8対応版
https://github.com/SavMartin/TexTools-Blender/releases


※ダウンロード時の注意点
BlenderはSteam版やインストール版はダメ
複数バージョン共存ならzip版

※操作はキーボードで覚えろ

でまぁ　読む前に
ここにポストイット入れとけという
SLでやるのに重要で具体的なページ番号



まずイルカ本

p008　基本操作の章
p028　第一章　ロボットのモデリング
p076　第二章　サブサーフとミラーでのイルカのモデリング
p169　第二章-3　ボーンとウェイト　SLだと絶対にAvastar使うから参考程度に
p192　3-1　カーブを使ったモデリング　建築だとチェーンやワイヤー類とかで使う
p218　3-2　文字の立体形状を作る　これ案外多用するんだよなと
p262   4-1 マテリアルの基本
ｐ309　4-4　シーム切りとUV展開　これが出来ないと話にならん

とりまSL向けでの初動学習ならここまででいい
これ以外のレンダリングとかシェーダーの細かい設定の話は
正直2.8が出た現在ではあんまり意味のある情報でもないんだが

3Dモデリング全体としてはある程度有用なので目を通すだけでもやっとけ



次　箱うし本　SL用だと使うページは更に少ないが
とはいえ最新のかなり重要な情報がいくつも入ってる

p009　blenderのセットアップ
p024　アウトライナーの役割　ある程度複雑なもん作るときに必須になる
p030　1-1　移動/回転/拡大縮小
　　　　ぶっちゃけこの３要素さえわかれば3dモデラーの9割は使えると思っていい
p40　ショートカット　暗記する必要はない　多用してりゃ体が覚える
p45　ショートカット　以下略
P60   1-3 ペアレント　SLの場合リンクオブジェクトとしてアップロード出来る
p71   1-4 原点の設定　これも複合オブジェクト作る際に多用する
p83   1-5 ペアレントを用いた歩行アニメーション
　　　この辺は組立状態と解体状態の切り替えとかで便利
p116 三章　ボーンとウェイト　参考程度に　操作方法を覚えるのが目的
　　　繰り返すがSLの場合Avastar使う前提なので
　　　直接的な方法としてはあまり関係ないっちゃない
ｐ156 3-2 IKのお話　知ってる前提で話がされることがよくある話
ｐ198　4-1　パーティクル　SLのパーティクルと直接の関係はないが一応
ｐ223　クロス　置物系で使えると便利なシチュエーションが結構ある

p252　モデリング　おまけ程度の内容ではあるが
　　　　イルカ本と組み合わせると見えるものがあるだろう
p269　レンダリングエンジンの話
　　　　これもSLとは直接的には関係ないが　知ってる前提で話が進む事が多いので
　　　　一応目は通しておけ　具体的な操作は必要なときにまた本を見ればいい

本の中身に関してはとりまこのくらいかなぁ




正直なところSLでモデリングやるばあいのセオリーということでなら
サブディビジョンサーフェスは使うな
と言っちゃってもええんだけど

実際のところは使い方全く知らないとそれはそれで詰むから

結構難しいお話なんだよねぇと

あと動画での参考ということだと

通称　ワニ動画　というのが存在する

これだ

https://www.youtube.com/channel/UCqHa5bmORg-H_EMELJ_ww6g/videos

vrchatとSLはある程度共通点があって

UV展開してテクスチャを作れって部分　ここはもう基本だと思っとけばいい

でテクスチャのペイントやベイクをする方法というのは

まぁ色々とあるのだ　とりま今回の記事では

UV展開は義務　と認識すればいい

大体このへんかねぇ

以上

LSLバックステージがネット上から消えたので 要約掲載 高速化編

のでまぁテクニックのところだけでも抜粋して
何回かに分けて乗っけとくこととする

でまぁ更に適当に抜粋に抜粋して要約する

3.1高速化手法

3.1.1定数演算は演算結果を書く

なんかLSLコンパイラで計算結果が変わらない定数演算も
そのままアセンブラコードにしちゃうらしいので
定数計算はコメントアウトして計算結果だけ代入しとけとのこと

ただこれも過剰にやると可読性が死ぬので
秒単位で演算時間が変わるような長大ループとか

ミリ秒単位で処理時間圧縮したい場合に有用

ワイの場合メモリに余裕あれば初期化処理してグローバル変数にぶっこむかな

変数間移動とハードコーディング数値の代入では前者が早い

3.1.2ループ中で計算結果の変わらない異処理はループの外に出す

for文とかで比較対象の固定数値をいちいちllList2とか使うと
なんかループの回数分list2が実行されちゃうらしく

先に変数に代入しとけということのようだ

これはllList2系命令の処理の食われ方からしても妥当やな


まぁこれもうちょい短縮方法ある

Listに対して固定でなんかするループ処理の場合
リスト長の変数自体をインクリメントなりデクリメントなりして
whileでぶん回すと結構な短縮になる

llist length = llGetListLength(Holge);

do{
    (何らかの処理)
    --length;
}while(hoge>-1);

これまぁリンクセットダンプとかでも使える


3.1.3　短い処理は　インライン展開

なんでもかんでも関数定義して投げるなって話っぽい

概ね10演算子辺りがボーダーらしいので

複数箇所から呼び出すことがわかってる処理以外は
可能な限りユーザー関数使うなみたいな感じだな

これも秒オーダーで処理時間変わるループや
ミリ秒オーダーでイベント終わらせる必要がある場合以外は
割と無視していいが　最後の詰めに使えるな


3.1.4　インクリメント・デクリメント

i++;
より
++i;
の方がアセンブラコードになったときに２命令文圧縮できるとのこと
これは普段使いではくせにしちゃっていいと思う

で更に

ビット反転した後に符号反転すると＋１したことになるとかで

a=-(~a); // ++a と等価

符号反転してからビット反転すると-1したことになるとかで

b=~(-b); // --b と等価


という記述方法が紹介されているけど
これも山ほど動かしたり
ミリ秒オーダーじゃないかぎりそこまでは不要かなぁ


3.1.5　ローカル変数は宣言時に初期化する

これはまぁちょっとわかりにくいな

ゼロやNULLで宣言しておく分には関係ない話
特定の数値代入して初期化する際に
宣言と代入と分けずに　宣言即代入したほうが早い

integer i;
i=5;

とするより

integer i =5;

こっちのほうが2命令文早いとのこと

これもミ(ry

3.1.6　同じ値を複数の変数に代入

同じ数値なら＝でチェーン記述したほうがええということらしい

a = 0;
b = 0;

よりも

a = b = 0;

のほうが効率的とのこと

3.1.7　ローカル変数VSグローバル変数

ローカル変数の方が確保と開放の処理分ちょい重いとのこと

これは体感としてスタックヒープコリジョンの対策でちょい有効
ループカウンタの変数とか文字列入れる一時変数とか
その辺をグローバル定義するとメモリ圧縮になることもなる


3.1.8 リストへの値の追加

リストへ値を一つ追加する場合は　[]で囲わなくても
そのまま+=でいけるとのこと

これもリスト初期化処理とかで便利かなぁというところだけど
可読性とのトレードオフがあるから使い所は選ぶね

3.1.9　文字列定数、リスト定数のグローバル変数宣言

これもあれだな　グローバル変数定義だと
ローカル変数定義時みたいに確保と削除が無い分

ポインタ参照的な挙動になって高速化するというやつだな

1.0.10　ビット演算を用いた、条件判定の高速化

ちょっとこれ要約するの無理だなぁ
integer値が32までならビット演算で複数の範囲判定が同時に行えるという話

3.1.11 list の長さの非0 判定

listの長さがゼロで無い判定
(lst!=[])
listの長さがゼロの判定
(lst==[])

3.1.12 llGetListLength() [互換性に注意]

ちょっとこれ衝撃だなぁ

integer len = llGetListLength(a);
これは
integer len = (a != []);

こう置き換え可能で　listの!=演算が単純なブーリアン値ではなく
リストの長さの差分を計算するプログラムになってるんだってさ

で更に空リストをグローバル変数定義すれば高速化するとのこと

list null_list = []; // グローバル変数として宣言しておく
integer len = (a!=null_list);

ただしこの処理自体を関数化すると相殺されるらしいので
使い所ってことだと結構微妙かなぁ

でまぁこれこれちょっと今使えるかどうかわかんないなぁ

//-------------------------------------------------------------------------------

高速化の章の話はこれで終わり

常用するのはインクリメント・デクリメントと
あと代入処理のチェーンくらいかなぁ

計算結果定数の記述はまぁ詰めでやるくらいでいいかねと


以上

20191031 [怪文書]コンテンツ業界における貨幣経済圏と感情経済圏のお話

くっそ長くなったので怪文書として04/01投稿とする

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

正直ソーシャルベースでの
コンテンツの話ということだとねぇ

買う側が許容するクオリティの最低ラインて
案外高いのよ

でまぁそれ未満だとそもそも相手にされなくて
じゃぁどうすればええのかって話だと

一部のオタクさん方面の人らが
”ごまかし”とか”ズル”とか
言っちゃうような手法が必要になる

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

アマチュアクリエイティブの周りだと
そういうハックやテックを
極端に嫌う人たちがおって

じゃそういう人らが作るもんが
売れるようなコンテンツになってるかというと
ならねぇのよね　工数ベースで既に赤字だから

ほいでまぁそこで面倒な話になる

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

要はなんでそういうの使わないのかという話

そういうの使うとね
対象市場がグローバルになっちゃってさ

世界のトップランナーと戦うことを強いられるの
戦うステージが上がっちゃうのよね

クラスやサークルで一番絵がうまい程度の人間でも
pixivランキングとかだと100位入れない的な話

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

なのでやり方としては

”やり方を評価するニッチなコミュニティ”や
”そもそものコンテンツが少ないジャンル”
に向けてコンテンツ供給するという
生存戦略が考えられるわけなんだけど

そもそもそんな小規模なところで
生きられるだけの対価が得られるのか？と

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

そのへんでまぁお話としては
仮の話としてなんだけど

”貨幣経済圏”と”感情経済圏”が大雑把にあるの

両方ともある程度等価交換が成立するの
でまぁ代表例としてあくまで現状での話ということだと

MMDは感情経済圏で
VRChatは大筋で貨幣経済圏なのよ

でまぁなんというかそこでも面倒な話がある

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

感情経済圏ってさ

得られる対価で物理身体の維持が出来ねぇのよ
というか貨幣経済的な対価を得ることが

現状の法律や各種コンテンツガイドラインや
慣例では実質的に不可能なのよ

だから感情経済圏って名称を仮で使うわけなのだが
じゃぁ具体的な対価と価格って何よ？という話

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

ほんともう大雑把に大げさに表現するけど

星での5段階評価が存在します

星0は興味なし　星1は25点　星2は50点
星3は100点　星4は400点　星５は5000兆点

でこれには実際のところマイナスの星もあるのだが
”感情の振れ幅”ということだと
マイナスの星もそれはそれで価値が存在するの

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

でまぁ基本　感情経済圏では

そもそもの評価基準が個人で違うわけよ
等価交換という話だと星４以上のものにしか
価値があるように見えないように見えて

実際には５０００兆点が１単位として取引されてるのね

いいねが+5000兆点　badが-5000兆点　興味なしが0

で最近のトレンドは”表示しない”手法

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

要は　5000兆点以外の評価ボタンが存在しないの

等価交換の手法として
そもそも5000兆点の評価を対価として出さないやつには
コンテンツを供給しません

という感じの話になる
まぁちょっとこの辺は面倒な話だなぁと

ちなみに感情経済圏での
個人資産額は∞です　無限大

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

ほんで　感情経済圏で活動する人間に対して

物理身体を維持するコストを賄う方法として

太古から存在する
パトロン制度とかそういうお話なわけよと

自分の経済状況から可能な限りの”全て”を
貨幣経済的な対価で支払うという仕組み

なので本来そこに”コスパ”みたいなのは存在しない

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

随分話が長くなっちゃったねぇ

まぁ要は　実際のところの話としては

感情経済圏の話ということだと
どんな値札がついていようが
買うか　買わないか　以外の選択肢がないの
財布は常に無限大なので

でまぁ　貨幣経済的に困窮していて
買えない　というのはもちろんあるんだけど
それは別のお話なの

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

感情経済圏の財布は実質無限大で
そもそもの値札が存在しない
という話をしたところで

貨幣経済圏の話だと

”買うに値するかどうか”を値踏みするようになる
でまぁそうなると

そこで星の5段階評価が出てくるわけよ
要は貨幣経済圏のコンテンツに関しては
”タダでも要らない”が出てくるわけさという

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

もちろんあれよ
”タダでも要らないが仕方なく使ってやる”
みたいなことを
コンテンツに関して言う連中は
相手にしちゃダメよそもそも

ほいでまぁ貨幣経済圏だと
金払うのは最低限の礼儀で
”二度目はない”って切るのもそれはそれで正当なのよ

後払い方式は無理だねぇそういう意味だと

BENTOでのハンドコントロールについて

まぁ何をいまさらという感じですが
実際に制御ロジック組んでみての話

BENTOのハンドやグローブを作って売る場合には

「BENTOハンド対応のAO使う前提」

最低限の知識としてこれは覚えておいたほうがいい

あるいは売るほうが説明する必要があるなという感じ

理由は

既存のアニメの様に

「アニメ停止したらニュートラルポジションに自動で戻る」なんて

そんな親切な仕組みはない

アニメ停止したら停止したときのフレームで止まりっぱなしになる

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

既存のSLアニメは任意アニメ停止すると

即Internal Animation(システム標準アニメ)で上書きされるんだわ

ほんでSLのInternal AnimationにはBENTOで新規追加されたボーンに関して

全くのノータッチなので

BENTOハンドのアニメを停止すると文字通りの”停止”になり

ニュートラルに復帰しない

AO無しでリログすると実際ハンドがパーの形になる

なのでまぁこれの解決策はいくつかあるんだが

一番簡単なのは「BENTOハンド対応のAOを使うこと」なんだよねぇと

ハンド自体にアニメとスクリプトを組み込む方法は推奨しない

現状市販されているBENTOハンドやグローブを観測した結果

全部が左右別オブジェクト扱いで装着させてるので

両方にニュートラルにするだけのスクリプト入れたらそれこそクソオモになる

大体この辺かねぇ

以上

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万円前後のまともなグラフィックボードにすることは
現在移動すら辛くてビューワーがクラッシュしまくるような状況では
十二分に効果的なのでそこは誤解なきよう



以上

SANSARまともに体験したいならVRHMDをカウノデス

やはりVRHMD所有前提のインターフェースだった


でまぁSANSARのためだけに買うならRIFTの方がええんだけど
直販で一週間以上待つ覚悟とか色々考慮するとVIVEでもいい
　
ただVIVEをAmazonでまともなルート購入が　現在は不可能なんだよなぁと
　


新品で103000円は明らかにおかしい値付け
というかマケプレ出品なのでサポートつかないんじゃねぇかな

色々気にする人は　ツクモのネットショップで買っとけ　確実だ

VIVE Kit 99HAHZ049-00 《送料無料》 TSUKUMOネットショップ

RIFTも並行輸入品でも作動自体は出来るらしい？との情報がある
初期不良とか修理対応で詰むので　ガチで急ぐ人向けかなと

多少割高だし直販以外は基本
壊れたらジャンク屋逝きにしかならんのでかなりハイリスクだけど



直販はこ↑こ↓
https://www.oculus.com/rift/

というわけでSANSARをVRHMDでやった感想　について


・とりあえずHMDつけずにアポロミュージアム行け　ロード終わってからHMDつけろ
　初期ロードが大体一時間かかる上にバックグラウンドロードもないけど　耐えろ

　あそこがSANSARで体験できることのほぼ全てだ
　宇宙船とロケットが全部実寸なので十分博物館行く代わりになる

・アトラス内の”つかめる”オブジェクトはやはりハンドセット持ってる前提だった
　RIFTだと対象物をポイントして黄色い枠が出たらサイドトリガーで拾える
　投げるモーションの加速具合は結構ピーキーと言うか十分強いので
　別にフルスイングしなくてもOK

・移動は割りとVRで標準的な方法
　ルームスケールじゃなくてもOK
　スティックでポイントすると放物線でマーカーが出る方式と
　スティック自体である程度平行移動が出来る


・初めて訪れるアトラスは全部ローディングで固まる
　これバックグラウンドロード　とか　予約ロードが出来れば随分違うんだが
　そういうのが一切出来ないのでもう致命的な欠陥レベル
　steamVRでもOculusHOmeでもバックグラウンドロードくらいは出来たぞ

・VR　Readyならとりあえず全アトラス大丈夫？
　使ってるグラボがVR　Readyじゃないのでカクついてるっぽいのだ
　グラボアップデートしたらまた見に行ってみるかねぇという感じ


大体この辺かなぁ
とりあえずVR　Readyの最低ラインであるGTX1060　6Gのグラボは以下の通り

コスパ厨に受けがいい3Gモデルでは多分ムリなので
モデル選定に対して出力可能枚数とファン数を重視した

シングルファンモデルはケースサイズで物理的に入らない場合を除き
積極的に選ぶ対象にはならん




以上

SLRRモーターコア関係での問題解決メモ

今回の話の要点

・問題
　子プリムとルートプリムを同じ位置に配置して
　子プリムでセンサーを実行した場合
　ルートプリムで実行した場合と挙動に差が出る

　具体的には完全に同じ座標にある別オブジェクトが
　子プリムでは検出できない　ルートプリムでは検出可能


・解決策
　子プリムの位置を極小距離オフセットすることで解決



じゃ本編


○はじめに

SLRRで車体を回転せずに後退させるために必要な措置についての解決


要はルートプリムと同じ座標に回転するセンサー置いて

そいつで計算させた結果を使って全体を移動すれば
その場で車体を180度旋回させるなんてクッソダサい動きしなくていいわけよ

ルート以外全部回転させるって荒業も前には試したけど
SIMラグがひどいときとかはトランスフォームに数秒かかってて
結局180度回転させるのとあんま変わらんじゃんみたいな


でまこの仕組を路面電車リリースした後に移植作業してたんだけど
で致命的な問題が出て正常に作動してなかったのが
今回動くようになりました　ヤッタネ

○現象

停止位置マーカーに到着した際の不可解な挙動

具体的には　ルートプリムでセンサーを実行している際には
座標的に完全に重なっている別オブジェクトをセンサーで検出出来ていたんだが

(これは到着オブジェクトが停止マーカーかどうかを検出させるルーチンで一番重要)

子プリムではゼロ点で重なっている別オブジェクトをセンサーで検出出来ない

(これ多分厳密には座標系が違うとかそういう関係の話だと思うが未検証)

○解決策

センサープリムを進行方向に対して0.001m後ろにオフセットすることで解決


以上

SANSARについて 雑に

とりあえず結論としては

現状VRHMD持ってないなら行っても実質的に移動以外何もできん上に
要求PCスペックも高いので一般消費者が行ってまだどうこうなるものではない

んでもって新しもの好きの純粋消費者にとってはSL2になるかもしれんが
既存ユーザーにとってSLの代わりになるものでもない　というか別物



じゃ適当に解説


○まずSANSARのプラットフォームとしての立ち位置

初期は次期SLとかNGPとか言われてたやつのようだ
SLのシステム上のネガというか
主にグラフィックのアップデートに関する障壁を取っ払って
よりリッチなコンテンツによるエクスペリエンスを目指したようなんだけど

ゲームエンジンのライセンス周りとかコンテンツ供給者との
すり合わせがうまくいかなかったっぽい

でまぁVRHMDが流行ったのでそっち方面に舵を切ったと

そういう部分では　ある意味2007年あたりのSLと似てるんだよな

当時の"ハイスペックパソコン”の使いみちの一つだったり
現在のバーチャルマネーブームの流れだったり

とにかく最新の流行りのガジェットの”使いみち”の一つという感じ

2007年当時のゲーミングPCがSANSARにおけるVRHMDだな



○入れるステージ(Atlas)の中身について

まぁSIMエッジが無くなって
オブジェクトが全部ゲームレディのmeshデータになったSLという感じ

ほんともうぶっちゃけて言っちゃうとVR対応したBlueMarsだもう
カメラ回転の制限がきついところとか
最初にAtlasのデータ全部ダウンロードさせられるところとか
ランディングがAtlas選択なところとかがモロだ

Atlasのデータがバックグラウンドでダウンロードできねーのに
一回マップがローディングになると一時間ほどなんも操作できなくなるので
これはもう致命的な欠陥言っていいれべるなんじゃねぇのと

でまぁVRの使用用途の可能性
として一番わかりやすいのはアポロミュージアムだ
実在するミュージアムにいかなくても所謂”サイズ感”とかがわかるのが
あーいうVRミュージアムのメリットだな

SLでも似たような試みはされたんだけど
移動が見下ろし視点で天井が高くなってしまうためにどうしても限界があり

かといってマウスルックのようなFPSスタイルで
3D空間を動き回るのはかなりの特殊技能なので
自分の目で見るリアルサイズ感みたいなのはVRならではじゃないかなみたいな



○操作等

一応通常のPC環境でもステージに入ることは出来る
が　見下ろし視点で移動が出来るのみ　歩く以外の移動手段がTPしかない
その歩きがもう問題外で遅い　なんなんだアレはｗ

ctrl押しながら任意の場所をクリックするとTPみたいな動きをする
これ自体はVRコンテンツでよくある操作方法なので特に違和感とかなし

ステージ上の何かに干渉するためにはVRHMDのハンドセットが必須のようだ
マウスやキーボードではステージ上にあるオブジェクトに対する操作が一切できないので

アポロミュージアムでの音声再生やゲームエリアでのボール投げ等も出来ない


ちなみにマップ上でVR使ってるかどうかは割とすぐにわかるというか
腕の動きが明らかに違うので実際に見てみることをおすすめする


○VRHMD所有者に試してもらった

ボールは投げられるようだ
ただボールを拾う操作がかなりシビアなようで

拾おうとして手を近づけすぎるとめり込んですっ飛ぶとのこと

通常のVRプラットフォームなら
ハンドセット向けて拾う操作すると吸い付くようにピックアップされるぽい
あとボールを持った手　の形もなんかおかしいらしい　実装抜け？


○終わりに　儲かるの？的な

現在自宅に自分用のVRHMDを手に入れることが出来ている人間は
確実に最新技術に興味を持った金持ちなので

そういう人間向けにコンテンツを供給する場　になるんだろうな
あくまでVR主体　VRじゃないモードは添え物というかおまけという感じ

んでもって実はそういうコンテンツって今のSLで
フリッカーさん達が好むようなmeshコンテンツそのものなので

現状SLでゲームレディレベルのmeshコンテンツを
自作出来るだけのスキルを持っていれば
コンテンツ供給者としての技術障壁ってことだとあんまりないのかなみたいな

ちなみにゲーム内通貨はs$って単位になってて
レートは1$が100S$でほぼ安定してるので

1s$が1円くらいの認識でよさげ


以上

一般論として高く売りたいなら売れない原因は潰しといたほうがいいんだけどねみたいな話

一般論だよ

かといってリリースしようとする時点で

んなこたわかってるよ
潰せるんだったら潰しとるわバカみたいな話にもなるので

ある程度QAみたいなことが出来る人間にテストしてもらうか
テスト版ってことで安く出して
人柱から意見を集めるみたいなのが手段としてあるわけです

金銭的な開発コストはただ作るだけの制作費の倍以上かかる

まぁでもそこでワイとかみたいな
めんどくさい操作方法しまくったりして粗の指摘しか出来ない
性格の悪いキチガイにエンカウントするのが嫌だってんでしょ


んでもってそういう連中が提示する"解決策"も
あからさまに実現することが不可能ないちゃもんとして受け取って
それをやるんだったら売る意味ね～じゃん
もうこっちに関わらなくていいからどっかいけばーか
とかそういう話なんだろ


でまぁあれよ
SecondLifeという場所への参加者として自分のクリエイティビティを
発露する行為自体を否定したいわけじゃねぇのよ

ただ権利を行使したときの責任ってもんもあるわけよ
大体の場合責任の度合いはそのまま値段なわけよ

その上でまぁ”可能なら高く売れて欲しい”ってのがあるだろうし
そのために

でも高く売れるために自分のスタイルを貫けないなら
やらんほうがマシだみたいな意見も尊重したい


でまぁ

大体の場合○○が欲しいから作ったor調べて買ったみたいな人間は
それを手に入れるためにものすごい調べたりするはずなんだよ

なのでもう
同じく○○が欲しいと思っている同士がそれを買ったりした場合

貴様が欲する○○はその程度のものだったのか？みたいな部分で
価値観やらなんやらの相違で行き違いが出たりするわけさ


△△から出てる○○？知ってるよ　でも出来が悪いから買いません
これで済んでれば簡単でいいんだけどねぇ

大体そういうのって間違って買っちゃって
期待以下の出来だから(´・ω・｀)ｼｮﾎﾞｰﾝみたいな経験があり
それはそれで学習して目利きになるしか無いってのが
長期的な話ではあるんだけどそれ続けるのも結構大変よほんと



てかほんとそういう人は”気に入るもっとすごいもの”
が見つかるといいねぇ的なことを純粋に思うわけ

でまぁ可能なら教えてーなみたいな
(お前には教えてやんねーって？　それも一興)

以上

SLRRモーターコア 計算方法のお話 メモ

三角関数の話です

うろ覚えなのでソース確認しないとだな

・二等辺三角形と三角関数を利用したRの決定

・レールにカントがついている場合のrot決定

・KFMでそれらを記述する方法

・二等辺三角形と三角関数を利用したRの決定

扇形軌道の視点と終点の接線の角度と直線での二点間距離で

二等辺三角形を作図するです

ベジェとか出やったほうがきれいに出るけどめんどくさいでしょあれ

なので先にRとθだけで作図出来る方法をやるです

まず現在の向きと位置をpos1,rot１として
ターゲットとなるガイドオブジェクトの位置をpos2,rot2とします

んでrot1とrot2に<1,0,0>を掛けて導き出した方向ベクトルをvec1,vec2

方向ベクトルから導き出した平面上での方角をdir1　dir2とします

dir1 = llAtan2(vec1.y,vec1.x);
dir2 = llAtan2(vec2.y,vec2.x);

んでこっからRを算出しますが
これはpos1,pos2間の距離とdirの角度の差を利用します

確か X=Rsinθ辺りの式を変形するとRを出せる式になるです

なので　まずXを決定します

Xはpos1とpos2の中点座標までの距離で出てくるので

そっからX= llVecMag(pos2-pos1)/2とかだったかな
θ = (dir2-dir1)/2 だったっけかなぁ

これでパラメータ全部埋まったのでXとθからRが出ます
んでRが出たらそっから移動速度とフレーム数で円周上の距離を割ると

移動モーションで扇形軌道を描く線を通すための
Rとθが決定するので

あとは頑張って座標プロットしてモーション組んでください


・レールにカントがついている場合のrot決定

割と単純な座標計算です

<0,0,1>のベクトルをrot掛けてvec1_1出してな
これの前に出したdirの式使って正規化する

vec1_1=vec1_1/llEuler2Rot(<0,0,dir>);

これで正規化した”傾き”のvectorが出るからな

そしたら　kant = llAtan2(vec1_1.z,vec1_1.y);

これでいけっかなぁ

まぁ航空機でのピッチロールヨーを出す数式と基本的に一緒

航空機と違うのは表示機ではなく実際の移動に使う部分だな


・KFMでそれらを記述する方法

とりあえず円は多角形で近似出来るだろー

フレーム最小のθとR使ってフレーム間距離出してな～
そしたら曲がる角度と移動距離が決定されるので

あとはそれをKFMに記述するだけでOK


大体この辺でいけるはずだ

んでこの理論で組んだモーターコアつくって
移動速度の外部コマンドでコントロール出来るブラックボックスにすれば
ツアーライドとかあのへんに汎用的に使えるんじゃねーの的な

以上

ランドマーク式テレポーターで３SIM以上飛ばさないとあかんようになった場合の話

とりあえずSIMエッジ超えるときの進入距離は4m取ること

以上