FoRのブログ

3DCGとかUnityとかのなんやかんや

なんもわからん状態からのUnityキャッシュサーバー導入

Unityでたくさんの画像Asset等含まれるプロジェクトがある。
プラットフォームを切り替えると圧縮し直しがかかってHold on…の時間がすごいかかる。困る。
そんな事情の対策のための機能CacheServerをローカルでいいので導入したい。

docs.unity3d.com

しかしマニュアルも書かれてることが若干古く、ググってもUnity5系時代の記事やUbuntuが絡んできたりって記事ばかりでなんもわからん。
シンプルに纏められてる情報が見つからなかったので、ミニマムな導入を忘備録。

ちなみに環境は

・Windows10

・Unity2018.2.18f1

なんか間違ったこと・無駄なフローやってたらゴメン

 

  • エディター側での設定

Preference>CacheServerのCacheServerModeをRemoteにする
IPAddress欄は localhost:8126

f:id:for13:20190911232852j:plain

この段階ではCheckConnection押しても繋がりません。

Localにすればいいのかと思ったけどサーバーにつながらないってエラーが出て悩まされた。

f:id:for13:20190911232934p:plain

解せぬ。

 

  • キャッシュサーバー のインストール

ドキュメントには「Unityの ダウンロード アーカイブ ページを開きます」…とあるけど最終的にGitHubに行き着く

github.com


ここのインストールの「npm install ~」ってコマンド使うのにNode.jsが要るらしいのでインストール。
終わったらコマンドプロンプト立ち上げて

 npm install unity-cache-server -g

のコマンドをコピペして実行。このコマンドだけでインストール終わるみたいなんだけど、どこから落としてきてるんだろう…

 

  • キャッシュサーバーの起動

C:\Users\〇〇\AppData\Roaming\npm
にインストールされた【unity-cache-server.cmd】をダブルクリックでサーバー起動。

f:id:for13:20190911233407j:plain

ここの4桁がAddress欄にセットしたポート番号
ここの辺もドキュメントに書かれてない。「オペレーティングシステムに合ったコマンドスクリプトを実行します」ってどうすんねんっていう。

Unityに戻ってPreference>CacheServerのCheckConnectionを押すとConnectionSuccessfulになるはず。
(たまに何故か外れるけど普通に機能してたりする。)

  • 実際にやってみた

Assetフォルダが9GB、テクスチャ3000枚近いProjectでテスト
初回SwitchPlatformでキャッシュ作成

iOSAndroid  1時間半
Android>iOS   2時間
iOSWindows  30分

 

もう一度SwitchPlatform
Win>iOS   2分
iOSAndroid 3分
AndroidiOS 2分

切り替え時間にすごい差出た。やったぜ。

  • 疑問とか

このキャッシュ、どこに保存されてるんだろう?

このように書いてみるとなんてことない作業なのだけど、色々調べ回る羽目になったのはキャッシュの場所を任意のディレクトリにしようとしたため。

CacheServerModeをローカルにしてCustomCacheLocation設定したら良いかな?

サーバー側でコマンドをなんやかんやして保存場所を決めるのかな?

とやっててドツボにはまりました。今の自分の知識ではおっつかない。

追々はNASにCacheServer立てれると良さげかも。

そのうちがんばる。

 

VRChatでVRモードの時にTポーズから動けなくなった

2018年12月16日時点の話(解決済み)

VRChat 2018.4.3でUnity2017にアップデートされたので、アバターを2017環境で再アップロード。

デスクトップモードでアバターの更新と正常に動作するのを確認。

そして後日2018.4.3になって初めてVRモードで起動…すると色々おかしい。

--症状--

・起動時やWorld移動のTipsの画面で腰の辺りに白い球が見える

アバターがロードされるとTポーズ固定になり、視点やコントローラーは動かせるが移動系の操作ができない

・「そういう時にはトリガー同時引きをすると直る」と見つけて試すがなんか違う(後にラールクさんにフルトラのキャリブレーション完了の操作と聞いた)

f:id:for13:20181217195334j:plain

 

この事についてTwitterでボヤいてたら耳寄りな情報が2件。

 

試してみた。

 

・コントローラーを抜いてVRCを起動する

確かに最近新たにSTEAMでゲーム買ったのでゲームパッドを繋ぎっぱなしでした。

ゲームパッドのUSB抜いた

直った!

VRC落として、コントローラー挿して、VRC再起動

再発した!

 

とりあえず原因はこれだったらしい。
公式のガイド

とあるので、2018.4.3のエンバグだったのかな?

 

