VICE WIKI のインターネットアーカイブあったわ

ちゅわけでURLはこれだ

http://web.archive.org/web/20120319080740/http://vicecombat.com/index.php?option=com_content&task=view&id=59&Itemid=67
このダメージチャートあるだけでも随分違うんだよねぇ

以上

年末商戦 VRHMDを買うならどれよ？という話

まぁ雑に

・PC用VRはどうしてもプレイしたいコンテンツが具体的にあって
　予算もPCのアップグレード込みで最低20万くらい準備できるなら今買っても問題無い

　買って後悔するのが嫌なら第二世代VIVEの発表やwindows10がVR対応する来年を待て

　エロ目当てならVIVEがええ
　Riftはトラッキングセンサー周りの問題が多すぎるのでオススメしない

　RiftのDK2とDK1は　もらえるならアリだがわざわざ買うのはやめとけ
　今となっては低スペすぎて地雷だ

・予算10万ならPSVRで一式揃う
　ただしプレイできるタイトルが基本的に既存ゲームシリーズのスピンオフばっかりなので
　もうしばらくタイトルが出揃うまで待ったほうがいいかもしれん


・SLでVRやりたいなら　LumiyaてビューワーがVRモードに対応した
　対応するスマホは　とりあえずdaydreamとかcardbordとかその辺対応してるかをチェック

　android6.0対応のキャリアスマホなら大体ついてるはずだ
　ハードの機能的な話だと"ジャイロセンサー"ってのを積んでるやつを選ぶこと

　ちょっと前ならポケモンGOのARモードフル対応してるかを確認すればよかったんだが
　最近は互換モードで動いちゃうからなぁと


大体この辺

以上

メモ ワイヤリングでIKを使う場合の話

まぁあdaeでエクスポートするときは結局マージしないといけないけどね

バージョンは2.77

参考サイト

インバースキネマティクス(IK) その１【Blenderの便利な機能を超簡単に紹介】


IKのやり方について

まずそれっぽい形状にベースのワイヤーを作る

アーマチュア(ボーン)を作って　ワイヤー→ボーン　の順番に選択して親子付する

ウェイトはとりあえず自動でもいけるみたいだけど
挙動的にウェイトペイントはやり直したほうがよさげ

ウェイトペイント手順は
アーマチュアをポーズモードでボーン選択
その後オブジェクトを選択してウェイトペイントモードにすると

あとは選択したボーンのウェイトが出て来るのでペイントで修正する
ペイントのブラシは左側に切り替えボタンがあるはずだ


単純に位置だけ調整でなんとかなるワイヤリングならIKのみでいけるが
そうでないなら"たわみ"の挙動が自動だとあんまよくないので

ボーンの回転ある程度手付けせんとだめくさい


IKのチェーン長に関しては
デフォルト設定のままいじるとゼッテー崩壊するので
ある程度設定は見といたほうがいい




dae出力する前段階のマージする話　最終的な手修正が必要な場合も同上


とりあえず　ワイヤ→アーマチュア　の順番で選択して移動コピーする

ワイヤ側についてる　モディファイアのアーマチュアを適用してしまう

そのあとプロパティのオブジェクトタブで　ワイヤの親子関係を削除
（ここの手順で結構ハマってしまう場合がある）

親子関係カットしたアーマチュアは邪魔なので削除してしまう




作業中にハマりそうな罠

モディファイア適用のチェック入れて出力すると何故かポリゴンメッシュが二重化するので
出力オプションに頼らずに複製して適用して出力すること



大体この辺だな

以上

割と旧世代の書かれ方したスクリプトを現代の技術で軽量化する場合のお話

具体的には１プリム複数スクリプト状態を是正するための話

・リサイズスクリプトはllScaleByFactor使っとけ

　http://wiki.secondlife.com/wiki/LlScaleByFactor

　これで回避出来ないissueはMOD可にして対応しろ 時間と手間の無駄になる

　スクリプトでリサイズしつつ平面マップ貼り付けした面をどうにかしたいとかだと

　とりあえず面番号と貼ってあるテクスチャのUUIDは現状どうやったって必須なので

　そっち方面の専門家(最低でもダンプが取れること)に依頼して
　専用ロジックを組んでもらう以外の方法は無い

