[1.0] Expression、ignore系の名称変更およびblendの提案

[0b5vr]

昨日、akiraさんに #185 の件でヒアリングを行った中で出た話題なのですが、

例えば、目を閉じる動作を伴うHappyにおいてignoreBlinkでblinkを無視すると、目を閉じた状態で0.5だけ笑うという処理ができなくなるのではないかという指摘がありました。
ignore系にもう少し柔軟性をもたせても良いのではないかと思いました。
また、"ignore"という名前も少しミスリードを招き、良くないかもと思いました。

具体的には、 overrideBlink という名称に変更し、 none nullify blend という選択肢から選べるようにすると良いのかと思いました。
none nullify が従来の ignoreBlink に相当する処理です。
blend の場合、 overrideされる側' = overrideされる側 * (1.0 - overrideする側) という数式を用いてblendを行うとよいかと思います。

[ousttrue]

実際にその設定が有効に働いているスクリーンショットとかあれば説得力が上がると思いまうす。

[0b5vr]

やってみまうす 🐭

[ousttrue]

設計思想としては BlendShpaeProxy にはロジックを入れずに 単なるセッター ・ゲッター(訂正) にしときたくて、
排他制御等の微妙なロジックを持つのはユーザー定義のコントローラーの責務にしたいのです。最低限の標準実装例は作るけど、込み入ったものは自作していただきたいという感じです(VRMBlendShapeProxy はブラックボックスのまま、太ってしまった)

ソース(AutoBlinker, 音声解析からLipSync作る, LookAt) => ユーザー自作のコントローラー => VRMBlendShpaeProxy(VRMController)

ただ現状だと、Blinker, Aioueo, Lookat などが BlendShapeProxy(1.0はVrmController) に直接ささっていたりするので、ここら辺整理は必要そうです。

[0b5vr]

設計思想としては BlendShpaeProxy にはロジックを入れずに 単なるセッター・ゲッターにしときたくて、
排他制御等の微妙なロジックを持つのはユーザー定義のコントローラーの責務にしたいのです。最低限の標準実装例は作るけど、込み入ったものは自作していただきたいという感じです(VRMBlendShapeProxy はブラックボックスのまま、太ってしまった)

以下、日本語がかなりとっちらかっていますが、伝わることを願います。

どちらかというと私の意図は、アプリケーションごとに実装が違う状態を作りたくなかったです。
アプリケーションごとに繊細なセットアップを可能にするのは、表現力を向上させる意味で有用と思いますが、
結果的にアプリケーションごとにアバターに別々のセットアップを施したりしなきゃいけなくなり、可搬性に優れる状態ではなくなってしまうのかなと思いました。

そもそも、それをわざわざアプリケーションに実装させる仕組みにして、ほんとうにそれをわざわざ実装してくれるアプリケーション開発者が多数を占めるとは思いません。
実装例を示したところで、それを使っていないサードパーティーのドキュメントが出回りすぎて、結果的に使われないみたいな未来は簡単に見えてしまいます。

なお、本当にここを自前で調整したいアプリケーション向けに、実装側でここをかんたんにオーバーライドできるようにするのはありかと思います。
それこそ、VMCとかでは現状でもユーザーがそういう微調整ができるような実装がされているイメージが見えます。
ただ、リファレンス実装はデフォルトで有効になっているべきです。

---

こちらは提案したもののデモです。

https://glitch.com/~pointed-impartial-honeydew

[0b5vr]

口頭で議論をしました。

• nullify を block にしてみます

[Santarh]

意図は理解しますし、やりたいことも理解します。
表情に対するオプションは標準実装でカバーすべきだというのも同意しますし、実際 1.0 の実装の方には入っていたかと思います。今のフラグとその制御実装は、自分がさまざまなモデルユースケースを考慮して「任意の表情 weight を入力としても、任意の表情が設定を外れて崩壊しえない」に則って定義実装したものです。
命名の変更も block ならまあ良いかなという気がします。
ただ、 blend を入れるのはかなり厳しい動作になるかなと思います。

overrideされる側' = overrideされる側 * (1.0 - overrideする側

とありますが、任意の表情 weight を設定する時に、この動作は決定的ではありません。同時に有効になる表情はかならず1つとは限らないからです。