アバターを変える→ロードが終わるまでsteamのメニュー開く
こっちでも解決した!
解決したけど…コレはコレで正しい挙動なのだろうか…?

ふいにまた再発したときには予備知識として良さそう。

 イオルさん、kurokuro9696さんありがとうございました!

 

VRChatでUnityのClothの認識を改めた話

●これまでの認識

Cloth最後に使ったのはいつだったか…2015年頃?

当時試してた際には

・ClothのMaxDistanceを0にしてもボーンウェイト効かなくなる

・そんな訳でCloth使うなら骨の子にメッシュを配置してColliderやMaxDistanceでClothの効きを調整する必要がある

・メリットとして、例えばスカートのような場所に使うとボーン&ダイナミックボーンで作った際の「骨の列の間から脚が貫通する」といった欠点が起きない

・デメリットとして、下手に急に動かすとメッシュが荒ぶって収集つかなくなることが起こりうる

と認識していました。

なのでUnity用モデルを作る際、スカートの物理をボーンかClothかどっちにするか。ワンピースな服とかだとボーンと併用できないから…という事でボーンでやっていました。Smooth Jointならボーンでも貫通しにくい作りに出来ることだし。

 

しかしVRChatだとセキュリティの関係か無制限にスクリプトAssetを使うことは出来ず、布系揺れものは

・Born入れてDynamicBorn使うか

・Cloth使うか

の二択 。

スリットのないロングスカートで、脚の貫通は極力避けたいとなると実質Cloth一択です。

そんな訳でロングスカートな衣装のハロウィンアバターを作る際に数年ぶりにClothを採用したのでした。

 

実際やってみると、UnityEditor上だと

・tretching StiffnessとBending Stiffnessを1前後

・WorldAccelerationScaleを0.05前後

にすると生地が堅い感じになる代わりに比較的安定した挙動でしたが。

VRChat上ではそれでも荒ぶってパンモロになる始末。

f:id:for13:20181030165113g:plain

もはや諦めの境地でロングスカートなアバターは鬼門だなぁと思いながらも「Cloth難しいよねー」と話していました。

 

 ●VRChatで得た知見

ところが先日VRChatのバーチャル宴会内で『和服の袖にClothを使いつつボーンの影響も受けているアバター』を目にし、お話を伺ったところ。

・ClothのMaxDistanceを0にしてもボーンウェイト効かなくなる

 の認識が間違ってたことが判明。

試しに琴葉姉妹ボディの袖でざっくり試してみた。

出来るやん…

何だ?だいぶ前だからUnity5の何処かで追加されたのに気づかなかったのか?それとも当時の検証が間違ってたのか?

なんにしても骨とClothの連携ができるのはとてもありがたい。

 ●改良

そうと判れば話は簡単。
こんな感じに脚骨のウェイトを付けて。

f:id:for13:20181102011858j:plain

ClothのMaxDistanceをこんな感じにつけて。

f:id:for13:20181102011926j:plain

すると…

 だいぶ改善されました。

 昔ながらの脚にウェイトベタ打ちをベースにMaxDistance狭めのClothで味付けする感じのアプローチ。

バーチャル飲み会の良い収穫でした。

 

ちなみに普段脚が貫通しないスカートを作る際に使ってるのはこちら

 

 DynamicBornのような縦に繋げた骨の計算だけでなく、横に並べた骨の列にも相互に影響を与えられるAssetです。

 

DドライブSSDが壊れた話

 一応まだ 偶に認識するけど。

 

for.hatenablog.jp前回の最後に怪しい症状を見せてから重要なデーターは別ドライブに退避し、Dropboxのフォルダと、ソフトをインストールする専門のドライブなってたDドライブ。

特に致命的なダメージはなかったけど前回のCの時の事もあって早急に対処が打てた。

 

症状のあらまし

 先日ModoとUnityで作業していたら2つが同時に(応答なし)になった。

タスクマネージャーからのタスクキルもできないどころかタスクマネージャーも(応答なし)になる。

再起動もフリーズして出来ないので電源長押しで無理やりPCを落として再起動。

起動時に『Scanning and Repairing drive (D:)』という感じに修復が走った後OS起動。

しかしやはり挙動がおかしい、普段スタートアップで立ち上がってるアプリがいくつが動いてこない。Explorer見てみてもドライブが一個も認識されていないし、Dドライブ絡みのショートカットを押すと軒並み動かない。
再度PC落としてシステムの回復を試すも効果なし。

Dドライブを外して再起動、SSDをUSBから繋いでみるとExplorerは正常に表示されるけどDドライブにはアクセスできない。