　可能ならルートプリムのXYZどれかを1Mとかにすると

　いきなりリセットかかったりした際の管理が楽だ

あととりあえず避けないといけない部分として

・物理ヴィークルで特定のプリムのみでコリジョンを拾いたい場合は

　そのプリムにスクリプトを入れてLSL2でコンパイルする

これだけはもうSLのSIM自体のバグによるものなのでここだけはどうにもならん

ヴィークル系で完全シングルスクリプトのは無理だ　諦めろ

あとはレスポンスアップとか作動のスムースさの話

・llSetLinkPrimitiveParamsFast は可能な限り最小の回数で済ます

大昔だと大量のパーツを同時稼働するためだけに

全部の稼働プリムにこれだけが入ってるやつとかあったっぽいな

 PRIM_LINK_TARGET　これを多用すること

　逆にこれを使えない構造になっているロジックはレートコントロールとか考えたほうがいい

・SetTextとTargetOmegaはllSetLinkPrimitiveParamsにある

大昔のスクリプトだとボタン類とかホイール類で

この辺やるためだけにスクリプト分割するのが常道だったんだけど

現在ならPRIM_LINK_TARGETと併用することでスクリプトを使わなくて済む

・テクスチャアニメとパーティクル再生は一枚のスクリプトに全部ぶちこむ

 http://wiki.secondlife.com/wiki/LlLinkParticleSystem

 http://wiki.secondlife.com/wiki/LlSetLinkTextureAnim

これでカバー出来ないレベルで大量のパーティクルやテクスチャアニメの同期制御があるなら

コンセプト自体に何らかの間違いがあるから再検討すること

・モデリング段階でのピボットオフセットは場合によっては危険だが有用

　当たり判定を考えなくて良くて関節が一個でスイングさせたいだけならかなり有用

　ただし自動車のドアみたいな複数の関節制御や

　ある程度形状通りのまともなコリジョンが必要な場合はスクリプトでやったほうがええ

手動リセットする手段が無いスクリプトで複数ステートをまたぐ場合 onrezが無いと死ぬ

ものすごい具体的には

特定の変数をリセットしたくないがイニシャライズだけは通したい　みたいな場合な

現状でinit　みたいな初期設定ステートがあり
そっから　mode1　mode2みたいな分岐の仕方するやつ

resetってステート作って一端全部そこに飛ばしてから　initを通す場合

reset自体に　state_entryしかない場合

resetに飛んでstate_entryが始まる前にtakeやdetachされると

state_entryが破棄されて　再び装着やrezをしても

resetのステートから抜ける手段が存在しないために
その状態でスクリプトがデッドロックになる

対策は
全部のステートに何らかの形でonrezイベントなりattachイベントを入れて
そっちで正常系の作動をするように修正することとなる

今更こんなとこで引っかかるやついないだろと思うんだけど

まぁ引っかかってしまった当事者なので記録とする

以上

完全シングルスクリプトタイプの飛行機はSIMエッジで謎のスピン暴走して死ぬ

ちぃ覚えた(このネタ通じる人間はおっさんだよなぁ)


対策は完全シングルを諦めればいい
あとレガシーな飛行機で大丈夫なやつを参考にするとか

(ほんと具体的な対策はインワでそっち方面詳しい人間に聞くがよろし)

以上

SLRR用車両 汎用システム化のためのモーターコア作成

メインランドのホーム脇にリンデン製の車両基地が建設されていたので

久しぶりに実験中だったモーターコア引っ張り出してみるかーと

要求仕様的には最低限のコマンドぶっ叩いて
座標演算とかの部分はブラックボックスにしてしまうのが目標で

現状そこのモジュールまではできてるのであとはフロントエンドだなぁと

とりあえずキー入力で適当に走れるようにするところまではもってきた感じ




まぁ要はなんでこんなもんが必要かというと

造形段階でXYZ軸ちゃんとやらないようなおバカさんとか

造形の都合上ルートプリムの位置がどうしても変えられないとか

複数のスクリプトやアバターでの制御がやりたいだとか

後進も出来るようにしたいけどルートプリム回すわけにいかんしけど
センサーの範囲は可能な限り狭くして軽くしたいとか

