Skip to content

Home

Jump to bottom
Fuji Sunflower edited this page Apr 3, 2026 · 327 revisions

名称の曖昧さ

今後アバターという言葉が出てきますが、アバターとは何かが実は曖昧に扱われています。
「3Dデータのキャラクターをアバターとして使用する」という文脈もありますし、3Dデータとキャラクターとアバターが同じ意味の文脈もあります。

VRM 0系とは

VRMは株式会社ドワンゴが2018年4月16日に開発したVR向け3Dアバターファイルフォーマットです。
2018年当時はドワンゴのGithubにドキュメントがありましたが、VRMコンソーシアムのGithubにドキュメントが移管されたようです。
VRMコンソーシアムは2019年2月に設立されたそうです。
VRMコンソーシアムは2022年の9月22日に既存のVRM規格の課題などを解決するためにVRM 1系を正式リリースしました。
そのためVRM 0系とはVRM 1系より前のVRM規格のことです。
ちなみにVRMという名称の由来は記録が存在しないので不明です。

VRM 0系の理想

VRM規格は「VRアプリケーション向けの人型3Dアバター（3Dモデル）データを扱うためのファイルフォーマット」です。
VRM対応アプリケーション間でクロスプラットフォームに使用出来ることを想定しています。
glTF 2.0をベースにしているため、VRMファイルの拡張子を.glbに変更するだけでGLBファイルとして読み込むことも出来ます。

過去の詳細 https://web.archive.org/web/20180416084732/https://dwango.github.io/vrm/

VRM 0系の現状

文言の変更

VRM規格の文言が何度か変更されていて、最近では「3Dアバター向けファイルフォーマット」と表記されています。
現在の詳細 https://vrm-consortium.org/

座標変換の謎

UnityからVRMを書きだす際の座標変換には謎があり、glTF内部ではZ+方向ではなくZ-方向を3Dキャラクターが向いています。
VRM 0系ファイルの拡張子を.glbに変更した場合のGLBファイルのキャラクターは基本的な風習では後ろ向きになります。
なおZ-方向を3Dキャラクターが向いているのは当初のドキュメントにも記載があるようです。

クロスプラットフォームの課題

クロスプラットフォームを謳っていましたが、VRMコンソーシアムが主に更新しているのはUnity向けVRMライブラリUniVRMだけでした。また、VRM 0系のglTF拡張には恐らくUnity想定の名称があります。

公式見解の差異

VRMライブラリにはthree-vrmというものがあります。 VRMコンソーシアムと関わりがあるpixivが管理しているようです。
2018年当時は公式ライブラリの一種と思っていましたが、UniVRMとthree-vrmでVRM 0系の概念の扱いに差異があるようです。

個人作成ライブラリ

クロスプラットフォームを謳っていましたが、VRMコンソーシアムではなく個人の方が更新しているライブラリに頼っていることがあります。 ちなみにUniVRMを基準に作成したかthree-vrmを基準に作成したかで差異があります。

VRM 0.x系

今までVRM 0系と表記していますが、VRMコンソーシアムとしてはVRM 0.x系らしいです。
2018年当時から更新の際に内部仕様が何度か変更されたため、正確なバージョンが分からないのが理由らしいです。
VRM 1系をリリースした時点のVRM 0.x系を最終版と考えるのが無難なので、サンフラワーふじはVRM 0系と表記しています。

解説の散逸

口頭のワークショップ形式でVRM仕様の解説をしていたらしく、解説の記録が散逸しています。

VRM 0系の仕様

glTF/extensions/VRM
glTF/extensions/VRM/exporterVersion
glTF/extensions/VRM/specVersion
glTF/extensions/VRM/meta
glTF/extensions/VRM/humanoid
glTF/extensions/VRM/firstPerson
glTF/extensions/VRM/blendShapeMaster
glTF/extensions/VRM/secondaryAnimation
glTF/extensions/VRM/materialProperties

備考

VRM 0系の概念

UniVRMが公式的なライブラリだったため、VRM 0系の仕様とUniVRMの仕様が混同された状態でした。
そのためVRMファイルに記録した値の必須性や使用法に関しては曖昧な点があります。
VRM 0系の概念を表現する正式名称に関しては特に決まっていない問題があります。
このwikiで便宜上表記している名称を信じないでください。

