2017年8月25日金曜日

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

今回の話の要点

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

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


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



じゃ本編


○はじめに

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


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

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

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


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


○現象

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

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

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

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

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

○解決策

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


以上

2017年8月21日月曜日

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しかない
その歩きがもう問題外で遅い なんなんだアレはw

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

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

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


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


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

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

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

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


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

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

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

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

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

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

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


以上

2017年4月27日木曜日

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

一般論だよ

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

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

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

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

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


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


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

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

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

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


でまぁ

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

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

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


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

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



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

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

以上

2017年4月24日月曜日

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

三角関数の話です

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

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

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

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

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

扇形軌道の視点と終点の接線の角度と直線での二点間距離で
二等辺三角形を作図するです

ベジェとか出やったほうがきれいに出るけどめんどくさいでしょあれ
なので先にRとθだけで作図出来る方法をやるです


まず現在の向きと位置をpos1,rot1として
ターゲットとなるガイドオブジェクトの位置を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


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

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

以上

2017年4月11日火曜日

ANHELOのVIAS-API 軽くテスト

とりあえずドキュメントはここのようだ

http://www.anhelo.style/products/m28/devel_ja

ワイがセットアップで詰まったとこ

・ホイール回転周りの挙動になんかよーわからんところがある

とりあえずスクリプトリセット時にハードリセット毎回かけりゃええみたい
いやこれハードリセット後に安易にソフトリセットかけたらあかんのか

確実な作動を求めるならソフトリセットは使わんほうがええ

でまぁここだけクリアすれば
普通にコマンド通ってるしなんとかなるんでね?



んでまぁその他留意事項

・基本的に外装制御コマンドが全部別

まぁアナログマティックだからここビットフラグにするわけにもいかんだろうしな
この辺の制御は既存連中からするとAPIにぶん投げる前の演算が要るな

・アニメ制御がAPIに入ってない?
多分これこだわる連中はアニメにステアとか入れるだろて判断かねぇ

てな辺りかね



まぁこれぶっちゃけ共通APIにするためのセットアップ職人も必要だよなぁと
でも社外スクリプトシステムで”めんどくさい”とこ全部外出しだし

最初にこいつに対応したスクリプトさえ組めれば
サドパのチューニング屋は楽ができそうだねぇ

みたいな

以上


2017年4月9日日曜日

カースクリプトの世代に関しての話 その2

その1

補足説明というかより実用的な話

入力に対するレスポンスの話というか

まぁ要は入力に対する出力の話とか利便性の話なんよ

第一世代はまぁ昔過ぎて排除だ

第二世代と第三世代の違いに関して

とりあず超低速での登坂能力と

確実に作動するブレーキとバックギアな
これがついてりゃ大体の問題は解決する
というか既存ヴィークルでまずいやつの
ストレス原因大体そこなので

"さっぱり操作したとおりに動いてくれない"これだ

バックギアに関してはバックギアというギアを入れろって話じゃない
それをやるとレースシムになってしまうからな

停止状態 もしくはそれに近い状態で
ブレーキを押し続けるとリバースに入る機能
んで入ってから離せばすぐに止まる
この部分の動作が確実になることが求められる

それでいてブレーキを使いたいタイミングでバックに入られても困る

でまぁこの話を前提とした上でDTCARの話だ

DTCARがダメな理由の10割って入力がすっぽ抜けるんだよ
しかもそれがラグじゃなくてロジック上の問題なんだよ

DTCARのControlイベントのレート自体は別に他のと変わらないんだよ

ただ確定タイミングがタイマーイベントなんだよ
つまりアクセルのオンとオフって入力がある場合

押してから離すまでの時間が短いと加速しないし
かといって最低レートが0.2秒なんだよ
つまり一回アクセル踏んで離すまでの時間が 0.2秒の次は0.4秒なんだよ

時速100キロでなら一秒で27m動くんだよ
実際のレースの速度域って200キロオーバーだろ 50mだよ

んでその速度域だと
アクセルオフしてからまたオンにするまでに0.2秒なら最低10m進むんだよ 
ステアリング入力も同じレートだ

そんないつ切ったら曲がるかがギャンブルみたいな
ガッタガタのステアリングと
入力してから効き始めるまでがランダムな上に
細かいタイミングでのオンオフを受け付けないアクセルとブレーキで
どうやってその速度域で安全運転しろっちゅうねん

Arlon系ならとりあえず入力してから作動するまでのディレイは確実に一定だし
オンからオフまでの入力をとりあえず全部拾ってくれる


んでまぁ別にここそこまでスクリプト的に難しい問題かってーとそうでもねぇのよ
そうでもねぇんだけどメインロジックほぼ全交換な上に
ヴィークルパラメーターのセオリーがわかってないと
同じフィーリング出せるようになるまでに数ヶ月かかるんだよ


今なら一週間くらいで出せるやつもいるだろうけどね


んでもってそこ改善したらもっと売れるようになるかみたいな話だと
現状さっぱり売れてないなら売れるようになる”かもしれない”という程度だ

そのへんは車種のチョイスとかガワの出来もあるし
エフェクト周りの演出も影響するしなと

以上