複数台連結しての同調走行とか　車掌が緊急停止スイッチ押せるようにしたいとか

そういうのをやるのに単純なコマンドだけで動かせる
ほとんどブラックボックスみたいなセンサモジュールが必要なわけです



とりあえず初期目標としては今売ってる路面電車のセンサの入れ替えか

こういうふうな二人乗り動力トロッコでも作れたらなぁ的な

という辺り

以上

レンタルの家賃をL$で払ってる場合のお話 (リアルマネー利用でのL$入手手段)

現状L$買う手段としてほんともうクレカ持ってる前提っすね

銀行口座しかない　クレカ無いという状況は
ちょっと前まで未成年でしたみたいなのじゃない限りはないと思いたい


L$購入の手段としてはpaypalもあるんだけど

日本だとpaypalで支払いが出来るようになるためにクレカが必須という
無限ループ状態なので正直めんどくさい


んでまぁそこにVISAデビッドってのが存在するわけで
(使い方自体はクレカと同じで決済時にに毎回口座に請求が行われるカード)

免許証とスマホもってりゃ申し込みできます
詳細はググれ　現状ではジャパンネット銀行ってのがおすすめだ


んでこれ作っとくとsteamでゲーム買うときに便利
あとminecraftが公式サイトから買えるし
payplaの認証も通ります

VRヘッドセットも注文できる(通るかどうかはやってないので知らん)

という辺り

以上

20160630 地上ヴィークル メモ

http://wiki.secondlife.com/wiki/Category:LSL_Vehicle/Parameters

メモ程度に

まずハンドリングについて

VEHICLE_LINEAR_DEFLECTION_TIMESCALEがトー　と　タイヤの横グリップで
VEHICLE_ANGULAR_DEFLECTION_TIMESCALEがキャンバーってのは

感覚的にセッティングするならこれで問題ないな　昔と変わってない
いわゆるパワー　的なパラメータ部分はハンドリングにはあんまり関係がない

てのが空気抵抗や転がり抵抗タイヤのグリップ限界みたいなもんがSLには無いので
(慣性が摩擦抵抗で消えないのではベクトル変換的には減速が必要)

そをを　LINER　のパラメータを動的変化させることで
タイヤのグリップサークルの様なものを演出することはある程度は可能
SLのヴィークルに荷重移動という概念を入れるのには必須の制御だけどね

LINERとANGLERのDEFRECTIONにも適当な倍率をかけられるようにしておくと

サイドブレーキでリアをブレイクさせるみたいな挙動を擬似的に与えることが可能



速度比例でのVEHICLE_ANGULAR_MOTOR_DIRECTION　可変制御の限界について

VEHICLE_ANGULAR_MOTOR_TIMESCALEとVEHICLE_ANGULAR_MOTOR_DECAY_TIMESCALEが固定値で
VEHICLE_LINEAR_MOTOR_DIRECTIONでの加速制御に
なんの動的介入もしていないスクリプトの場合

発進加速領域で加速力が強すぎて過剰に旋回しちゃうんだよな
んでもってVEHICLE_ANGULAR_MOTOR_DIRECTIONの限界が4*PIなので
ある程度の領域を超えると
旋回力パラメーターを上げまくったのに高速で曲がらない　低速で曲がりすぎ　となる


大体の旋回力制御スクリプトの数式が

旋回力　=　速度　/　ターンレート　となっているので

ここの数値は理論的に出す場合
限界値は　最高速（m/sec）/12.56となり

100m/sec(360km/h)で約7.96分の1　0.12倍が限界となる

んで大体のスクリプトでこのレートは感覚的に3辺りが初期値となっているので

この設定値での限界速度は約135キロ

つまり地上ヴィークルでの実用限界速度は理論上はで時速135キロまでとなる

案外限界低いなｗ

まぁもちろんこれ以上をやるためのハックはいくつかあるんだけど
(一番メジャーなのはインパルスでぶっ叩く手)

それをやっただけでは慣性までは殺せないし
操作のリニア性に影響するので個人的にはあんまり推奨されないという感じ

ただダウンフォースでの高速域旋回性の向上とかをシミュレートするのにはちょっと足りんので
常識的な範囲で試してみるのは手かもなぁインパルスでぶっ叩く手