ボーンの正規化

glTF拡張部

glTF拡張部は無い

ボーンの回転を(0.0, 0.0, 0.0)と拡大縮小を(1.0, 1.0, 1.0)としてVRMを保存する正規化処理があります。
正規化という難解な言葉ですが、内容としてはトランスフォームの適用です。

UniVRM

UniVRMはSkinnedMeshRenderが付属するゲームオブジェクト（glTFとしてはノード）の位置を記録していたため、トランスフォームの適用として十分だったかは怪しいです。
ちなみに、UniVRMではVRMを仮出力して再読み込みしてからVRM設定を行う不思議な出力手順だったので正規化されていないVRM 0系を出力可能でした。

余談

VRM 1系のローカル軸保存方法として、VRM拡張に正規化するための値を記録しておいて読み込む際に回転と拡大縮小を処理しても良かったのではないかなと思っていました。ローカル軸が残っているGLBと正規化するためのVRM拡張という想定です。
VRMコンソーシアムでの議論ではVRM仕様とUniVRMなどのインポーターの仕様が常に混同しているので上手く伝わりませんでした。

マテリアル (VRMMaterial)

glTF拡張部

glTF/extensions/VRM/materialProperties[]

https://vrm.dev/univrm/shaders/

名称 説明 備考
name マテリアルの名前 -------------
shader シェーダの名前 過去のマテリアル名がいくつかあります。
renderQueue Unityのレンダーキュー Unity想定の機能です。
floatProperties Unityのマテリアル変数 Unity想定の機能です。
vectorProperties Unityのマテリアル変数 Unity想定の機能です。
textureProperties Unityのマテリアル変数 Unity想定の機能です。
keywordMap Unityのマテリアル変数 Unity想定の機能です。
tagMap Unityのマテリアル変数 Unity想定の機能です。

VRM 0系のシェーダ

UniUnlit

Standard

MToon

UniVRMでRenderingTypeをTransparentWithZWriteに設定すると謎の警告が出るため、使いたくない気持ちになったが単にZWriteが有効なだけだったらしいです。 https://www.slideshare.net/slideshow/vrm-mtoon/175540511

過去のマテリアル

過去にあった複数のマテリアルはUniUnlitに統合されたと思われます。

  • VRM/UnlitCutout
  • VRM/UnlitTexture
  • VRM/UnlitTransparent
  • VRM/UnlitTransparentZWrite

備考

調査中：UniVRMのプロジェクトはLinearに設定されるが、シェーダにリニアワークフロー関係の関数を使用していたか 調査中：UnityのStandardシェーダーのMetallicは実はPBRのMetalnessを2乗したものだった記憶があるが、UniVRMが正しく扱っていたか

表情 (VRMBlendShape)

glTF拡張部

glTF/extensions/VRM/blendShapeMaster
名称 説明 備考
blendShapeGroups ------------- ------------- 
glTF/extensions/VRM/blendShapeMaster[]
名称 説明 備考
name VRM表情の名前 presetNameがUnknownの時に必要になる
presetName VRM表情のプリセットとの対応関係 -------------
binds 頂点モーフの対応関係 -------------
materialValues マテリアルモーフの対応関係 ------------- 
glTF/extensions/VRM/blendShapeMaster[]/binds[]
名称 説明 備考
mesh メッシュとの対応関係 -------------
index ブレンドシェイプとの対応関係 -------------
weight 変形の程度 ------------- 
glTF/extensions/VRM/blendShapeMaster[]/materialValues[]
名称 説明 備考
materialName マテリアルとの対応関係 -------------
propertyName マテリアル変数との対応関係 -------------
targetValue マテリアル変数に入力する値 -------------

頂点モーフ機能が基本ですが、マテリアルの色やUVの変更が可能でした。
マテリアルの色やUVの変更の名称はほとんどUnityの名称を踏襲しています。
ちなみに、複数のブレンドシェイプをまとめて扱うことが可能です。

プリセット表情 (presetName)

プリセット表情と思われるのは以下の17個です。
アプリ側がVRMの表情操作をする際にプリセット表情の存在はほとんど保証されていましたが、プリセット表情の内容設定が必須かは曖昧です。