0/1 で制御するのはうまくいくことが多いですが、中間値を許すととたんに破綻してしまいます。

中間値は「任意の表情 weight をとったときに、特定の表情が想定と違って破綻しないようにする」上ではかなりの「作者の意図しない崩壊」が多発すると思います。

[ousttrue]

あ、勘違いしてました。

blink (来る方) を減衰させるのかと思ってました。
２個以上設定したたときにとかにまずそう。

たとえば

• happly 1.0 + blink 0.5=> happly 0.5 + blink 0.5
• happly 1.0 + A 0.5=> happly 0.5 + A 0.5

一個でも

• happly 1.0 + A 0.5=> happly 0.5 + A 0.5

口は比較的早く動きので表情が高速で変わって変になりそうな。

[ousttrue]

原則としては、

• 来る プロシージャルであることが想定される 割り込みExpression 値 (bilnk, lipsync, lookAt)を加工するのはあり
• 受ける方 overrideXXXが設定してある喜怒哀楽などのExpreeesion 値を変えない

は守るべきと思います。

[0b5vr]

この動作は決定的ではありません。同時に有効になる表情はかならず1つとは限らないからです。

複数のoverrideする表情が0より大きい値の場合に、どのように値をブレンドするか、を定義すればよいでしょうか？
上で提案したデモ実装においては、"blendでoverride" する表情の値の総和を積算しています。これを仕様に明記することはできると思います。
e.g. happyとsadが overrideBlink = blend の場合、 blink' = blink * saturate(1.0 - (happy + sad))

0/1 で制御するのはうまくいくことが多いですが、中間値を許すととたんに破綻してしまいます。

ここが理解できていないです。具体的には、どのような場合に破綻が発生するでしょうか？

原則としては、

• 来る方 (bilnk, lipsync, lookAt)を加工するのはあり
• 受ける方 値を変えない

は守るべきと思います。

来る方・受ける方という単語が理解できていないですが、
Expressionが適用される順序に関わらず、overrideされる側の値しか変化しないという認識です。
順序を考慮したいという話でしょうか？

[ousttrue]

概念

• プロシージャルな Expression(blink, lipsync, lookAt) が不規則に割り込んでくる(来ると言っていた)。このときに Expression(blink, lipsync, lookAt) 値(0-1)を加工する設定

オーバーライドも言葉として誤解を誘発してそう。
例えば、喜に overrideBlink 設定する => blink により喜の値が変わりそう。
オーバーライドする => どっちが、どっちを？ というのが分かりづらいと思いました。

喜の overrideBlink 設定が blink 値をオーバーライドする くらい毎回書かないと間違えそう。

blinkOp とか？Operation, Option

[0b5vr]

これ、なんでPendingに入ったかど忘れしてしまった……　ごめんなさい……

[0b5vr]

口頭で議論を行いました。

名前は継続的に検討しつつ、実装を試みてみます。

[Santarh]

返答気づかず、すみません。

複数のoverrideする表情が0より大きい値の場合に、どのように値をブレンドするか、を定義すればよいでしょうか？
上で提案したデモ実装においては、"blendでoverride" する表情の値の総和を積算しています。これを仕様に明記することはできると思います。
e.g. happyとsadが overrideBlink = blend の場合、 blink' = blink * saturate(1.0 - (happy + sad))

はい、この場合の挙動についての考慮がなされていなさそうだったのが懸念点だったので、こちらで問題ないと思われます。

ここが理解できていないです。具体的には、どのような場合に破綻が発生するでしょうか？

こちらは私の言葉足らずですね、すみません。これは「実際的な 3D モデル製作において、線形補間を前提に Blend された中間値を取る BlendShape の設計を考慮に入れるのは難しいのではないか」ということです。
ただしこれは、そういった中間値をとるあらゆる組み合わせにおける見た目の保証についてであり、単一の表情間を遷移する際の中間値においては問題はさほどおきないでしょう。（表情遷移の時間って 1 秒未満だと思いますし）

というわけで、自分としては疑問点は解消しているので、全体的に同意します。

[ousttrue]

block と blend が先頭２文字が同じで、コード補完の邪魔になる(しまったー)以外は特に問題ない感じです。

[0b5vr]

blockしっくりきてきました