今回はこの辺

以上

firestrom 64bitビューワ向け グラフィック設定

割と最近のPCを使っていて
他の最近のゲームでは特に問題なくてSLだけ重いとかの環境で

32bitビューワだと落ちまくって64bitだと比較的安定する場合向けの話

メモリとCPU GPU が十二分にある状態で
フレームレート低下が起きる場合 大体メモリかバスの転送レート不足です

んでまぁSLビューワは2007年代から
全体的にバスの帯域不足によるパフォーマンス低下が顕著です
(ネットワーク キャッシュ からメモリ・グラボへのデータ転送 等)
とりあえずメモリ増設しろ言われるのはその辺

根本解決は一般的な環境では不可能だと思っていい

まず基本的なグラフィック設定から

SLビューワー自体は所詮2010年以前のグラフィックエンジンなので

基本的にはグラボさえ積んでれば全部のチェックボックスをONにしちゃってい

ただその分全体的にポリゴンメッシュのスライダは減らす方向

アバターは下げきっちゃっても自分の表示は特に問題ない

最近のフルmeshアバターだとオブジェクトの方が重要になる

次にハードウェア設定

んでまーこの辺が割と重要というかパフォーマンスの底上げに必要な部分

異方性フィルタ VBO 辺りは最近のグラボならONのほうが大体FPS出る

んで今回のポイントはテクスチャの不可逆圧縮

これかけるとスカルプが歪むんじゃないかという危惧があったんだけど

グラボに転送されるデータとしてのテクスチャは圧縮されても特に影響は無いっぽい

色に影響するのでSS撮る時は切ってもいいかもしれんが所詮誤差レベルなので常時ONでいい

アンチエイリアスは4以上にしたほうがいい

2以下とか切ってるとFPSが下がる謎現象が発生することがある

テクスチャメモリ これはVRAMが2GB以上のグラボで

メインメモリが16G以上メモリ積んでるなら1024にしちゃっていい

シェーダーでもVRAM使うけどSLビューワーくらいなら問題ない

レンダリング設定

このタブのテクスチャの読み込み精度 は弄ったらダメ スカルプが死ぬ

アルファマスクは特に事情がなければONでいい

グローの強度がデフォで２になってるけど気にするな

フレームレート制限はつけとくとトータルでのFPS変動が減るのでおすすめだが
もともと酔いやすい人があんまり低い設定にするとダメじゃねーかなぁ

装着している 光源 と パーティクル はOFFにする必要はあんまりない
あえて切るってーとグリーファーとかのの警戒任務についてる場合くらいかねぇ
rez禁止エリアでならスパム系がこれで防御できる

プレキャッシングのディレイはランディングとかで影響する
TP直後に落ちまくるとかの症状がひどいPCだと遅らせるほうがいい

影の品質はパフォーマンス優先なら１にしちゃっていい

地面のテクスチャの精度 はあんま下げ過ぎるとダメだが
今更ただの地面使ってるSIMあんまないから影響はないっちゃないんだよなぁ



大体この辺かね

以上

2016夏くらいを目処にPCを完全更新する場合のお話

SL向けにPC更新する場合のお話

SteamとかOriginとかMinecraftもやってる前提で

スペック的に無難にクリアしつつ予算抑える構成


市販やBTOマシンはとりあえず無視ね 自作前提


CPUは最低 i5 6500

マザーボードはZ170 microATXが最低ライン

M2SSDが使えるといいけど普通のでもおｋ 最低500G HDDは任意で追加 最低2TB

電源は700Wでいいかな

グラボは GTX1070が出るだろうからとりあえずそれで

メモリは最低でも16G積むこと

光学ドライブは別にいいや

OSはとりあえず10で

モニターは4Kか フルHD二枚推奨

大体この辺かな

以上

2016春 SL向けPC最低ライン 等

予算3万以内程度で延命措置程度にアップグレードする場合

・Core i シリーズのCPUの場合

 OSを64bit版にアップグレードしてメモリ8G程度積む
 どうしても32bit版じゃないとダメな場合 RAMDISKにしてキャッシュ割当

・グラボが6xx以前のもので電源に不安がある場合

 玄人志向の750Ti補助電源無しロープロファイルモデル が最低ライン

 ＰＣＩｅｘスロットすらない場合はマザーボードから買い替え