名称 内容
A 「あ」の発声の表情
I 「い」の発声の表情
U 「う」の発声の表情
E 「え」の発声の表情
O 「お」の発声の表情
Blink まばたきの表情
Blink_L 右まばたきの表情
Blink_R 左まばたきの表情
Joy 喜怒哀楽の喜びの表情
Angry 喜怒哀楽の怒りの表情
Sorrow 喜怒哀楽の悲しみの表情
Fun 喜怒哀楽の楽しみの表情
LookUp 上を見た時の表情
LookDown 下を見た時の表情
LookLeft 左を見た時の表情
LookRight 右を見た時の表情
Neutral 待機時の表情

備考

  • 2018年当時ではVIVEコントローラーを使用することが多かったので、喜怒哀楽を4方向の操作で手軽でした。

カスタム表情

プリセット表情以外のカスタム表情を追加出来ました。 VRM対応アプリがカスタム表情を使用可能にすべきかは曖昧でした。

驚き

驚きはVRoid Studioが追加していたカスタム表情です。
VRM 1系ではプリセット表情になったらしいです。
VRコントローラーで5方向の操作となり煩雑となりました。

パーフェクトシンク

それなりの認知度がありますが、VRM 0系の標準機能ではありません。
iOS ARKitで決められている表情をVRMのカスタム表情として追加するようです。
iOS ARKitで決められている表情を合算するため、細かいカスタム表情を大量に追加するようです。

課題

まばたきの曖昧さ

まばたきを使用するか、右まばたきと左まばたきの同時使用でまばたきとするかはVRM対応アプリごとに曖昧でした。

喜怒哀楽の楽

喜怒哀楽の喜と楽の違いがよく分からなかった。

感情表現なのかが曖昧

4つの表情として使用するのか感情表現として使用するのかがアプリごとに曖昧でした。
例えばキャラクターが喜ぶ場面でロボットが意味もなく変形するようなことが起きました。

ニュートラル表情の必須性

UniVRMにはニュートラル表情を活用したベイクがありますが、ベイク機能がVRM仕様なのかは曖昧でした。 UniVRMのベイク機能は処理が力業のためUnityのBlendShapeのウェイトが100を超えてしまうと上手く再現できないことがあります。

ニュートラル表情をどう使用するかは、対応アプリ側にはうまく伝わっていませんでした。 UniVRMでは表情操作APIでVRM対応アプリ側が常時ニュートラル表情を指定すれば使用は可能でしたが、アプリ側で設定する必要がありアプリ毎の差異がありました。 https://github.com/vrm-c/vrm-specification/issues/185 https://vrm.dev/api/runtime-import/VRM_BlendShapeProxy/

VRoid Studioでの解釈

口パク・まばたき・感情表現 VRoid Studio製のアバターは感情表現の表情に口の動きが混ざっていたため、口パクと感情表現が混ざると顔が破綻することがありました。
VRoid Studio製のアバターの使用率は多かったため、VRM対応アプリケーションでは感情表現すると口パクとまばたきが停止する処理をしていることが多いです。
ちなみにUniVRMでの表情操作は、複数のブレンドシェイプを組み合わせを指定したVRM表情を呼び出している。
そのため、口を開くブレンドシェイプと目を見開くブレンドシェイプを組み合わせてVRM表情として指定した場合はそこまで破綻しなかったはずです。
VRoid Studioの場合は、口を開いて目を見開いたブレンドシェイプ自体をVRM表情として指定していたようです。

  • 表情に含めてよい部位の動きの推奨項目があっても良かったかもしれない。

VRMBlendShapeのAPI周知不足

UniVRMではVRMBlendShapeに関してVRMBlendShapeProxyのAPIを呼び出すのが正式な使い方でしたが、上手く周知されずブレンドシェイプ自体を操作するアプリもあったようです。
ちなみに、アプリがVRMのプリセット表情やVRMのカスタム表情に含まれていないブレンドシェイプを使用して良いかは曖昧でした。

シェイプキー法線

VRM 0系のせいではないが、当時のBlenderから出力したFBXファイルにはシェイプキー法線が無かったので、表情操作で陰影が歪むことがあった。

物理演算

glTF拡張部

