キャラカメでは、株式会社ジーン様からキャラカメでの利用向けにご提供いただいた真田幸村の3Dモデルをもとに、まばたき・5母音の口形・感情表現を備えたVRMデータを制作しました。Blenderでの表情制作、Unity／UniVRMでのVRM化、Godotを使用する実機での互換性確認を経て、今回のモデルを採用しました。

本記事では、既存のキャラクター資産を「表情を入力して動かせるアバター」へ展開するために、どのような工程と検証を行ったかをご紹介します。

VR/AR体験のキャラクター資産を活用

今回のデータ提供元は、株式会社ジーン様です。題材となった真田幸村は、VR/AR体験で使用されたキャラクターです。元モデルが持つ顔立ちや甲冑、質感を生かしながら、キャラカメで扱うための表情と姿勢を整えました。

今回の取り組みは、新しいキャラクターをゼロから生成するものではありません。既存モデルの造形を尊重し、利用先に必要な機能を追加する技術検証です。

このキャラクターは、株式会社ジーン様が開発したVRチャンバラアトラクション「VS真田幸村」でも使用されました。

馬を含むデータから、人物モデルを取り出す

ご提供いただいたFBXには、真田幸村の人物モデルだけでなく、馬や馬具、それぞれを動かすための骨格も含まれていました。

そこで最初に元データを保管したまま作業用のコピーを用意し、Unity上で馬側のモデルと骨格を変換対象から外して、甲冑や槍を含む人物側を残しました。

人物の骨格とメッシュの結び付きを保ちながら材質・テクスチャの参照を整え、人物単体のVRMを出力して再読み込みを確認しています。そのうえで、Blenderによるまばたきや口形などの表情追加へ進みました。

形式変換だけでは、表情は増えない

FBXをVRMへ変換しても、元データにない表情が自動的に追加されるわけではありません。今回調査した顔メッシュには、表情用のShape Keyがありませんでした。

そこで、モデルを変換する工程と、表情を作る工程を分けました。最初にUnityで基準となるVRMを作り、Blenderで顔の構造を調査。まぶた・口角・口内など、どの頂点を動かせるかを確認してから、表情の変形差分を作成しています。

馬を含むFBX資産の調査・人物モデルの抽出 → 基準VRM作成 → Blenderで表情制作 → GLBを介した変形差分の受け渡し → Unity／UniVRMでVRM出力・再検証 → Godot／実機で確認・採用

1. まずは、まばたきで往復工程を確認

最初からすべての表情を追加せず、両目・左目・右目のまばたきから着手しました。

今回のVRM側の顔は1,274頂点。眼の表面とまぶたが同じ顔メッシュに含まれているため、顔全体を一律に縮めるのではなく、まぶたの対象頂点を選んで変形させています。また、同じ位置に分割されている頂点の動きをそろえ、境界に裂け目が出ないようにしました。

BlenderからGLBへ出力した後は、向きと頂点対応を照合し、基準VRMへ顔の変形差分を転写しました。全身の骨格や材質を丸ごと置き換えず、表情制作に必要な変更を切り分けた点がポイントです。確認は「開眼」と「閉眼」だけでなく、25・50・75％の途中の形や、0％へ戻したときの復帰もチェックしました。

2. 5母音と感情を追加し、動画を見ながら強さを調整

まばたきの経路が成立した後、「あ・い・う・え・お」に対応する口形、笑顔・怒り・悲しみ・楽しさの感情表現、口角や眉などの制御を追加しました。

初期版の動画では表情が控えめだったため、レビューをもとに笑顔の口角を上げ、目尻を下げる方向へ調整。悲しみには伏し目を加え、5母音も開口・横幅・すぼめの変形を強めています。ブリンクと組み合わせた際のまぶたの崩れも確認しました。

最終データは21個のモーフと24個の有効な表情クリップを持ちます。クリップの一部は同じモーフを共有するため、24種類の独立した形状があるという意味ではありません。なお、5母音の口形を作ることと、音声から母音を自動認識することは別です。今回追加したのは、入力された値に応じて口を動かすためのモデル側の表情データです。

3. Unityで読み込めるだけでなく、Godot側の整合性も確認

今回の重要な学びの一つが、エンジン間のデータ整合性です。Unityで表示できることだけをもって、Godotでも問題なく扱えるとは判断しませんでした。

実際に、表情を増やした際、メッシュ側とプリミティブ側のモーフ名リストに個数の不一致が見つかりました。そこで、名前・順序・モーフ配列・初期ウェイトをそろえ、表情クリップが正しい対象を参照するか検証しました。これは今回のデータと実装の組み合わせで確認した互換性対策です。

同じモーフを複数の入力が使う場合にも注意が必要です。例えば「口開け」と母音A、「目を細める」と部分的なまばたきが共有する変形を整理し、重複入力で意図以上に変形しないよう扱いを確認しています。

4. 表情とは別工程で、基準姿勢と足元を調整

顔まわりの確認後、腕を水平にしたTポーズを基礎に、脚幅と足首の向きを調整しました。足首の内向きや足裏の浮きを、床付きの正面・側面・斜め画像で確認し、自然な脚幅を維持したまま足裏内側の支持点を床へ近づけています。

靴底の形状を平坦化したわけではなく、反りによる隙間は残ります。全身の床接触を完全に解決したという扱いにはせず、顔中心の利用と全身姿勢の確認を分けました。

5. 数値検証・目視確認・実機検証を分ける

最終候補では、Unityで24クリップを6段階の値で確認する144状態の検証を実施。さらにPlay Modeでは、視点変更・関節の曲げ戻し・表情を合わせた204状態について、変形、有限な座標、ニュートラルへの復帰を確認しました。

実機側ではGodotによるモデル読込、表情プロファイルの結び付け、既存の9係数入力、5母音を直接入力する検証を実施。確認対象ログでは無効インデックスやNaN、クラッシュ、タイムアウトなどの致命的エラーは検出されず、各検証は正常終了しました。正式配備後のプロジェクトでも再確認しています。

以下の動画は、ブリンク・5母音・感情表現を組み合わせた実機上の確認映像です。

一方、既知のスクリプトキャッシュ関連メッセージやテクスチャ形式変換の警告は残っています。また、今回の確認は長時間稼働やあらゆるVRM対応アプリでの動作、全身描画への対応を保証するものではありません。表情動画のレビューと、Unityでの確認・実機データ検証を組み合わせて評価しました。

既存の3D資産を、次の体験へ

今回の取り組みでは、FBXからVRMへの変換に加え、「表情を作る」「キャラクターらしい強さに整える」「エンジン間の整合性を確かめる」「実機で確認する」工程をつなぎました。

表情の自然さには、元モデルの顔の構造、口内形状、ひげや兜による見え方なども影響します。悲しみの表現などには改善の余地があり、表情の自然さは継続的に調整していきます。

既存のキャラクター資産を生かし、表情を通じた新しい体験へつなぐ。その具体的な制作・検証事例として、今回のワークフローをご紹介しました。

データをご提供いただいた株式会社ジーン様に、心より御礼申し上げます。

キャラクターデータ提供：株式会社ジーン様

※本記事は制作・検証事例の紹介です。キャラクターモデルデータの配布は行いません。