・キャッシュをRAMDISK もしくはSSDに


 これだけで随分ましになる




んじゃ買い替え最低ライン



・ガチで予算がない場合(非推奨だが実質の最低ライン)

1000円単位で予算が妥協できない場合は中古も視野に

新品の場合

マザーはH110 メモリは16G CPUはi3を最低ラインくらいで見とくこと

グラフィックは基本シェーダーoffでオンボ運用 30fpsはとりあえず出る

どうしてもグラボほしいなら750ti入れとけ 無いよりはいくらかマシだ

将来的にグラボ積む予算があるならマザーをZ170にするといい

H170やB150をあえて選ぶ意味なんてもんはSL用という意味では全く無い

HDDは流用しとけ SSD入れるのも手だけど

電源は流用するか適当なのを買えばおｋ OSだけは64bitにすること


・ある程度予算はあるがコスパ重視の場合

CPUはi5の6500 マザーボードはZ170のMIcroATX メモリは最低16G 余裕あれば32

グラボはGTX660のVRAM4Gモデル (2Gでも可)

SSDはM2の500G 追加でHDDを2T

ケースはミニタワー 電源は80PlusGOLD で2万円前後のやつ
セミプラグインくらいでいい 700W前後


・予算が潤沢にある系

BTOで i7 980Ti だけ見とけばおｋ AMD選ばなきゃどれも一緒



てな辺りかね

以上

SLにおける 基本的な 乗り物 武器 移動補助装置 の基本操作について

SLにあるもんでrezや移動補助を伴うものはいくつかあるわけなんだけど

同時に使える操作キーは 実質のところ最大で7つ
排他利用のものはカッコ書きとすると

前 後 右(回転) 左(回転) 上 下 マウスボタン(一人称視点マウスボタン)

標準ビューワーでのキーボードでのキーバインドは

前 : w
後 : s

右回転 : d
左回転 : a

右 : shift+d
左 : shift+a

上 : e
下 : c

こうなってる 所謂WASD配列というやつ
FPSとかだと 上が space 下が ctrl になってることが多いけど
SLの場合 eが上 cが下です 慣れませう



んで以下に代表的な操作方法を書いておく





・一次元機動ヴィークル

 例：鉄道車両

前 : 前進(あるいは速度のトグルアップ)
後 : 後退(あるいは速度のトグルダウン)

右回転 : なし
左回転 : なし

右 : なし
左 : 無し

上 : 無し
下 : 無し





・二次元機動ヴィークル

 例：一般的なバイク 自動車 モーターボート ヨット

前 : 前進
後 : 後退 もしくは 減速

右回転 : 右旋回
左回転 : 左旋回

右 : なし 右旋回 もしくはドリフト右
左 : 無し 左旋回 もしくはドリフト左

上 : 速度上限アップ(ギアアップ)
下 : 速度上限ダウン(ギアダウン)

 例：一部のバイク

前 : 前進
後 : 後退 もしくは 減速

右回転 : 右旋回
左回転 : 左旋回

右 : なし もしくはギアアップ
左 : 無し もしくはギアダウン

上 : 前タイヤ もしくは 後タイヤ アップ
下 : 前タイヤ もしくは 後タイヤ アップ

・三次元機動ヴィークル

 例: 飛行機

前 : 機首下げ (下降)
後 : 機首上げ (上昇)

右回転 : 右ローリング もしくは右旋回
左回転 : 左ローリング もしくは左旋回

右 : 右水平旋回
左 : 左水平旋回

上 :  スロットルアップ
下 :  スロットルダウン

 例: 宇宙船 ヘリコプター

前 : 前進
後 : 後退

右回転 : 右ローリング もしくは右旋回
左回転 : 左ローリング もしくは左旋回

右 : 右水平移動
左 : 左水平移動

上 :  上昇
下 :  下降

・装着型の射出装置

 例: 銃等の武器類 スプレー缶 ジョークグッズ

 基本的にマウスルックで使うことになる

前 : 前進
後 : 後退

右 : 右水平移動
左 : 左水平移動

上 :  ジャンプ
下 :  しゃがみ