glTF/extensions/VRM/secondaryAnimation

揺れ物 (VRMSpringBone)

UniVRMでCenterにVRMとしての最親となるゲームオブジェクトを設定するとCenterはNone扱いになる。 VRMとしての最親となるゲームオブジェクトの子階層にあるゲームオブジェクトがUniVRMのglTFの扱いとしてはルートノードである。
備考：出力の際のglTFルートノードの扱いが間違っているだけの可能性がある。

glTF/extensions/VRM/secondaryAnimation/boneGroups[]
名称 説明 備考
comment ------------- -------------
stiffiness ------------- -------------
gravityPower ------------- -------------
gravityDir ------------- -------------
dragForce ------------- -------------
center ------------- -------------
hitRadius ------------- -------------
bones ------------- -------------
colliderGroups ------------- -------------

揺れ物の衝突判定 (VRMSpringBoneCollidergroup)

VRMSpringBoneで接触可能なVRMSpringBoneColliderGroupを指定出来た。
複数のVRMを読み込んだ際にVRMSpringBoneで他のVRMのVRMSpringBoneColliderGroupを接触可能にして良いかは曖昧だった。

glTF/extensions/VRM/secondaryAnimation/colliderGroups[]
名称 説明 備考
node ------------- -------------
colliders ------------- ------------- 
glTF/extensions/VRM/secondaryAnimation/colliderGroups[]/colliders[]
名称 説明 備考
offset ------------- -------------
radius ------------- ------------- 
glTF/extensions/VRM/secondaryAnimation/colliderGroups[]/colliders[]/offset
名称 説明 備考
x ------------- glTFの標準的な仕様に合わせると配列でまとめた方が良い
y ------------- glTFの標準的な仕様に合わせると配列でまとめた方が良い
z ------------- glTFの標準的な仕様に合わせると配列でまとめた方が良い

人型ボーン (VRMHumanoid)

glTF拡張部

glTF/extensions/VRM/humanoid
名称 説明 備考
bone 人型ボーンとの対応関係
node ボーンとの対応関係
useDefaultValues UnityのHumanLimit.useDefaultValues UniVRMのスクリプトに必要か分からないと書いてあります。
min UnityのHumanLimit.min UniVRMのスクリプトに必要か分からないと書いてあります。
max UnityのHumanLimit.max UniVRMのスクリプトに必要か分からないと書いてあります。
center UnityのHumanLimit.center UniVRMのスクリプトに必要か分からないと書いてあります。
axisLength UnityのHumanLimit.axisLength UniVRMのスクリプトに必要か分からないと書いてあります。
名称 説明 備考
neck 首 必須
head 頭 必須
hips 尻 必須
spine 腰 必須
chest 胸 必須
leftUpperArm 左上腕 必須
leftLowerArm 左前腕 必須
leftHand 左手 必須
leftUpperLeg 左大腿 必須
leftLowerLeg 左下腿 必須
leftFoot 左足 必須
rightUpperArm 右上腕 必須
rightLowerArm 右前腕 必須
rightHand 右手 必須
rightUpperLeg 右大腿 必須
rightLowerLeg 右下腿 必須
rightFoot 右足 必須
名称 説明 備考
jaw 顎 任意
upperChest 胸の上部 任意
leftToe 左つま先 任意
leftEye 左目 任意
leftShoulder 左肩 任意
rightToe 右つま先 任意
rightEye 右目 任意
rightShoulder 右肩 任意
leftThumbProximal ------------- 任意
leftThumbIntermediate ------------- 任意
leftThumbDistal ------------- 任意
leftIndexProximal ------------- 任意
leftIndexIntermediate ------------- 任意
leftIndexDistal ------------- 任意
leftMiddleProximal ------------- 任意
leftMiddleIntermediate ------------- 任意
leftMiddleDistal ------------- 任意
leftRingProximal ------------- 任意
leftRingIntermediate ------------- 任意
leftRingDistal ------------- 任意
leftLittleProximal ------------- 任意
leftLittleIntermediate ------------- 任意
leftLittleDistal ------------- 任意
rightThumbProximal ------------- 任意
rightThumbIntermediate ------------- 任意
rightThumbDistal ------------- 任意
rightIndexProximal ------------- 任意
rightIndexIntermediate ------------- 任意
rightIndexDistal ------------- 任意
rightMiddleProximal ------------- 任意
rightMiddleIntermediate ------------- 任意
rightMiddleDistal ------------- 任意
rightRingProximal ------------- 任意
rightRingIntermediate ------------- 任意
rightRingDistal ------------- 任意
rightLittleProximal ------------- 任意
rightLittleIntermediate ------------- 任意
rightLittleDistal ------------- 任意