タスクマネージャーで見てみると常に使用率が100%になってる。

f:id:for13:20180210172022p:plain

そういえば以前そんな記事見たぞ?と「windows10  SSD 100%」などでググり、Windows Update

knot-found.hatenadiary.jpの記事を試す。…正常に戻った!

 

と思ったら翌日また作業中に使用率100%になってダメになった。

前回のCの時のように「SATAケーブルを抜いて挿してとスーファミみたいなことしたら認識した」「突然に固まる」「しかし再起動すると何事もなく動く」と重なることが多いので、もうじき壊れると判断してパーツ交換しました。

という感じ。

SSDの寿命

今回のDに使っていたSSDをいつから使い始めたか記憶が定かじゃないけど、前回死んだSSDと同時期じゃないのは確か。早くとも半年か1年後辺りに足したもの。

そう考えたら今回も壊れるまで5年近くと言うことになるか?

しかし

f:id:for13:20180210173813j:plain

左が前回換装したCのSSD。記事から察するに使用開始から約1年。

右が今回イカれたDに使ってたSSD。電源投入回数の割に使用時間が少ないのが気になるところだけど…。

電源投入回数から計算すると去年の時点で914回、年600回動かすとして2年ちょいで死んだ?それは早すぎない?

bbs.kakaku.comnandの値はこの件があるからあてにならないかも。
使用初めた日時メモするようにしよ。


結論

怪しい動きをしたらクローンを取ろうと思いました。
あと念のためDropboxのフォルダも引っ越そう。

Unityのタイムラインでボイロ1分動画を作ってみて。

年始帰省中にUnityのタイムライン機能を探り探り使って1分動画作ってみた。

 

Unity WebGL Player | AkaneTyaban01

 (音が出ます。操作はニコニ立体と同じ、リプレイは実装してないのでF5で。Lip Syncが動かないのは後で修正する予定)

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

基本的な所は毎度おなじみテラシュールウェアを、特に

tsubakit1.hateblo.jpのタイムラインとスクリプトの連携周りを参考に。

f:id:for13:20180110023925j:plain

こんな感じになりました。

 

今回やってみたかったこと

●会話に合わせたモーション・表情・リップシンク設定

●カメラ操作スクリプト・カメラ注視スクリプトのタイムラインに合わせたON-OFF

 

弄ってみてわかったこと

●AudioTruckはAudioSourceセットしなくても動く。

●AudioTruckはAudioSourceのAudioClipをタイムラインに合わせて置き換えて鳴らすわけじゃないらしい

●AnimationTruckにはAnimatorは要るっぽいがControllerはNoneでも動く。

●PlayableAssetとかPlayableBehaviourのスクリプトどうしたら良いのかわからん

●別にPlayableAssetやPlayableBehaviourを使わなくても、ITimeControlでスクリプトとかの動作をコントロールすることは出来る

遭遇した問題

●モーションと表情のために複数のAnimationTruckに同じAnimatorを与えると、表情が変わる辺りでBlendShapeの変化を記録したAnimationClipに引っ張られたのか接地がおかしなことになった。

→AvatarMaskも効果なかったので、体の動きと顔で別々にAnimatorを持たせた。Akane_BとHead(2)の2つがあるのはそのため。

 

上記『AudioClipをタイムラインに合わせて置き換えて鳴らすわけじゃない』故に、Lip SyncのためにAudioClipをタイムラインに合わせて入れ替える仕組みが必要になった

→AudioClipのリストを作り、OnControlTimeStart()でCountに応じたClipの入れ替えとLip Syncの開始。OnControlTimeStop()でCountを増やすというゴリ押し実装。

f:id:for13:20180110030707j:plain

● timelineIKLook.csを作り、カメラ注視の全体のウェイトをOnControlTimeStart()とOnControlTimeStop()で0と1で切り替えたらパッと変化してしまう。
→ 初めtimelineIKLook.cs内でSmoothDampを使おうとしたが、クリップの開始時、終了時に一回だけ処理されるのを忘れてたので意図した挙動にならなかった。結局素直にIKのスクリプト側を改良。

 

感想

慣れたら色々使えそうだなぁと思いました(小並感)

前の歌うボイスロイドの時はAEでの表情の切り替えがとてつもなくめんどくさかったけど

for.hatenablog.jpコレだと表情のモーションクリップ作ればブレンドも簡単だし、実況動画の動く立ち絵

素材を作るとかも出来そう。

…リソースがあればだけどww

あとTwitterのボイロ30秒動画とかやってる方々すげぇなぁと思った、話作り的な意味で。台本考えるの大変。

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

 さて、茜ちゃんモデルの修正と続きに戻るか。