マウスカーソル : 射出方向決定 上下左右を向く

マウスボタン : 発射

・射出装置がついた二次元機動ヴィークル

 例： 戦車 消防自動車 戦闘艦船

前 : 前進
後 : 後退 もしくは 減速

右回転 : 右旋回
左回転 : 左旋回

右 : 右旋回
左 : 左旋回

上 : 速度上限アップ(ギアアップ)
下 : 速度上限ダウン(ギアダウン)

マウスカーソル : 射出方向決定

マウスボタン : 発射

・射出装置がついた三次元機動ヴィークル

 例：戦闘機・攻撃機 爆撃機

前 : 機首下げ (下降)
後 : 機首上げ (上昇)

右回転 : 右ローリング もしくは右旋回
左回転 : 左ローリング もしくは左旋回

右 : 右水平旋回
左 : 左水平旋回

上 :  スロットルアップ
下 :  スロットルダウン

マウスボタン : 発射

例: 戦闘ロボット 戦闘ヘリ 輸送ヘリ ガンシップ 宇宙戦艦

前 : 前進
後 : 後退

右回転 : 右ローリング もしくは右旋回
左回転 : 左ローリング もしくは左旋回

右 : 右水平移動
左 : 左水平移動

上 :  上昇
下 :  下降

マウスカーソル : 射出方向決定

マウスボタン : 発射

大体この辺かな

ほとんどの市販ヴィークルはこの操作系になっているか
なっていることを期待されています

一部デファクトが決定する前のものはこれと外れたりしてますが
そういうのは個別でマニュアルを確認しませう


以上

DMCAとかマケプレの報告の話 20170131

DMCA申し立ての具体的なhowtoはなんか頻繁に様式とか変更されるらしいので
SL公式サイトのこの辺参考にするがよろし

http://secondlife.com/corporate/dmca.php


具体的に空いたところ埋めれば完成するテンプレとか紹介できればいいんだけど
そういうのをやってるサイトとかが発見できなかったのよね

個人的に経験者を紹介することは可能だけど基本的には上記URLどおりにすればいい


ページの下の方にあるFAQ見た感じだと　1～7の項目を適当に改行あけてコピペして
その間に内容を記述するのがええらしい

(そういう意味ではテンプレを作る意味自体がなさそうだなこれ)


ポイントとしては

・英語で書くこと(USAに提出する書類なので)

・別に全部手書きにする必要はない　署名以外は
・Object一個に対して1報告　2つあれば両方に対して一通づつ
・FAX代金は一通辺り800円　毎回かかる
・表紙をきちんと作る　題名は　ATTN: DMCA NOTIFICATION

・手書きの署名が必要(日本でいう印鑑みたいなもんだ)

あと適当に追記

なんか書類の作り方　を見た感じだとインワにコピーされた現物置いてあると速いのかね？

(マケプレURLでもいけるかもしれんけど詳細は不明)

んでDMCAは連邦法に則った正式なな申し立てになるので
アカウント情報とかは正確に記述されている必要がある

あと多分正式な記録として名前とか全部記録されて
関係機関(FBIとか)に開示されるんじゃねーかな
一般公開されるかどうかは不明

(虚偽申請や濫用は訴訟とか書かれてるけどまぁ法的手続きのテンプレだこの辺は)

証明に関しては
ユニークなモデリングやメーカーブランドロゴがあればそれの証明が出来ればOKとのこと
いつから売ってるかとかロゴをいつ作ったとかも聞かれることがあるとかなんとか


FAXに関してだけど　画像を使う場合は　現在一般的なe-mailやコピー機と比較して
解像度やたら低くてグラデーションとか無いのでそこだけ注意かなぁ

(国内で国際FAX対応してるコンビニはローソンのみらしい)

メールで画像を送るっていって後から添付するのも手だけど

前にこの手の連邦法が関係する申し立てやったときは
様式とアップローダー指定されたので
そんときに指示された手順を使うのがええんでねーかな




マケプレの報告の仕方

該当のページを開いて

この商品をフラグ　ってのが右側の一番下あたりにあるので

それクリックして

私の知的財産権を侵害する　ってのを選択

様式に関しては

多分自分の商品URLとか乗っけといて
転用されている箇所の説明とか書いときゃええんでねぇの