備考

https://vrm.dev/univrm/humanoid/humanoid_overview/ UnityのHumanBodyBonesを概ね踏襲している。
必須ボーンと必須ではないボーンが存在するため、スクリプトの際にnullチェックをする必要があり取り扱いが実は不便だった。
https://github.com/vrm-c/vrm-specification/blob/master/specification/0.0/README.ja.md 必須ボーンと必須ではないボーンが存在するのは簡易的なボーン構造のキャラクターにも対応するための配慮だと思われます。
必須ではないですが、指ボーンはなんだかんだ設定しておいた方が無難でした。
あごボーンはなんだかんだ設定しない方が無難でした。
つま先ボーンは設定しない方が無難なときもありましたが、設定した方が無難な気はします。
ちなみにアプリで読み込んだVRMがVRMHumanoidのみを使用するのか、その他のボーンも使用するかは曖昧です。
ちなみにHipsの親階層になるボーンいわゆるルートボーンをDCCツールの時点で原点に作成しておいた方が無難です。

権利情報 (VRMMeta)

glTF拡張部

glTF/extensions/VRM/meta
名称 説明 備考
title キャラクターの名称 アプリ側で必ず活用すべきかは曖昧でした。
version バージョン情報 イラストの差分というよりもプログラマー的な感覚でのバージョン管理で用意したと思われる。バージョン情報が必須かどうかはUniVRMとthree-vrmで見解の差異があります。
author キャラクターの作者 ユーザー自体が既存データをVRMに変換して「作る」ことがあったため、誰を表記すればいいか曖昧でした。
contactInformation 連絡先情報 設定すべきかよく分からない
reference 親作品 ニコニコ動画のコンテンツツリーのようなものを想定していると思われる。
texture サムネイル 設定されているかが曖昧だったので、上手く活用されませんでした。
allowedUserName アバター使用の利用規約 2018年当時は美少女キャラクターをおじさんがアバターとして使用してよいか問題があり、単なる使用だけではなくキャラクターをアバターとして使用して良いかが焦点にあったと思われる。Only AuthorかEveryoneだけが周知されていた時期があり、Explictly Licensed Personを設定するとアプリで使用出来ない時期がありました。
violentUssageName 暴力表現の利用規約 -------------
sexualUssageName 性的描写の利用規約 -------------
commercialUssageName 商業利用の利用規約 -------------
otherPermissionUrl その他の利用規約 UrlではなくURLにすべきだとは思う
licenseName 再配布と改変に関する利用規約 -------------
otherLicenseUrl 再配布と改変に関するその他の利用規約 licenseNameがOtherの時だけ使用するのが正しいらしい。otherLicenseUrlはlicenseNameがOtherの時のみ設定可能というのが抜けていた時期があります。

備考

  • 3Dキャラクターの権利情報などですが、アプリに読み込む際に利用規約に同意させることが必須かは曖昧でした。
  • MMDでのモデル情報がアイディアだと思います。

一人称視点 (VRMFirstPerson)

glTF拡張部

glTF/extensions/VRM/firstPerson
名称 説明 備考
firstPersonBone 一人称視点を設定するボーン -------------
firstPersonBoneOffset 一人称視点を設定するボーンからのオフセット -------------
meshAnnotations ------------- -------------
lookAtTypeName 目線制御の種類 -------------
lookAtHorizontalInner 目線制御の顔の中心側への程度 -------------
lookAtHorizontalOuter 目線制御の顔の外側への程度 -------------
lookAtVerticalDown 目線制御の下向きへの程度 -------------
lookAtVerticalUp 目線制御の上向きへの程度 ------------- 
glTF/extensions/VRM/firstPerson/firstPersonBoneOffset
名称 説明 備考
x ------------- glTFの標準的な仕様に合わせると配列でまとめた方が良い
y ------------- glTFの標準的な仕様に合わせると配列でまとめた方が良い
z ------------- glTFの標準的な仕様に合わせると配列でまとめた方が良い

