メインコンテンツへスキップ
見出し画像

🪕「リュート風の楽器を奏でる絵」② | 単純ループアニメーションからの脱却 (2025-01-06)

    概要(Ver.2025.01.06)

    2024-11-12から開始の記事(①)⬇️が追記により長くなりました。この記事はその続き「②」です。

    今回は「SDKを使えばより動的な映像になるかも知れない」と、おぼろげに思い描いていたことを実践しました。「Live2D Cubism SDK for Unity」を試して、試行の末、導入となりました。映像内容の変化はほどほどですが、裏側の変化としては大きいので、記事を分けました。

    Ver.2024.12.31をベースに更新して、2025-01-06の⬇️以下の楽曲動画より、Ver.2025.01.06を適用してみました。

    • 更新の要点

      • 動画収録としてOBSのシーンに置いていた動く絵(ループ動画)に代わり、演奏可視化をするUnity上で「Live2D Cubism SDK for Unity」を使って、絵(Live2D)を動かすようにしました。

      • つまり、全体として単純なループアニメーションではない映像です。

      • この置き換えでは、キーフレームアニメーションでそれっぽい動きを強引に作りやすかったところも、ゲームキャラクターアニメーションのように、それぞれに制御された動きにしたいため、どの程度「雰囲気を維持できるか」、いくらか不安がありました。

      • 動かす要素により異なる制御を導入しました。

        • 時間長や値(位置)のランダム性(再現性なし)

        • 楽曲のテンポに関連した手や首左右揺らし周期

    ※ただし、楽曲の内容(音符)との明確な連動は今のところないというこ
    とも付け加えておきます。ここにロマンがあるとはいえ、単純にはいかないので今は踏み込まないでおきます。

    ソフトウェア開発的な裏話

    ここからはソフトウェア開発的な裏話です。

    まだ慣れていないライブラリ/SDK導入初期のよくあることが今回もありました。
    ※これにより、2025-01-05時点では採用できるか不明なまま、導入を延期をしました。

    これまではLive2Dのアニメーションを作りループ動画としていました。この方法では出力されるものに柔軟性はないですが、「演奏している風」を表現するにはある程度の範囲で手軽です。
    ただ、Unity上で動的制御がうまくいけば、もっと柔軟な表現が可能であるということは当初から考えていました。今回は、ちょっと柔軟な表現というところまでの厄介そうな要素が実際に出てきたお話を、ここに残しておきます。

    URPの不具合らしき現象の回避

    ※URP: Universal Render Pipeline。Unityの描画パイプライン(RP)の1つ。以前からある標準(ビルトインRP)に、ある時期からURPとHDRPの選択肢が加わっています。そのため、どのRPでの話題/問題であるかということも、考える必要が追加されてしまったのでした。

    よくあることが何かというと、「Unityエディタで動いた!」「これなら行けるかも」と思ってビルドしてみると実行画面が黒いままになり、やむを得ず対策を開始するという状況です。
    ソフトウェアは安定版/動作確認済みの組み合わせで構築すべきではあります。そうは言っても実際には、段階的、突発的に物事を進める上で、理想的な条件を維持することは困難です。
    というわけで、安定が確認された条件ではないとは見られますが、そんな中で、原因特定や回避策を探しました。

    この種の問題は厄介で、最初は回避策があるかも不明でした。
    チャット系AIに問題点を投げて、検討を始めることにしました。基本的には詳しい情報があるほどよいといった感じの回答ですが、お約束の検討事項を挙げてくれるので、意味がありそうなものから考えてみることができます。

    そこから、ビルド実行時のエラーログを取ることに進み、広めの可能性の回答をもらいながら、通常の検索エンジンでエラーログの断片を検索語にすると、次の情報が出てきました。

    URPのカメラスタックをMSAA有効で使うとビルドでエラーするという問題の情報にたどり着き、この可能性はちょっとありそうでした。

    チャットAIに、このURLや文面を投げてみても、解決策は含まれてないとしましたが、実際にやってみると、MSAA(アンチエリアシングの一種)を無効にすることで問題が回避ができました。
    ※MSAA無効による画質低下などの代償はあります。

    更新順序の厄介さ

    これ以前に、すでに演奏可視化と、楽曲音声再生の同期で、ある程度特殊な制御方法をしています。
    そこへ、UnityのAnimatorを絡めた形でLive2Dのパラメータを更新するのは少し不安要素です。
    ※すでに難点を経験済みなのですが、Animator周りは何年も(表面的に)空転していて、別のソリューションが出てくるまで、やりくりするしかない、みたいなところがあります。

    実際、うまくいったりいかなかったりして、それがスクリプトコンパイルの反映とリロードに関する問題なのか、更新順序などに関連するのかといったところで、形になるまで手間取りました。
    SDKドキュメントにも関連した機能の記述があるようですが、全体像を把握できていないので、ひとまず動く方法を優先することにしました。

    • 🎹演奏可視化側 → FixedUpdateで機能するように構築済み

    • 🖼️Live2D → パラメータ変更は特定順序のUpdateでないと反映しない

    • 🎹と🖼️は一部連動したい

    ※全容は把握していませんが、現状として。

    まとめ

    単純なループアニメーションではない、ちょっと柔軟な表現の映像になりました。

    今回の変更によっても、アラが見える部分もあったりします。段階的にやれたりやれなかったり、ということで。今後も微調整/更新をする可能性はあります。

    #Live2D #動画 #画像生成AI #Unity

    あなたへのおすすめ