以上

いくつかのLSLセオリーについて 是正というかそういう話

まぁほんと当時の状況と言葉尻だけ拾われて変な話になってる部分について

・検索でlistは重いから使わない　について

　これバックステージパスにも書かれてるんだけど
　実際ワード保持して逐次検索するようなプログラムの場合
　等長のString型で保持してSubstring系の命令使ったほうが確かに速いんだが
　それはあくまで項目が100とか超えるようなインデックス検索だけの話で

　そういう量じゃなければ入力が十分に遅いので実用速度的に有意差はない
　項目数多すぎてRAMがガチで足りんとかそういうのもmonoならほぼ無い
　何でもかんでもsubstring使ってると検索の後の処理でステップ数食われる

　具体的にはインデックス一個でデータ引き出すだけ　みたいな状況で
　list2なら引数は２だが　getsubstringでは引数が3だ　しかもインデックスの計算がある

・スクリプトは分割したほうが軽い　系の話

　まぁ例えば　SIMFPSが一桁になるようなコンバットsandboxで
　一秒に数ステップしか命令が行われないような状況になれば

　通常の　エフェクト再生　rez　サウンド再生　みたいなアウトプット処理が
　シーケンスだと数秒かかるようになるので
　全部のスクリプトを分割して　それぞれトリガーで１命令実行するだけみたいなのを使うと
　原理上２フレームで全部再生されるので確かにハイレスポンスになったように”見える”わけだ
　(この影響が出るのは実質米国本土のみなんだけどねぇ)

　現代のセオリーでは"無駄に多い"スクリプトは普通に悪だし
　そういうFPS一桁になるような武器類を使うのはBAN対象なので
　そういう時代の無駄に分割されたスクリプトは使わないほうがいい

・オブジェクト移動系ギミックは固定値で動かすべきという話

　これまぁ結局座標演算ちゃんと出来ないやつの戯言だからなぁ
　というところで決めつけちゃっていい

　5フレームくらいまでなら全部手作業で動かして座標取っちまってもいいしな

　ただそのままでは動的なフレーム数加減とかに対応出来なかったり
　多関節や平行リンク等のちょっと複雑な稼働やらせようとしたときに詰む

　リサイズや　中立位置のオフセットにも対応できないしな

サンサーラについて 雑に ほぼ妄想

20160522現在において 雑に ほぼ妄想

・やりたいことのメインはやっぱコンテンツコントロールっぽいなぁ

  要はAAAタイトルのクオリティーで合法なアセットが作れない奴は
  絶対に作る側には回させないぞという雰囲気が感じられる

  (ハイエンドからこぼれた連中を安く雇うってのは中小だとよくある手なので)

  実際のとこスマホにも対応させるならハイからローまでの一貫したアセット必須だしな
  (UOでいうところの2D版と3D版の同居 みたいな話のような感じ)

・所謂"SLが衰退した10の理由"みたいなクソみたいなネット記事を鵜呑みにしてるのだろうか
 実際んとこ株主相手にわかりやすいアッピルするならグラフィックの進化は義務だしな

・ユーザーサイドでコンテンツは結局"組み立ての面白さ"以上のものは求めてない感じがする

・コンテンツコントロール的には"っぽいものが出来た"以上の出来のものは
 結局法的な問題をクリア出来ないので排除したいのだろう


・個人的な考えでは SLが衰退した原因は結局んとこ
  所謂ゴールドラッシュが終わっただけの話だと思ってるのでなんとも
  (出金はともかくとして 最近の他社に比べて入金ハードルが高すぎるんだよな)


・スマホからハイエンドPCまでログイン出来る仮想世界 みたいなのをやろうとしてるとするならば
 ものっそ雑な話として 全部課金アイテムのMMORPGと何が違うんだよみたいな話になるので
 (ユーザーコンテンツ無しにするなら 入金するだけになるから結局一緒ということになる)
 それだったらPK無し設定のGTAとかと本質的な違いが殆ど無い

大体この辺かなぁ

以上

primstar2とblendrによるスカルプの"マルチフェイス"について

手法というかtips程度の話

スカルプでどうしても１メッシュ辺りの解像度が不足している場合や
単純にモデリング時の頂点数を倍に増やしたい等に有効
(仕様上整数倍でしか増やせないけどね)