一人称視点

2018年当初の「VRアプリケーション向けの人型3Dアバター（3Dモデル）データを扱うためのファイルフォーマット」としては意外と重要な要素です。
単に3Dキャラクターの内部にHMDの視点を設定するとカメラにはキャラクターの舌や歯などの構造が映ります。 一人称視点のみについては恐らく存在意義がありませんが、何故かVRM 1系にも残っています。 https://vrm.dev/univrm/firstperson/univrm_firstperson/

  • 自動設定
  • 常に映る
  • 三人称視点のみ
  • 一人称視点のみ

UniVRM

出力する際に視点の位置は目の間に自動設定されると思いきやされていなかったので、設定が間違っているVRMがありました。 UniVRMでは自動設定の際にはメッシュ分割を行ってカメラレイヤーの指定をしていましたが、再現方法としてメッシュ分割を行うこと自体がVRMの仕様なのかは不明です。

目線制御

便宜上VRMLookAtと表記していますが、gltTF拡張としてはglTF/extensions/VRM/firstPersonの辺りに記録されます。

ボーン制御

キャラクターが目標を見つめた際の目線制御の程度の調整が可能でした。
目線制御の程度の調整がVRMに必須なのかは不明です。
使い方が不明だったので、目線制御の程度を上書きするようなアプリもありました。
目線制御の程度を上書きするのはVRMの改変になるのかという問題があります。

モーフ制御

モーフでの目線制御が可能でした。 使われていた記憶はほとんどありません。 プリセット表情の一部を使用しますが、設定しない方が無難でした。

  • 目線上
  • 目線下
  • 目線右
  • 目線左

過去の議論

ボーンの正規化

ボーンの正規化によるローカル軸破棄の仕様は何度か議論になり、とりあえずVRM 1系は回転値が残っている仕様になりました。
VRM 1系に拡大縮小も残っているのはUniVRMの不具合なのか仕様なのかは不明です。

備考

振り返ると、議論の前提知識にVRMのキャラクターの衣装改変を想定しているかが無かったように感じます。
3DのJPEGと表現されてしまいましたが、PSDに対するPNGと表現しても良かったかと思います。
正規化という言葉ではなく、DCCツールのようなトランスフォームの適用なら理解しやすかったと思います。

揺れ物のCenter

VRMコンソーシアム自体も役割を知らないような機能です。
https://github.com/vrm-c/vrm-specification/issues/155

備考

Centerという名称が理解しづらいように感じます。
ちなみにMMDにセンターボーンというキャラクターの基準になるボーンがあり、それを想定した名称なのではないかと予想しています。
VRMコンソーシアムでのテスト方法が不明なのでこの予想の真偽も不明です。

VRMのアプリ事の差異

アプリの制約上VRMデータが読み込めないことがありました。
推奨データサイズがVRM 1系で決まるかと思っていましたが、特に決まってはいないです。
アプリの制約上無視して良い概念の程度も決まっていないです。

Unity特有の仕様

VRM仕様では定義できないUnity特有の仕様の問題がありました。
UniVRMがこの特有な問題を解決するための方法は曖昧です。
つまり、VRMの理想をUnityで再現する公式的な見本と考えられるUniVRMの仕様が曖昧です。

謝辞

あまりにも色々な課題が発生し、あまりにも対処が遅かったですが、アイディアそのものは良かったのかなと未だに感じています。
誰に感謝すれば良いのか不明なのは付録をご覧ください。

Fuji SunflowerによるVRM 0系に関する調査です。
OSSならばVRMドキュメントに書くのが正しいのですが、ページが細切れにされて見つからなくなってしまうので自分用のWikiを用意しました。
Oenotheraの読み方はオエノセラで月見草のことです。ひっそり暮らしていけたらいいですね。

This is the research about VRM v0 by Fuji Sunflower.
I'm in trouble because VRM document is fragmented highly. So I created my wiki although I should send pull requests as OSS.
Oenothera is evening primrose. I hope quiet life.

Clone this wiki locally