f:id:for13:20180110034251p:plain

 

ボーンインフルエンスの数を制限する@modo

UnityやUEにfbxを持っていった際、ボーンインフルエンス数(1頂点がWeightMapを何個持つか)が自動で制限されます。

Unityで最大4(UEは8らしい)だいたいいい感じにまとまるから良いのだけど…

やっぱり厳密に調整したい所があったり、IllusionのHoneySelectの自作Modとか弄ってるとインフルエンスが4を超えるとエラーで読み込めなかったりする。
そんな訳で常々『1頂点あたりのWeight数を任意に制限できないかなー』と思っていましたが、ようやく項目を発見。

1頂点のWeightの合計を100%に纏める時お馴染みの、デフォーマーリストの"NormalizeingFolder(正規化フォルダ)"のプロパティにありました。気づかなかった…

試しに8個Weightを持たせてみて、ソース制限にチェック入れて、インフルエンス数を指定して、この時点で変形に反映されるけど更に"ウェイトのベイク"を押すと。

f:id:for13:20171221120308j:plain

これが

 

f:id:for13:20171221120317j:plain

2でベイクしてこんな感じ。

 

f:id:for13:20171221120324j:plain

1でこんな。

良さげ。

 

作成中の琴葉茜ボディでも試してみると

f:id:for13:20171221120337j:plain
左上から10、4、2、1
いいねぇ、調整がやりやすくなる。

 

ってか何で今まで気づかなかったんだ…
検索しても出てこないから無いのかと思いかけてたww

Unity2017でMecanimに追加されたUpperChestについて

 Unity2017辺りで追加された(と思ったら5.6.1のときにはもうあったらしい。知らんかった…)UpperChestの項目。

f:id:for13:20170816104153j:plain

 先日のコレの最後、『動きを出力してunityに持っていって既存モデルにあてたら若干挙動がずれる』って話について。

for.hatenablog.jp

薄々「まぁUpperChestの分の動きがズレてる原因だろうなぁ」と思いつつ検証してみた。

用意したもの

  • モーションA:前回出力した謎の動き。UpperChestあり
  • モーションB:Aを複製し、インポート設定でMappingからUpperChestを外したもの
  • Assetから持ってきたモーション:UpperChest何それな時代のモーション。当然UpperChest無し
  • BoxPeople:以前出力したテスト用のハコ人間。UpperChest無し
  • BoxPeople+:新RIGに使ったBoxPeople。UpperChestあり
  • Tenryu:いつもの。UpperChest無し
  • Tenryu+:UpperChest足してウェイト調整

検証内容

  1. UpperChest対応骨にモーションA、未対応骨にモーションAを宛てる
  2. UpperChest対応骨にモーションA、未対応骨にモーションBを宛てる
  3. UpperChest対応骨にモーションB、未対応骨にモーションBを宛てる
  4. UpperChest対応骨、未対応骨共ににAssetから持ってきたモーションを宛てる

 の4パターン
ちなみに赤いほうがUpperChestあり。

赤いのと白いののズレが少なければいい感じ。

●UpperChest対応骨にモーションA、未対応骨にモーションAを宛てる

f:id:for13:20170816092655g:plain

前回おや?となったのがこのケース。

腰から下は比較的ズレ少ないけど、胸から先がうまく揃ってない。Mecanimも万能ではないんだなぁ。

●UpperChest対応骨にモーションA、未対応骨にモーションBを宛てる

f:id:for13:20170816092728g:plain

UpperChestが無い分、頭や肩辺りがズレがデカイけど。手とかはちゃんと補正されてる。

●UpperChest対応骨にモーションB、未対応骨にモーションBを宛てる

f:id:for13:20170816093042g:plain

一番ズレが少ない。

●UpperChest対応骨にAssetから持ってきたモーションを宛てる

f:id:for13:20170816093128g:plain

こちらもほとんど一致。

 

 3と4のケースからは、モデル側的にはUpperChestが有っても使わない分には動きに影響しないというのが判る。

まぁ当たり前か。

 

結論

  • 『新しく作ったモーションやUpperChest有りのモーションAssetを買ったのを、既存のモデルとかに使いたい』 って場合は、モーション側のインポート設定を弄ってUpperChestをNoneにすれば問題ないっぽい。
  • どうしても動きでUpperChestを使いたいなら、当然モデルにもUpperChest骨が足されてないといけない。
  • 新しいモデルに古いモーションを宛てる分には問題ない。

 

あぶねー Rigの構造見直しかと思った…

保存

保存

保存