ただしプリムカウントは普通に増えるし言うほどメリット的なものはあんまりない
(ヴィークル系でハッチ類のチリを合わせるのに有効かもしれんが)

んで

・やり方

primstarで普通にモデリングしたいUVmeshを生成して

編集モードでキューブを追加してそのキューブの面を全部削除

これでバウンディングボックスの最大値が確定するので

そっから通常通りのモデリングを行い

完成した辺りでオブジェクトモードにしてshidt+Dで複製

最初の数回はどうせ失敗するので出力用データとして別にして作業するほうがいい

んで複製したのを更にその場で複製して二個にする

それぞれのオブジェクトでUV座標上での頂点の半分を削除
(自力でフェイスマネジメント出来るなら半分じゃなくてもいい)

あとはそれぞれのオブジェクトでUVを全体に引き伸ばして出力してやればおｋ

出力されたオブジェクトは完全にチリの合ってる２プリムになってるはずです

(ただSLのレンダリングの関係でつなぎ目の法線ズレがかなり目立つだろうけどね)

あとまぁ中間調点が生成されるので表面の平滑度がかなーり下がってるだろうけど
その辺は気合でどうにかしてください

(tatara買ってきてワンビット編集してごまかす手もあるけど)




・雑な解説

まぁ要は座標軸と頂点グリッドを複数オブジェクト間で
完全に合わせるのがこの手法の肝なんだけど

スカルプのデータ上の仕様というかそういうので
(スカルプの仕様は結局４回程度アップデートがかかっている)
ドットトゥドットで完璧な頂点座標出力が出来るアプリがほとんど無いのよね

なのでこの手法が使い物になるのが判明したとしても
大体手法として確定したのが2012年くらいだったので
もうmeshがデルの確定だったじゃん当時

今となってはスカルプでまともなモデリングができる連中いねーんだよね
だったらmeshが作れる奴がいるのかって話なんだけど

meshが作れるんだったら日本のアマチュア連中はMMDとかUnityいっちゃうじゃん

商業連中はmeshがつかりゃよかったのにって2007年からずーっと言い続けて
スカルプが出てきたかなーってくらいまでは残ってたんだけど

SLの民間連中のメインのマネーソースであるところのギャンブルと両替が禁止になって

土地レンタルとかの商業連中がどんどん撤退して
オワコン臭出だした頃にはもういなくなっちゃってた



てな辺りかね

以上

(メモ)PNGのRGBA32対応の話

ちょっと画像フォーマット周りで詰まったのでメモ

現象としてはこの話につながります
http://ueponya.blogspot.jp/2015/08/blender-27-primstar2.html

んでまぁファイルフォーマットの話なんだけど

今んとこ汎用系のメジャーなファイル形式
(ブラウザで特になんも指定なしでまともに表示される形式)

でRGBA32が使える形式が実質PNGしかないの

TGAはRGBA32ネイティブ対応で便利なんだけど
一般的な環境ではそもそもプレビュー出来ないのと
サポートしてるアプリがどんどん消えてるので今回は除外
(まぁそれでもSLでまともに使えるのが実質こいつだけなんだが)

んでまぁPNGについてなんだけど

PNGのアルファチャンネルって最低でも3種類あるのよ

・特定１色マスク(パレットとか使われた時代の名残)

・PNAファイルによる透過(伺かでスムーズな透過使いたかったらこれが必須だった)

・RGBA32 アルファチャンネル(ここ最近はこのフォーマット使われてることが増えてる？)

この３つな

んでまぁ3Dで使いやすいのはRGBA32なんだけど

PNGファイルのロードのライブラリが
PNG-24までしか対応してなかったりするのかねぇ

(多分ライブラリーの世代によるもんだと思う)

てかPNG32制定されたの最近かなぁこりゃ




参考サイト

1分でわかるPNG8,PNG24,PNG32を判別する方法 | iwb.jp

んでなんか カラータイプとアルファチャンネルの種類見りゃいけるらしい

新・OS X ハッキング! (130) 実は種類がある「PNG」の見分けかた | マイナビニュース

てかMacで割りと標準なのかー

とまぁそんな感じ

以上