FaceEmo 2.x
変更のコストを下げる
テスト網羅性の向上
保存方式の見直し
シーンオブジェクトではなくアセットで保存
シーンオブジェクトへの参照をどのように保持するか？
階層の変更やリネームに追従したい
アーキテクチャの見直し
MV(R)Pパターンに変更
Presenterのテストを書く？
大規模なマイグレーションの方法
AaCのv0→v1が参考になるか？
マイグレーション開始コミット
v0をv1にリネーム
アセンブリ構成の変更
これも基本的にはv0→v1のリネームぐらい
コンパイル通らないところを修正？
破壊ワークフローと非破壊ワークフローを整理しているように見える
AaCはライブラリだから破壊的変更に気を使っている
マイグレーションのプルリクどうする？
AaCは1つのプルリクにまとめる予定？
1.xのリリースは出ているが、このPRはまだマージされてない
変更ログなし
0.xのリリースはそもそもない
CGEはリリースなし
とりあえずwip-v2ブランチを作る？
ほぼすべて書き直すぐらいの勢いでいきたい
パッケージ内のすべてをLegacyフォルダに移動
LICENSE.mdとpackage.jsonを除く
1.xから2.xへの移行に必要なクラスはlegacyに残す
表情メニュー保存用のクラス
NDMFコンポーネントは残さなくてもいいか
それ以外は（可能であれば）同等のクラスを作ったときにlegacyのものを消す
すべてのasmdefを削除し、legacyアセンブリに統合
別のフォルダにクローンしてUnity2022で開く
package.jsonを修正
2.0.0-beta.1
unity2022
AaCの最新版をpull
R3とVContainerを導入
参照の確認用テストを書く
UseExternalPackageTestsとか？
Emoボタンの部分をコメントアウト
パッケージ構成の見直し
Unity依存を切り分けるか？
Unityバージョンに非依存にできる
C#バージョン依存の記法を使っている場合、完全に非依存にはならない
エディタ拡張でpure C#の層を作る意義はほぼ無い
そもそもUnityの操作を簡易化するソフトウェアなので
エディタ拡張はデータの加工や読み書きが主な仕事なので、IO部分を外に追い出しても、そちらにばかりコードが増えていく
VRCSDK依存のデータ読み書きが多い場合、それに依存しない層の役割がかなり小さくなる
VRCSDK依存の切り分け
VRC以外で使うか？と考えると、せいぜい表情エディタぐらいしか使わない
表情エディタの切り出しは後で検討する
切り出しの優先度がそこまで大きくないので、最初から別パッケージで開発する手間やリスクの方が大きい
VRCアバターからの移行というケースは考えられるが、VRCが絡まないケースで使われることは無いと考えていい
テスト同梱の要否
MAやNDMFはフォルダ名の末尾にチルダを付けてUnity上で無視している
AAOも同様
以前はCL4EEのテストが見えていたが、NDMFのLocalizerに切り替えて以降はテストランナーに何も出てこなくなった
UPMパッケージはテストを同梱する？
サンプルは Samples~ 以下に配置し、どのようなサンプルがあるかを package.json に記述します。こうすると利用者側は必要なサンプルのみ Package Manager 上でポチポチしてインポートできるようになります。
この例だとTestsはチルダを付けずに同梱している
samplesと同等の記法でテストを個別にインポートすることはできない？
UPMや、その他一般のパッケージにテストを同梱すべきか？という話は見つからなかった
まあ、非開発者向けのツールにテストが同梱されていてもあまり意味がないので、無視するのが丸いとは思う
Detailに詰め込みすぎなので構成を見直す
従来のエディタ拡張がEditorフォルダ以下に作られていたことを考えると、Runtimeアセンブリは無くてもいい気がする
CGEはコンポーネントをRuntimeアセンブリにしている
MAはcore.asmdefとcore.editor.asmdefがある
現状のRuntimeアセンブリをEditorアセンブリに変更してみたが、特に問題なさそう
Editorアセンブリのコンポーネントがアップロード時に同梱されなければ問題ない？
Unityを再起動するとコンポーネントのスクリプトがMissingになり、アバターのビルドが失敗する
この状態で再度FaceEmoを適用しようとすると下記のエラーが表示される
Can't add script behaviour BlinkDisabler because it is an editor script. To attach a script it needs to be outside the 'Editor' folder.
無機能でもいいのでコンポーネントはRuntimeに入れましょう
RuntimeにあるのはUnityの仕様で、Componentとして存在するためにはEditorビルドだけではなくランタイムビルドにも含めないといけないという仕様によるものです。VRCSDKの仕様でコンパイル済C#はvrcaには含まれないんですよね。
MAのすべてのコンポーネントはビルド終了前に内部的には削除されてます
AvatarOptimizerに関してはRuntime以下はほぼ無機能のコンポーネントだけで、Editor以下に全機能を詰めてたはず。
MAやNDMFはあまりアセンブリを分けていない
MA
nadena.dev.modular-avatar.core
nadena.dev.modular-avatar.core.editor
nadena.dev.modular-avatar.harmony-patches
nadena.dev.modular-avatar.param-introspection
NDMF
nadena.dev.ndmf
nadena.dev.ndmf.runtime
nadena.dev.ndmf.vrchat
AAOはわりと細かく分けてる
com.anatawa12.avatar-optimizer.api.editor
com.anatawa12.avatar-optimizer.editor
com.anatawa12.avatar-optimizer.internal.animator-optimizer
com.anatawa12.avatar-optimizer.internal.localization.editor
com.anatawa12.avatar-optimizer.internal.localization.runtime
com.anatawa12.avatar-optimizer.internal.meshinfo2
com.anatawa12.avatar-optimizer.internal.prefab-safe-set
com.anatawa12.avatar-optimizer.internal.prefab-safe-set.editor
com.anatawa12.avatar-optimizer.internal.trace-and-optimize-base
com.anatawa12.avatar-optimizer.internal.unsafe
com.anatawa12.avatar-optimizer.internal.utils
com.anatawa12.avatar-optimizer.localization
com.anatawa12.avatar-optimizer.runtime
LLCはMA依存で、アセンブリはruntimeとeditorの2つ
MAはMenuInstallerのみ使用
VRCSDK非依存にする意義がどれだけあるか？
ガッツリVRC専用のAnimatorControllerだし…
表情エディタを転用できるぐらい？
それなら表情エディタだけ別パッケージ or 別アセンブリにするだけでいい
構成案
Domain
AaC依存の処理もここに書く
AaC VRCパッケージは使わない？
Usecase
Infra
VRChat
参考
NDMF
ModularAvatar
UI
Localization
Ext
CAC
AaC
R3
VContainer
Usecaseを作るべきか？
Presenterを挟む場合は過剰？
Presenterは可能な限り薄いレイヤーにすべき
Coreとその他の境界は？
表情設定の機能を含むかどうかで分ける
LocalizationやReportingは表情設定の機能を含まない
ExpressionEditorをパッケージ切り出し可能にする？
その場合、UIとの分離はどうする？
FaceEmoの依存にExpressionEditorを入れる？
簡易起動方法は？
起動専用のコンポーネントを作る
メリット
メニューの深い階層から起動しなくていい
設定項目が複数ある場合、毎回入力しなくていい
View Positionの代替パラメータ
追加メッシュや追加オブジェクト
アバターにアタッチするか、適当なオブジェクトにアタッチするか
FaceEmoと併用する場合、そのコンポーネントは不要
パッケージ名は？
FaceEmoEditor？
サムネイル生成との連携は？
公開APIを作る？
メインウインドウとの連携は？
バージョン指定は単一にする
ほぼ同梱のような扱い
分離する場合、キーを抽象化することができない？
EditorCurveBindingそのままでいいのでは？
propertyNameで判別
blendshape.
m_IsActive
m_LocalPosition.
localEulerAnglesRaw.
m_LocalScale.
ここの仕様を1.xから変える場合は変換処理を入れる
不明なキーがある場合、ウインドウを出して警告？
2.xではデフォルト表情を考慮する必要がある
別案
Core
ExpressionEditing
Importing
Generating
Drawing
Data
要検討
UI
Presenters
Views
Components
Localization
ErrorReporting
Tests
Ext
CAC
AaC
R3
UniTask
VContainer
エントリポイントをどうするか？
Mainアセンブリを作る？
UIアセンブリがすべてを参照すべきかどうか
インターフェースだけ知っていればいい？
Usecase経由？
さらに別案
Editor
AppMain
Domain
Localization
Usecase
Infra
VRChat
ModularAvatar
NDMF
UI
Presenters
Views
Resources
Ext
CAC
AaC
UniRx
UniTask
VContainer
Runtime
Components
Tests
Editor
アセンブリ
Editor
jp.suzuryg.face-emo.app-main
jp.suzuryg.face-emo.domain
jp.suzuryg.face-emo.usecase
jp.suzuryg.face-emo.ui
jp.suzuryg.face-emo.infra.vrchat
jp.suzuryg.face-emo.infra.modular-avatar
jp.suzuryg.face-emo.infra.ndmf
jp.suzuryg.face-emo.ext.aac
VRC依存も含めて1つのアセンブリにまとめる
Infra.VRChatでのみ参照する
jp.suzuryg.face-emo.ext.unirx
jp.suzuryg.face-emo.ext.unitask
jp.suzuryg.face-emo.ext.vcontainer
Runtime
jp.suzuryg.face-emo.components
Ext内のライブラリはEditorとRuntimeを1つにまとめて、asmdefのプラットフォームをEditorだけにする
UIの中で、VRCのコンポーネントを指定するObjectFieldはどうする？
AppMainではVRCのdllを参照する必要がある？
直接呼び出してなければ大丈夫だったりしない？
R3.Unityを参照しているアセンブリでR3.dllの参照が必要か？という話
Override Referencesがfalseなら追加しなくていいが、trueにするなら追加が必要では？
DomainにUnity依存のコードを入れるかどうかは別として、具象の処理をDomainに入れるのは適切ではないのでは？
さらに別案
Editor
Core
Domain
ExpressionEditing
ThumbnailDrawing
Usecase
UI
Localization
Presenters
Views
NDMF
プレビューシステムなど
NDMFのメソッドをいくつか呼ぶだけなら、わざわざアセンブリ作らなくてもいいかも？
USE_NDMF_PREVIEW_SYSTEMで分岐
アセンブリ分ける方が素直か…
VRChat
Domain
Generating
Importing
Usecase
UI
Presenters
Views
Ext
パス文字制限の都合上、あまり階層を深くしたくない
これで60文字
Packages\jp.suzuryg.face-emo\Editor\Core\Domain\Localization
Runtime
Components
Runtimeアセンブリの数を増やすとビルド不具合が誘発されるため、1つにまとめる
フォルダは分ける
外部のライブラリに依存するコンポーネントは、プリプロセッサを使用してコンパイルエラーを回避する
&&が使える
VRCHAT_BASE_PRESENT
VRCHAT_AVATARS_PRESENT
MODULAR_AVATAR_PRESENT
NDMF_PRESENT
Define Constraintsでアセンブリ自体を無視するのが手軽
起動チェックのみアセンブリを独立させる？
jp.suzuryg.face-emo.vrchat.booting
起動コンポーネントのEditorにも表示したい
コンポーネントはmissingにしない方がいいかも
プリプロセッサでIEditorOnlyだけ無視する？
[ 1.3,3.4.1] は 1.3.0 <= x <= 3.4.1 を評価します。
かっこ () は、終点を除いた範囲であることを示します。
(1.3.0,3.4) は 1.3.0 < x < 3.4.0 を評価します。
1 つの式の中で、両方の範囲タイプを混在させることができます。
[1.1,3.4) は 1.1.0 <= x < 3.4.0 を評価します。
(0.2.4,5.6.2-preview.2] は 0.2.4 < x <= 5.6.2.-preview.2 を評価します。
正確なバージョンを指定するには、角かっこに単一のバージョン指定子を示します。
[ 2.4.5] は x = 2.4.5 を評価します。
ショートカットとして、範囲かっこを付けずに単一のバージョンを入力すると、その式はそのバージョン以降を含むことを示します。
2.1.0-preview.7 は x >= 2.1.0-preview.7 を評価します。
Tests
Editor
アセンブリ
jp.suzuryg.face-emo.core
jp.suzuryg.face-emo.ndmf
jp.suzuryg.face-emo.vrchat
エントリポイント
jp.suzuryg.face-emo.ext.aac
jp.suzuryg.face-emo.ext.unirx
jp.suzuryg.face-emo.ext.unitask
jp.suzuryg.face-emo.ext.vcontainer
jp.suzuryg.face-emo.components
同梱していないライブラリに依存する場合はアセンブリを分ける
参照先のアセンブリが参照しているasmdefを改めて参照する必要はないので、extはアセンブリを分けてもいい
コンパイル済みdllの場合は別
インスタンスがPlayモードをまたげない都合上、DIコンテナの使用がしづらい
設定アセットをEditorWindowに渡して、初期化のときに読み込んでもらうほうがシンプルかも
パス文字削減案
Core
Localization
ExpressionEditing
Drawing
Usecase
UI
Presenters
Views
uxmlとussもまとめて格納
Resources
アイコンなど
NDMF
VRChat
Components
Ext
VRCSDK, MA, NDMFのパス文字はどの程度になっているか？
FaceEmoだけ短くしても意味がないので
MAについて以前調査したときの最長
Packages\nadena.dev.modular-avatar\Editor\ErrorReporting\Resources\ModularAvatarErrorReport.uss.meta
100文字
2024/06/17時点での最長
Packages\nadena.dev.modular-avatar\Editor\ParamsUsage\nadena.dev.modular-avatar.param-introspection.asmdef.meta
111文字
Packages\nadena.dev.ndmf\Editor\VRChat\ParameterIntrospection\VRChatProviders\VRChatBuiltinProviderPlugin.cs.meta
113文字
Packages\com.vrchat.base\Runtime\VRCSDK\Dependencies\VRChat\Resources\Validation\Performance\StatsLevels\Windows\AvatarPerformanceStatLevels_Windows.asset.meta
159文字
Packages\com.vrchat.avatars\Editor\VRCSDK\SDK3A\Elements\AvatarFallbackSelectionErrorNotification\Resources\AvatarFallbackSelectionErrorNotificationStyles.uss.meta
163文字
プロジェクトまでのパスが100文字でも特に問題なかった
csファイルだけでカウントしてみる
Packages\com.vrchat.base\Runtime\VRCSDK\Plugins\UniTask\Runtime\External\TextMeshPro\TextMeshProAsyncExtensions.InputField.cs
125文字
Packages\com.vrchat.avatars\Editor\VRCSDK\SDK3A\Elements\AvatarFallbackSelectionErrorNotification\AvatarFallbackSelectionErrorNotification.cs
141文字
プロジェクトまでのパスが120文字でも特に問題なかった
プロジェクトまでのパスがあまりにも長い場合、SourceAssetDBのロックを取得できずにUnityが起動できなくなる
プロジェクトまでのパスが167文字のとき、FaceEmo1.5.5を適用したアバターのビルドが通ることを確認
コンソールにエラーは出るが、表示を消せるタイプのエラー
テストビルドでエラーが発生しない
GestureManagerでのプレビューは失敗
あんまり文字数気にしなくてもいいのか…？
とりあえずNDMFの文字数（113文字）以下に収まるようにする
できれば100文字以下にしておくと安全
Packages\jp.suzuryg.face-emo\Editor\Ext\ObservableCollections\Suzuryg.FaceEmo.Ext.ObservableCollections.R3.dll.meta
115文字
Packages\jp.suzuryg.face-emo\Editor\Ext\dll\Suzuryg.FaceEmo.Ext.ObservableCollections.R3.dll.meta
97文字
ライブラリの見直し
更新・移行
UniRx → R3
標準のインストール方法がNugetだったり、依存dllがあったりするので同梱は難しいかも
UniRxの導入目的はUnity依存の機能ではなくRxだったはず
AaC 1.x
同梱ではなく依存にする？
MAのように協調動作が必要なわけではないので、同梱の方がいい
Zenject → VContainer
シンプルなのがいい
追加
UniTask
VRCSDKに入ってる？
VRCSDK Base/Runtime/VRCSDK/Plugins/UniTask
VRCSDK Base/Editor/VRCSDK/Plugins/UniTask
UniRxはなかった
それに依存するのも怖いので自前で入れてもいいが
unitypackageの中身はcsとasmdefだけ
この問題の原因になっているVRCSDK側の問題をCannyに上げました。
この問題のせいでVRCSDKとUniTaskが同時にインポートできません。
今のところ、VRCCore-Editorは参照していない
unitypackageにPlugins/UniTaskが同梱されている
VRCSDKがUniTaskを含まなくなったら自前で入れるのが丸いか…？
UniTaskのasmdefのOverride referenceがfalseなのがちょっと怖い
むしろVRCSDKが自前で入れてるなら、こっちも自前で入れていいだろの精神
GitHub Actionsでリリース可能な形式で同梱
これまでシンボリックリンクをリポジトリに入れていなかったが、入れてしまっていいのでは？
追跡可能かどうかテストしてみる
yオプションでいけそう
バックアップ用のリポジトリをprivateにしておく意味は特にないので、publicに変更
アクションのテスト用にする
ドラフトでテストするならメインのリポジトリでもいい
MAやAAOを参考にする
VContainerの導入について
unitypackage版を見たところcsとasmdefだけだったので、同様の構成でsubmoduleから取り込めるかも
ここから取り込む？
Source Generatorのdllを入れる必要がある？
リフレクションの部分がそのままでいいなら不要
どのくらい速度が違う？
READMEを見ると、リフレクションを使っていてもZenjectよりだいぶ速い
標準のVRCアバター用プロジェクトでは、UniRxもZenjectもインストールされない
Package Managerのリストの中に存在しないことを確認
Packagesフォルダの中に存在しないことを確認
VRC SDKのDependenciesの中に存在しないことを確認
FX構成の見直し
ジェスチャーと表情固定のステートを分割
ステートの増加とトレードオフ？
ステートの増加 = 負荷の増加 ではない
FX全体をAaCで書き直す
生成が十分に速ければ、テンプレートFXを同梱する必要はないかも
コード化しながら構成の変更について検討するため、優先的に作業する
CACのアセットのうち、必要なものだけ同梱する
Unity2022の機能で参照のチェックができたはず
FX生成の高速化検討
分岐が255通りで収まらない場合
同期の都合上、何かしらの「モード」単位で分割して、「モード」内では1変数で分岐するようにしたい
ダンスギミック中に最初の3レイヤーが無視されることを考慮する？
アバターマスクを考慮
CgeAacの WithAvatarMaskを確認
処理の順序を考慮してレイヤー順を決める
DefaultFaceが一番上じゃなくてもいい
再生レイヤー以外のウェイトが1になっていてもさほど問題ではない
一番上のレイヤーはダンス中にウェイトが0になる可能性があるが、表情レイヤーが無効になっていない状態でDefaultFaceが無効になるのはあまり好ましくない
表情エディタの軽量化
AnimationModeでプレビューしない
MA, NDMFの新APIをチェック
フェイストラッキングとの共存
ExMenu階層の編集
デフォルト表情の仕様変更
デフォルト表情を表情パターン内の表情に合成する
「デフォルト表情」という名称は変えたほうがいいかも
1.xとの互換性
旧表情メニューの自動変換
旧コンポーネントの維持
表情パーツ合成
アバターギミックを維持する方法について検討
ExMenuの項目をユーザーが選択して、それがONのときにバイパスする？
ContactやPBはバイパスじゃなくて自前でレイヤー追加してもいいか？
CGEのDynamicsみたいな感じ
Contactの位置はViewPositionみたいな感じでギズモ表示
CGEからの変換の互換性
FaceEmoのアセンブリを参照している場合はコンパイルエラーを回避できないため、そこは修正してプルリクを出す
とりあえず1.xへの変換を経由するのが無難
2.xへの変換を作れるように、一部のクラスはpublicにしておく？
元々の表情を無効化できない問題
顔メッシュが複数に分かれているケース
表情パーティクルが含まれるケース
表情インポート時に、読み込んだクリップのキーをすべてリセットアニメーションに入れてしまう？
Playモードをまたぐ必要があるかどうか
表情設定をアセットに保存しているならPlayモードをまたいでも問題ないのでは？
1.xだとシーンオブジェクトのリンクが切れていたはず
リポジトリの階層見直し
パッケージの中身をトップに置く
.gitignoreでUnitTestsのみ無視するように変更している
UnitTest~がUnityで無視されるため、シンボリックリンクを作成する
AssetsにもPackagesにも入っていないスクリプトをどうやってテストしている？
たぶんPackagesの中がリポジトリのルートになっている
AnimatorControllerのテスト
AaC
アニメーターを動かして挙動をチェックする方式
MA
生成されたステートや遷移をチェックしていく方式
日本語パスを含む場合の不具合
名前空間をパッケージ名にする？
MAやNDMFはパッケージ名
AAOはAnatawa12.AvatarOptimizer
ファイルの階層とnamespaceの階層が綺麗に一致している人等そうおらん。
VPM Dependencyの見直し
ローカリゼーション等をNDMFに依存する場合は VPM Dependencyに入れておきたい
それならVRCSDKやMAも入れてしまうか？
dependencyに入れる場合のネックは？
外部リポジトリが追加されていないとコケる
自分のリポジトリにMAやNDMFを追加することで対応可能
インストール時に他のパッケージが更新される
これを嫌がるひとはどれだけいる？
どのようなケースで更新される？
VCCとALCOMでは挙動が違う？
VCCとALCOMの両方で、VRCSDK 3.5.0環境にMA1.9.3をインストール
VRCSDKは更新されなかった
MA1.9.3のdependencyは下記
"com.vrchat.avatars": ">=3.4.0",
"nadena.dev.ndmf": ">=1.4.1 <2.0.0-a"
NDMFはdependencyなし
大丈夫そうかな…？
MAやNDMFのバージョンは <2.0.0-aとしておく？
2.xが出たときに即時対応できないケースを想定
上限を指定しない場合
MAやNDMFのインストール時に競合が発生しない
FaceEmo側でコンパイルエラーが出る可能性がある
上限を指定する場合
MAやNDMFのインストール時に競合が発生する
競合を無視してインストールすることはできる
たぶん1.xではAPIの破壊的変更がされない
使用中のAPIが存在するMAやNDMFの最低バージョンを確認し、VRCSDKのバージョンはそれに合わせる
MAのプレビューシステムを確認
Unity2022はC#9.0なのでnull許容参照型が使える
ただし、Unityオブジェクトのnullチェックは特殊
Resharperでもいいかも
便利そうなもの
nullチェック
CanBeNullAttribute
NotNullAttribute
ItemNotNullAttribute
ItemCanBeNullAttribute
範囲チェック
ValueRangeAttribute
NonNegativeValueAttribute
その他
PublicAPIAttribute
MustDisposeResourceAttribute
CollectionAccessAttribute
この属性を使用すると、すべてのコレクションメソッドにこの属性が設定されている場合にのみ意味があります。
Annotation not foundの警告はリフレクション関連なので別物
MAの警告部分のコードを確認した
日本語パス関連のバグ調査で、MAやNDMFをアンインストールした状態で実行することがあったが、依存部分を分離しない場合はそのような調査が困難になる
vccでは依存パッケージを強制的に削除することができるので、依存パッケージが無くてもビルドが通るようにしておく
vrchat依存アセンブリは、条件が揃っていないときビルドに含めないようにする (constraint)
起動アセンブリで、vrchatアセンブリが存在するか否かによって処理を分岐する
constraintで無視する場合、version definesがfalseになるか？
メインウインドウの起動と表情エディタ単体起動で、どこから場合分けするか？
コンテナは統一？
vrchatアセンブリが存在するかどうかで分岐し、単体起動かどうかで分岐しない
デフォルト表情の反映に工夫がいりそう
反映タイミング
デフォルト表情のアニメーションがセットされたとき
デフォルト表情のアニメーションが編集されたとき
C-S押下のタイミングで反映？
C-S押さない人もいそう
というかアセット変更時ってC-S押さなくても保存されるのでは？
反映が頻繁すぎる場合、かなり動作が重くなる
フォーカス移動のタイミングで反映？
反映先
表情エディタのプレビュー
表情サムネイル
制御の主をどうするか
EditorWindowを主とする
管理クラスを作る
Edit, Playの変更時に、EditorWindowが管理クラスを呼ぶ
管理クラスを呼ぶメソッドはインターフェースとして、EditorWindowが管理クラスに依存しないようにする
管理クラスを呼ぶメソッドはstaticにする必要がある？
コアドメインを考える
ジェスチャーとExMenuによる表情制御の設定を自動化する
VRCSDKと不可分なのでは？
一般化する？
表情制御の設定を自動化する
一般化した表情設定とは？
表情アニメーションの作成
プラットフォームに依存しない
AnimationClipで指定しないプラットフォームはどうか？
アニメーションのキーの指定という意味であれば非依存か？
表情再生の条件指定
プラットフォームに依存する
ジェスチャー
フェイストラッキング
メニュー
実際には、各表情に対応した条件指定の他に、表情再生全体の挙動を調整する設定が必要
まばたき設定や口変形キャンセル設定は一般化可能か？
実装できるかどうかは別（単にVRCSDKに依存しないというだけ）
VRMは口変形キャンセルではなく、ウェイトのオーバーライドを設定する（まばたきや目線も同様）
None: ウェイトを制限しない
Block: 表情再生中、リップシンクのウェイトを0にする
Blend: 表情のウェイトとリップシンクのウェイトの合計が1になるようにする
表情制御（スクリプトやAnimatorControllerなど）の自動生成
プラットフォームに依存する
設定部分が一般化されていれば、出力を変えればいいだけ
しかし、実際には実装によってできることの範囲が変わるので、設定部分がプラットフォームの実装に引っ張られる
VRMのように規格化された設定がない
サブドメインは？
ビジネスロジック（仕様）の部分に大したウェイトはない
何をビジネスロジックと考えるかによる
機能追加の作業量について考える
例）FaceEmo1.xに対して、左右ジェスチャー表情の一括合成ボタンを追加する場合
エンタープライズビジネスルール
手作業の改変をスクリプトで自動化する場合のロジック
アプリケーションビジネスルール
各ロジックをFaceEmoとして統合する場合のロジック
Editor
Startup
HierarchyLauncher.cs
Core
Domain
Localization
ILocalizer.cs
Usecase
UI
Localization
Localizer.cs
Presenter
View
VRChat
Domain
Fx
FxGenerator.cs
Layer
DefaultFaceLayer.cs
Usecase
UI
Presenter
View
Runtime
Component