【VRChat】Unityエディター上でエモートスイッチの確認をしてみる

• まずEmoteSwitchとは

凝ったアバター自作勢の皆様おなじみの『Emoteのアニメーションの上書きを利用してオブジェクトの出し入れなどの切り替えを行う仕組み』です。

導入など詳しくはケーキさんの記事が解りやすいかと思います。

keiki002.com

• EmoteSwitchの動作確認ってどうしてる？

VRChat上で確認するには何分か掛けてアバターをアップロードし、VRCに戻ってアバターをリロードし、Emote再生して確認。と言う流れになろうかと思います。

めんどくさくないですか？

特に切り替えにエフェクトとか演出が絡んでタイミングのトライ・アンド・エラーが要るとなると超めんどくさい。

なのでエディター上で簡易的に切り替えを再現する仕組みを組みました。

• Unityエディター上でエモートスイッチを再現する

とりあえずEmoteSwitchに必要な構造や.animの作成は元怒さんが配布されている【EmoteSwitch V3】等で一通り出来てるものとします。

今回はテストに右手の刀のオン・オフで生成しました。

①擬似的にEmoteを動かすためのAnimatorControllerを作成

名前は何でも良いです。とりあえず『__EmoteSwichTEST』にしました。

②Idle(なにもしてない状態)モーション・生成されたEmoteSwitchのOn・Offモーションの.animをD&D等で登録する。

Idleは自前で用意したものが無ければ、VRCSDKにあるものでも大丈夫です。idleで検索掛けたらあるはず。

③AnimatorのParameterタブで遷移条件を追加する

＋ボタンからTriggerを２つ選び、わかりやすいようにonとoffにリネームします。

④IdleからOnOffへのトランジションを繋げ、遷移条件を設定する

ステートを右クリック＞MakeTransitionで矢印が伸びるので、Idleからon・offへ遷移し、またIdleへ戻るトランジションを繋げます。

・Idle→onのトランジションの設定はこんな感じ

・HasExitTimeを外す。遷移条件を満たしたら即遷移するようになります。

・Conditionsの＋を押して先程定義したTriggerのonを遷移条件に設定。

・on→Idleのトランジションはこんな感じ

・VRC上ではモーションが一通り再生し終わるまで動けないのでHasExitTimeはそのまま。モーションが再生し終わったらIdleに戻る設定。

・Off側もConditionsにoffを設定する以外は同様。

⑤設定したAnimatorControllerをアバターのAnimatorにセット

以上で完了です。

• Unityエディター上で動作確認

あとはUnityのPlayを押してゲーム(?)を動かし、Animatorビューから③で設定したTriggerの丸を押せばステートが遷移しVRCでEmoteを選択したときの挙動を再現できます。

この通りステートの切り替わりで手元の刀のOnOffが切り替わってます。

最終的な確認はちゃんとVRC上で行う必要がありますが、ちゃんと動く構造になってるか、エフェクトのタイミングはどうかの微調整には使えると思うのでUnityとVRCの行ったり来たりをいくらか軽減できるのではないでしょうか。

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

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

docs.unity3d.com

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

ちなみに環境は

・Windows10

・Unity2018.2.18f1

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

• エディター側での設定

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

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

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

解せぬ。

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

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

github.com

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

 npm install unity-cache-server -g

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

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

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

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

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

• 実際にやってみた

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

iOS＞Android　　1時間半
Android>iOS 　　2時間
iOS＞Windows 　30分

もう一度SwitchPlatform
Win＞iOS　　　2分
iOS＞Android　3分
Android＞iOS　2分

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

• 疑問とか

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

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

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

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

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

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

そのうちがんばる。

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

●これまでの認識

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

当時試してた際には

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

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

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

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

と認識していました。

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

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

・Born入れてDynamicBorn使うか

・Cloth使うか

の二択 。

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

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

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

・tretching StiffnessとBending Stiffnessを１前後

・WorldAccelerationScaleを0.05前後

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

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

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

 ●VRChatで得た知見

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

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

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

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

出来るやん…

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

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

 ●改良

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

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

すると…

先日のVR飲み会で伺った話を元に構造とセットアップの見直しを行った。だいぶスカート安定するようになった。#VRChat pic.twitter.com/wYx2GanRhp

— FoR (@For_K_Est) October 30, 2018

 だいぶ改善されました。

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

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

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

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

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

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

Unity WebGL Player | AkaneTyaban01

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

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

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

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

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

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

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

●カメラ操作スクリプト・カメラ注視スクリプトのタイムラインに合わせた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を増やすというゴリ押し実装。

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

感想

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これが

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

１でこんな。

良さげ。

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

左上から10、4、2、1
いいねぇ、調整がやりやすくなる。

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

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

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

 先日のコレの最後、『動きを出力して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を宛てる

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

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

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

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

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

一番ズレが少ない。

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

こちらもほとんど一致。

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

まぁ当たり前か。

結論

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

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

保存

保存

保存

ModoでRig組み ver,1

そろそろRigもModoでやってみっかって適当にいじりながら挑戦。

基本

・IK

・デュアル2DのIK

・コンストレイン

・ペアレント

・スケマティックでチャンネルをつなぐ

 で考えた。

■hip～ChestはIK　それぞれの骨にゴールをおいて腹や胸の反りを管理

■Neck～Headは頭の位置においたHead_Nullの回転値を半分ずつ2つの骨に与える感じ。

ただし普通に回転値継承させただけではHead_Nullのワールド回転は動かないので『深々とお辞儀してるのに首から上は微動だにしない』みたいな状態になるので、Head_Nullの親のLocatorに背骨の回転を継承させることで背骨の動き+Head_Nullの動きで意図した挙動になってる的な。

■UpperArm～LowerArmはデュアル2DのIK　普通のIKだと角度がきつくなるとガクガク荒ぶり始める　よろしくない。

Mayaめいて素直な挙動なのは良いけど、上腕と下腕でで肘の曲がり以外に曲げが入っていてもまっすぐに修正されてしまうので、O脚のキャラとか特異な関節のモンスターとかには使えない場合があるかもしれない。
あと腕を設定してる時に、肘の向きを管理するのに使う上方ベクトルのLocatorが肘の内側に来てしまった。→IKの設定の方向の所で180°回転させたら意図した挙動になった。

■handはIKゴールの方向追随と、腕の角度の影響を受けるのをControllerでリニアに切り替え可。武器を標的に向けるとかはゴール追随、歩きの時の振りとかは腕の影響受けて　みたいに使い分け。

■指や肩は頭同様各ロケーターの回転を渡してるだけ。

■upperLeg~LowerLegも腕同様デュアル2DのIK

Foot＿Null　つま先を起点に足全体を管理

┗Too_Null　足の先の上下回転

┗Heel_Null　踵の上げ下げ

　┗IKgoal　ロックかけてこれ自体は操作しない

今回はこんな構成にしてみた

つま先立ちとかはしやすい反面踵を軸にターンとかはやりにくくなったかも。

for.hatenablog.jp

 前回のRigでは肘や膝の向きを調整する辺りの挙動に不満が出てきたけど、今回のはその辺も改善されていい感じ。

やったぜ。

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

 …ってな感じで考えたけれど、骨の間にいくつかlocator挟んだせいか、試しにUnityに持って行ったときに完全な流用が利かなくなってた。

赤が新Rigの骨　灰が今までの最低限の骨

特定の挙動が入ったときに手先の位置にズレができる

Unity2017で追加されたUpperChestを追加したからってのもあるのかも…？

というわけで検証してみた。

for.hatenablog.jp

保存

保存

保存

保存